Public bug reported:

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 ...

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/

** Affects: initramfs-tools (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: initramfs-tools (Ubuntu Xenial)
     Importance: Undecided
         Status: New

** Affects: initramfs-tools (Ubuntu Bionic)
     Importance: Undecided
         Status: New


** Tags: rls-ee-incoming

** Also affects: initramfs-tools (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  New
Status in initramfs-tools source package in Xenial:
  New
Status in initramfs-tools source package in Bionic:
  New

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 ...

  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

_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to     : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

Reply via email to