This bug was fixed in the package initramfs-tools - 0.130ubuntu3.9

initramfs-tools (0.130ubuntu3.9) bionic; urgency=medium

  * Add support for panic=-1 value (LP: #1831252)

 -- Julian Andres Klode <>  Mon, 07 Oct 2019 12:53:35

** Changed in: initramfs-tools (Ubuntu Bionic)
       Status: Fix Committed => Fix Released

** Changed in: initramfs-tools (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.

  panic=-1 is completely ignored by the initrd causing unexpected

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Fix Released
Status in initramfs-tools source package in Bionic:
  Fix Released
Status in initramfs-tools source package in Disco:
  Fix Released
Status in initramfs-tools source package in Eoan:
  Fix Released

Bug description:
  in Ubuntu Core we default to using panic=-1 on the kernel command line 
(documented at [1]) to speed up the auto-rollback mechanism of the kernel. on a 
kernel level this works just fine and the system reboots immediately ...

  when in the initramfs during boot and a panic occurs, no reboot
  happens at all, the initrd spawns a shell regardless of the panic=
  value ...

  [Test case]

  Before booting change root=$foo to root=x$foo - this will make it
  panic. Then test that

  1) "panic=-1" causes an immediate reboot
  2) "panic=5" waits 5 seconds
  3) no "panic" drops you to a shell

  [Regression potential]
  This adds some very specific checks for -1 in places that use ${panic}, as 
such the regression potential is somewhat limited. If there were a regression, 
it could be a syntax error (causing boot to fail) or a sleep not working 
correctly (causing sleep to, well, not sleep) - but that's unrealistic.

  [Other info]
  this is caused by a filter in  /usr/share/initramfs-tools/init

                  case ${panic} in

  this function only lets positive values through, else panic= simply
  gets unset

  the panic() function itself is also not capable of handling negative
  values, it has a sleep call that interprets negative values as
  commandline options instead of simply ignoring a negative sleep time
  [2] (line 11).

  the filter in the init script should allow the -1 value (to comply
  with the kernel documentation and behaviour) and the panic() function
  should properly skip the sleep call when a negative value for panic=
  is set.


To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to