[Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Thu Sep 24 20:22:22 UTC 2020

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
Foundations Bugs, 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