All autopkgtests for the newly accepted initramfs-tools (0.136ubuntu6.3) for 
focal have finished running.
The following regressions have been reported in tests triggered by the package:

initramfs-tools/0.136ubuntu6.3 (armhf)

Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].


Thank you!

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

  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  Fix Committed
Status in initramfs-tools source package in Groovy:
  Fix Released

Bug description:

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to