group.of.nepali.translators team mailing list archive
-
group.of.nepali.translators team
-
Mailing list archive
-
Message #36774
[Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.
This bug was fixed in the package initramfs-tools - 0.137ubuntu12
---------------
initramfs-tools (0.137ubuntu12) groovy; urgency=medium
* d/tests: Add explicit call to partprobe on net test, specially in
prep-image and run-image. (LP: #1893675)
initramfs-tools (0.137ubuntu11) groovy; urgency=medium
* scripts/functions: Prevent printf error carry over if the wrong
console is set. (LP: #1879987)
The function _log_msg() is "void" typed, returning whatever its
last command returns. This function is the basic building block
for all error/warning messages in initramfs-tools. If a bad console
is provided to kernel on command-line, printf 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 "quiet" is not passed in the
command-line). If that happens, boot is stuck and cannot progress.
The simple fix hereby merged is to return zero on _log_msg().
* scripts/local: Re-execute cryptroot local-block script. (LP: #1879980)
Currently, if an encrypted rootfs is configured on top of a MD RAID1
array and such array gets degraded (like a member is removed/failed),
initramfs-tools cannot mount the rootfs and the boot fails. We fix
that issue here by allowing cryptroot script to re-run on local-block
stage, given that mdadm is able to activate a degraded array in that
point. There is a cryptsetup counter-part for this fix, but alone the
initramfs-tools portion is innocuous.
-- gpiccoli@xxxxxxxxxxxxx (Guilherme G. Piccoli) Mon, 31 Aug 2020
18:04:00 -0300
** Changed in: initramfs-tools (Ubuntu Groovy)
Status: In Progress => Fix Released
--
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/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:
In Progress
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