group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1879987@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package initramfs-tools - 0.130ubuntu3.11

---------------
initramfs-tools (0.130ubuntu3.11) bionic; urgency=medium

  [ Guilherme G. Piccoli ]
  * scripts/functions: Prevent printf error carry over if the wrong
    console is set. (LP: #1879987)
      The function _log_msg() is "void" typed, returning whatever its
      last command returns. This function is the basic building block
      for all error/warning messages in initramfs-tools. If a bad console
      is provided to kernel on command-line, printf 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 "quiet" is not passed in the
      command-line). If that happens, boot is stuck and cannot progress.
      The simple fix hereby merged is to return zero on _log_msg().

  * scripts/local: Re-execute cryptroot local-block script. (LP: #1879980)
      Currently, if an encrypted rootfs is configured on top of a MD RAID1
      array and such array gets degraded (like a member is removed/failed),
      initramfs-tools cannot mount the rootfs and the boot fails. We fix
      that issue here by allowing cryptroot script to re-run on local-block
      stage, given that mdadm is able to activate a degraded array in that
      point. There is a cryptsetup counter-part for this fix, but alone the
      initramfs-tools portion is innocuous.

  [ Jay Vosburgh ]
  * scripts/functions: Change netplan render for net_failover master
    devices. (LP: #1820929)
      Modify the _render_netplan function to check for network interfaces
      that are net_failover master devices. When found, such devices are
      matched only by name, not by MAC address, as the MAC is not a unique
      identifier for the net_failover case. In the net_failover architecture,
      the MAC address is used to manage the membership of the net_failover
      interface set, thus multiple interfaces will be assigned the same MAC
      address.

 -- gpiccoli@xxxxxxxxxxxxx (Guilherme G. Piccoli)  Wed, 12 Aug 2020
17:12:11 -0300

** Changed in: initramfs-tools (Ubuntu Bionic)
       Status: Fix Committed => Fix Released

** Changed in: initramfs-tools (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 Released
Status in initramfs-tools source package in Bionic:
  Fix Released
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