** Description changed: - kernel get stucks at boot if console=ttyS* is specified in the kernel - cmdline and that serial HW isn't available on the system. + [Impact] - Reproduced with: - 4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next (mainline) + * 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. - Removing the non-existent 'console=ttyS*' parameter fixes the situation. + * 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. - I tested it using KVM/qemu, but it has been brought to my attention that - it was reproducible in VMware as well. + * This SRU proposes a pretty simple fix: return zero on _log_msg(). We + should definitely not brake the boot due to error log functions. - I think it is safe to say that it is unlikely to be specifics to a - certain virtualization technology type. - Didn't test on baremetal yet. + [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.
-- 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: In Progress 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: In Progress Status in initramfs-tools source package in Groovy: In Progress 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
