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

[Guilherme G. Piccoli]

** Description changed:

- kernel get stucks at boot if console=ttyS* is specified in the kernel
- cmdline and that serial HW isn't available on the system.
+ [Impact]
  
- Reproduced with:
- 4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next (mainline)
+ * 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.
  
- Removing the non-existent 'console=ttyS*' parameter fixes the situation.
+ * 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.
  
- I tested it using KVM/qemu, but it has been brought to my attention that
- it was reproducible in VMware as well.
+ * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
+ should definitely not brake the boot due to error log functions.
  
- I think it is safe to say that it is unlikely to be specifics to a
- certain virtualization technology type.
  
- Didn't test on baremetal yet.
+ [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.

-- 
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:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

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