Bug#962545: Invalid serial console blocks system boot
Package: initramfs-tools
Version: 0.137
Followup-For: Bug #960355
Hi Ben and Jonas, I was reporting a similar bug and found this one, thanks
to reportbug!
So, I think this is indeed a bug. The problem was vastly debugged in a
recent Launchpad issue [0], I'll give a summary here.
Currently, _log_msg() is like a void-typed function, with no return. If the
parameter "quiet" is not provided, there's a printf and then the function
returns, which in shell language means the printf return is carried over
to the caller of _log_msg().
Problem is: checkfs() makes use of error log functions, which in the end
rely on _log_msg(). If "quiet" is not supplied, and the filesystem is not
set to fsck on boot (i.e., fsck is not included in the initrd), when the
bad console is provided, an error message on checkfs_once() will eventually
reach the printf on _log_msg(), causing checkfs_once() to "inherit" the bad
return from printf.
The big issue comes now: checkfs() runs a loop, and given in this corner
case checkfs_once() returns an error state, the loop goes on forever,
effectively preventing the boot.
I consider this a bug specially because we had reports of cases in which
the serial console was working...but after a (virtual) HW update the
serial port changed, hence introducing such boot loop.
I've proposed a really simple fix in the following merge request:
salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/30
One could argue the problem is on checkfs() and we could fix there.
I disagree, I think in no way an error log message should prevent boot or
induce such errors by carrying over a bad result due to invalid console.
Also, we could rethink printf returning error in case of bad console,
but this is/will be a long-term discussion, no quick fix will outcome
from there, so I'd rather have it fixed now if possible.
Cheers,
Guilherme
[0] bugs.launchpad.net/bugs/1573095
-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Reply to: