[Bug 1831252] Re: panic=-1 is completely ignored by the initrd causing unexpected behaviour

[Tiago Stürmer Daitx]

I tested the initramfs-tools in xenial-proposed, bionic-proposed, and disco-proposed with all 3 testcases (panic=-1, panic=10, and no panic), everything worked as expected:
- panic=-1 rebooted instantly after the root partition is not found
- panic=10 rebooted after 10 seconds
- no "panic" entry caused to drop into a basic shell

ii  initramfs-tools  0.122ubuntu8.16  all  generic modular initramfs generator (automation)
ii  initramfs-tools  0.130ubuntu3.9   all  generic modular initramfs generator (automation)
ii  initramfs-tools  0.131ubuntu19.2  all  generic modular initramfs generator (automation)


multipass at xenial:~$ apt-cache policy initramfs-tools
initramfs-tools:
  Installed: 0.122ubuntu8.16
  Candidate: 0.122ubuntu8.16
  Version table:
 *** 0.122ubuntu8.16 400
        400 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.122ubuntu8.15 500
        500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
     0.122ubuntu8.14 500
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
     0.122ubuntu8 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages


multipass at bionic:~$ apt-cache policy initramfs-tools
initramfs-tools:
  Installed: 0.130ubuntu3.9
  Candidate: 0.130ubuntu3.9
  Version table:
 *** 0.130ubuntu3.9 400
        400 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.130ubuntu3.8 500
        500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
     0.130ubuntu3.6 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     0.130ubuntu3 500
        500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages


multipass at disco:~$ apt-cache policy initramfs-tools
initramfs-tools:
  Installed: 0.131ubuntu19.2
  Candidate: 0.131ubuntu19.2
  Version table:
 *** 0.131ubuntu19.2 400
        400 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.131ubuntu19.1 500
        500 http://archive.ubuntu.com/ubuntu disco-updates/main amd64 Packages
     0.131ubuntu19 500
        500 http://archive.ubuntu.com/ubuntu disco/main amd64 Packages

** Tags removed: verification-needed verification-needed-bionic verification-needed-disco verification-needed-xenial
** Tags added: verification-done-bionic verification-done-disco verification-done-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1831252

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

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

Bug description:
  [Impact]
  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

          panic=*)
                  panic="${x#panic=}"
                  case ${panic} in
                  *[![:digit:].]*)
                          panic=
                          ;;
                  esac
                  ;;

  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.

  [1] https://github.com/torvalds/linux/blob/v4.17/Documentation/admin-guide/kernel-parameters.txt#L2931
  [2] https://paste.ubuntu.com/p/mswD8Cd869/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831252/+subscriptions