Verification done for bionic:
bionic-updates:
- boots fine w/ console=ttyS0, can ssh in 10 seconds.
- boot fails w/ console=ttyS1, cannot SSH, qemu on 100% CPU (initramfs-tools
looping)
bionic-proposed:
- boots fine w/ console=ttyS0, can ssh in 10 seconds. (no regression)
- boots fine w/ console=ttyS1, can ssh in 10 seconds, qemu on low CPU% (issue
fixed)
details:
-------
$ lsb_release -cs
bionic
bionic-updates:
---
$ dpkg -s initramfs-tools | grep -i version:
Version: 0.130ubuntu3.10
console=ttyS0:
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-99-generic
root=UUID=f513680e-7260-45e3-b4aa-89e4a210be77 ro console=ttyS0
console=ttyS1:
(cannot SSH into system. CPU% always high for QEMU.)
$ top -b -d1 | grep -e CPU -e qemu
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142522 libvirt+ 20 0 3745600 485332 23116 S 100.0 3.0 1:30.08
qemu-system-x86
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142522 libvirt+ 20 0 3745600 485332 23116 S 99.0 3.0 1:31.08
qemu-system-x86
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142522 libvirt+ 20 0 3745600 485332 23116 S 98.0 3.0 1:32.07
qemu-system-x86
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142522 libvirt+ 20 0 3745600 485332 23116 S 99.0 3.0 1:33.07
qemu-system-x86
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142522 libvirt+ 20 0 3745600 485332 23116 S 99.0 3.0 1:34.06
qemu-system-x86
^C
bionic-proposed:
---
$ dpkg -s initramfs-tools | grep -i version:
Version: 0.130ubuntu3.11
console=ttyS0:
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-99-generic
root=UUID=f513680e-7260-45e3-b4aa-89e4a210be77 ro console=ttyS0
console=ttyS1:
(can SSH into system. CPU% low for QEMU)
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-99-generic
root=UUID=f513680e-7260-45e3-b4aa-89e4a210be77 ro console=ttyS1
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142731 libvirt+ 20 0 3656512 602160 22816 S 83.2 3.7 0:38.73
qemu-system-x86
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142731 libvirt+ 20 0 3656512 602160 22816 S 29.7 3.7 0:39.03
qemu-system-x86
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142731 libvirt+ 20 0 3656512 602160 22816 S 1.0 3.7 0:39.04
qemu-system-x86
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142731 libvirt+ 20 0 3656512 602160 22816 S 2.0 3.7 0:39.06
qemu-system-x86
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
142731 libvirt+ 20 0 3656512 602160 22816 S 2.9 3.7 0:39.09
qemu-system-x86
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
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:
Fix Released
Status in initramfs-tools source package in Trusty:
Won't Fix
Status in initramfs-tools source package in Xenial:
Fix Committed
Status in initramfs-tools source package in Bionic:
Fix Committed
Status in initramfs-tools source package in Eoan:
Won't Fix
Status in initramfs-tools source package in Focal:
Fix Released
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
--
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
