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)
