[Bug 1768230] Re: Long time booting : Failed to connect to lvmetad. Falling back to device scanning.

Janne Snabb 1768230 at bugs.launchpad.net
Wed Jan 30 16:57:15 UTC 2019


On 29/01/2019 13.44, Marc Pignat wrote:
> If I understand well, ubiquity is the installer, so the iso image must
> be tested.
>
> Where can I find a 18.04-daily iso image?

As I understand it (might be wrong), the normal daily ISO is not the 
correct one to test with because it is not based on the /proposed/ 
repository.

The correct procedure is documented here: 
https://wiki.ubuntu.com/Testing/EnableProposed#Installation_testing_using_-proposed

Looks like there are no normal ISOs available. Thus there is a 
requirement to set up a netboot environment, which is documented here: 
https://help.ubuntu.com/community/Installation/Netboot

However, the expected location for the /proposed/ netboot installer does 
not have recent enough version to include this fix: 
http://archive.ubuntu.com/ubuntu/dists/bionic-proposed/main/installer-amd64/

Maybe it will appear there at a later time...

Janne Snabb
snabb at epipe.com

-- 
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/1768230

Title:
  Long time booting : Failed to connect to lvmetad. Falling back to
  device scanning.

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in ubiquity package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  Fix Committed
Status in ubiquity source package in Bionic:
  Fix Committed

Bug description:
  [SRU Justification]
  A regression in initramfs-tools causes it to autogenerate config in the initramfs saying to resume from any available swap devices, but references the swap device by UUID, which is not a canonical form for referring to LVM volumes (because of snapshotting, they are not unique).  Ubiquity also generates a file in /etc at install time which references the swap partition in the same way.  Since the lvm2 initramfs hooks also only activate precisely those LVs that are detected as needed at boot, this adds an inappropriate 30-second boot delay to any system with swap on LVM, which includes any desktop system that was configured with LVM (but not full-disk encryption) at install time.

  [Test case]
  1. Install using the "Use LVM" option in the desktop installer.
  4. Reboot.
  5. Verify that dmesg shows a 30-second delay before mounting the root filesystem.
  6. Install initramfs-tools from bionic-proposed.
  7. Reboot.
  8. Verify that dmesg no longer shows a 30-second delay before mounting the root filesystem.
  9. Install using the bionic daily image that contains the ubiquity from bionic-proposed.
  10. Reboot.
  11. Verify that /etc/initramfs-tools/conf.d/resume is not present and that there is no delay before mounting the root filesystem.

  [Regression potential]
  This makes changes to shell scripts, and shell is a perilous language. An unnoticed bug could cause all initramfs generation, and thus all kernel installation, to fail for some users. A regression could also cause a user to lose hiberation support that they currently have.

  [Original description]
  After choosing "Erase disk and install ubuntu" + "Use LVM with the new Ubuntu installation", the
  system is very slow to reboot.

  It shows the message : "WARNING:Failed to connect to lvmetad. Falling back to device scanning.",
  then waits 32 seconds, then continues as it should.

  I think this is a ubiquity bug, since the d-i based installer is not affected.
   - ubuntu-18.04-desktop-amd64.iso (a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34) : affected
   - xubuntu-18.04-desktop-amd64.iso (7c24318d3b1de1efd584b5aea034ce1aafd2d0f06c59812d989a5fc95bf947e3) : affected
   - ubuntu-18.04-server-amd64.iso (a7f5c7b0cdd0e9560d78f1e47660e066353bb8a79eb78d1fc3f4ea62a07e6cbc) : not affected

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1768230/+subscriptions



More information about the foundations-bugs mailing list