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]. https://people.canonical.com/~ubuntu-archive/proposed- migration/focal/update_excuses.html#initramfs-tools [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions 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. https://bugs.launchpad.net/bugs/1879987 Title: 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: [Impact] * 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 _log_msg(). * 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: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
