/srv/irclogs.ubuntu.com/2019/05/31/#ubuntu-devel.txt

=== MJDombrowski_ is now known as MJDombrowski
=== MJDombrowski_ is now known as MJDombrowski
=== MJDombrowski_ is now known as MJDombrowski
=== MJDombrowski_ is now known as MJDombrowski
=== MJDombrowski_ is now known as MJDombrowski
=== gusnan is now known as Guest25872
=== gusnan_ is now known as gusnan
ograxnox, yo ... i'm currently looking at the panic() function of the initrd ... on Ubuntu Core we set panic=-1 on the cmdline ... which the kernel typically hadles fine ... now we have an issue with a customer where the initrd drops you into a console with the panic= value set ... according to the code it should sleep for $panic seconds and then reboot instead of dropping to a shell ... https://paste.ubuntu.com/p/mswD8Cd869/12:03
ogranow ... that "sleep -1" (resulting from the "panic=-1" on the cmdline) seems to cause us to still end up in a shell, seemingly the error from the sleep command makes us jump ahead to the /bin/sh at the bottom of that function12:04
ogra(i assume initrd scripts dont use set -e ?)12:04
ddstreetogra that initrd script certainly doesn't match the kernel's panic usage12:06
ograddstreet, that might be ... it is what we have by default in the 16.04 initramfs-tools though (i'm working on Core16 which uses exactly the above code)12:07
ddstreetah12:07
ddstreetogra unrelated to that but re: panic=-1, i hope you are restoring /proc/sys/kernel/panic to 0 (or whatever the user's configured) after booting?  not leaving the system with panic=-1?12:08
ograi need to avoid dropping to the shell (which i can surely by simply setting panic=1 (that should only delay the kernel panic a bit when not in initrd) ... but in general it looks like a bug in initramfs tools12:08
ograddstreet, it is a constant default ... Core is mainly used in non-user setups ... headless remote managed devices etc ... so the panic value should cause an immediate reboot12:09
ogra(Corer has a builtin rollback mechnaism and the reboot will cause you to go back automatically to the last known good kernel)12:09
xnoxogra:  it would be interesting to see the full boot log with: set -x12:10
xnoxogra:  to see exactly what has happened.12:10
ograthe -1 is fine in all cases except the initrd panic12:10
xnoxogra:  maybe none of panic() is called at all?12:10
xnoxogra:  also, do you need sleep here?12:10
ograxnox, well, it properly prints the "dropping to a shell yadda yadda" stuff and all ...12:11
ograi dont need the sleep at all12:11
ograwhat i need is no shell when the fs is corrupt on a device that has secureboot enabled12:11
xnoxogra:  you did see "Rebooting automatically due to panic=" right ?12:11
ogranope12:11
xnoxogra:  also it is odd to have a variable named same as a function =)12:11
ograit just drops into the initrd shell12:12
xnoxogra:  so ${panic} is not set?12:12
ogra(i dont have the exact logs from the customer)12:12
ograpanic is set to -112:12
ogra$ LC_ALL=C sleep "-1"12:12
ograsleep: invalid option -- '1'12:12
ograTry 'sleep --help' for more information.12:12
ograsleep thinks it is an option due to the minus12:12
xnoxsleep -- -112:13
xnoxsleep: invalid time interval ‘-1’12:13
xnox  12:13
xnoxbut still kind of useless12:13
ograyes12:13
ograwell, before i start hacking up my own panic() function for this customer project i thought we should also fix it upstream ;)12:13
xnoxogra:  so obviously just this snippet of code is not enough, without reproducer or full logs12:13
xnoxogra:  so do you have reproducer or full logs?12:14
ograwell, obviously that code snippet cant handle negative values and this should be fixed12:14
ograregardless of logs/reproducer12:14
xnoxogra:  but also not critical for the customer, right?12:14
ograwell, given they sell secureboot protected devices, they dont really want people to gain root access to these systems just because of an FS corruption on potentially unrelated plugged in USB drives or whatever12:15
ograso it is kind of critical :)12:16
ogra(i guess i'll get along with panic=1 for that particular case .... but i also think we need a fix in the existing upstream code ... this is why i pinged)12:16
ograi assume the original sleep code there is in place so that you can actually see the console message before it reboots12:19
=== coreycb_ is now known as coreycb
=== davecore_ is now known as davecore
=== sadin999_ is now known as sadin999
=== JamieBennett_ is now known as JamieBennett
=== pch2013_ is now known as pch2013
=== jamespage_ is now known as jamespage
=== Pici` is now known as Pici
=== ebarretto_ is now known as ebarretto
xnoxogra:  secureboot does not imply locked down device.12:37
xnoxogra:  i'm not sure what is the intention of -112:38
ograwell ... its an expectation that you cant easily gain root access though12:38
ograxnox, https://github.com/torvalds/linux/blob/v4.17/Documentation/admin-guide/kernel-parameters.txt#L293112:38
=== ricab is now known as ricab|lunch
ogra(as i just said in the interhnal channel, that initrd functio doesnt take panic=0 into account either)12:38
ogra*internal12:38
xnoxogra:  right, so the code should handle that too.... ie what you mentioned earlier i.e. on zero call `sleep infinity` and on negative numbers, skip calling sleep12:39
ograright12:39
ograi think the original implementation of that function simply pre-dates that kernel feature ...12:40
ograxnox, oh my ... digging deeper i see that /usr/share/initramfs-tools/init actually filters out negative values completely for panic= ... (unless my regex understanding is wrong)13:11
=== smoser1 is now known as smoser
=== ricab|lunch is now known as ricab
ograxnox, https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/183125214:25
ubottuLaunchpad bug 1831252 in initramfs-tools (Ubuntu) "panic=-1 is completely ignored by the initrd causing unexpected behaviour" [Undecided,New]14:25
xnoxogra:  hehe. I did say "are you sure panic is even set?!"14:32
ograyeah, now i'm sure it is not because of this :)14:32
=== gusnan_ is now known as gusnan
=== gusnan is now known as Guest20834
=== Guest20834 is now known as gusnan
ddstreetvorlon xnox fyi, not sure if you noticed yet but it's not only systemd failing during test reboots, dbus test just failed as well: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/d/dbus/20190531_164159_d3a1e@/log.gz18:45
bdmurraysarnold: Have you had a chance to test bug 1820676? Maybe you could test it with a new laptop install. ;-)19:01
ubottubug 1820676 in ubiquity (Ubuntu) "Something has gone seriously wrong: import_mok_state0 failed" [Undecided,Incomplete] https://launchpad.net/bugs/182067619:01
connor_klol19:02
sarnoldbdmurray: it's funny you mention that, I just a few moments ago saw https://www.zdnet.com/article/dell-releases-more-high-end-ubuntu-linux-laptops/19:03
sarnoldbdmurray: I tried a new image on the machine that was wedged and it *did* boot past that point -- I however forgot to test what happens if you hit the cancel button in the installer19:04
bdmurraysarnold: dpm19:04
bdmurraysarnold: don't you have a new laptop lying around somewhere...19:04
sarnoldbdmurray: yes19:04
bdmurraysarnold: here's one more reason to play with it!19:05
sarnoldyes :)19:05
connor_ksarnold, most expensive paperweight ever19:10
sarnoldconnor_k: you should meet my server..19:11
=== gQuigs is now known as bryanquigley

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!