Prevents printf error carry over if wrong console is set
I've updated bug #960355 with more information. Appreciate reviews, thanks in advance!
Guilherme
Currently the _log_msg() functions is "void" typed - with no return -, which in terms of shell means it returns whatever its last command returns. This function is the basic building block for all error/warning messages in initramfs-tools.
It was noticed [0] that in case of bad console is 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 and we can find various reports dating back some years. The reports usually are of the form "machine can't boot if wrong console is provided" or slightly different forms of that, almost always relating serial consoles with boot issues.
This patch proposes a pretty simple fix: return zero on _log_msg(). We should definitely not brake the boot due to error log functions; one could argue we could fix checkfs() and that's true, until eventually we find another subtle corner case of "misuse" of the _log_msg() return value (after some debugging), and fix that too, and so on... W could also argue that printf shouldn't return error in this case, and although a valid discussion, it's not worth to have users waiting on a dilemma while boot is quite easy to brake, just by passing a wrong kernel parameter (or having the underlying serial console device changed to output to a different port than the previously set on kernel cmdline).
[0] bugs.launchpad.net/cloud-images/+bug/1573095/comments/46 Signed-off-by: Guilherme G. Piccoli gpiccoli@canonical.com