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

Status changed to 'Confirmed' because the bug affects multiple users.

Unfortunately, the "WARNING:Failed to connect to lvmetad. Falling back to device scanning." only shows up on the console, not in the log files.

It is super-easy to reproduce here at least. I tried 18.04 with the ubuntu and the xubuntu CD. Chose default options, except for wanting LVM (and a Danish keyboard).

System gets created fine. At all boots after that, it shows "WARNING:Failed to connect to lvmetad. Falling back to device scanning." at the beginning of the boot process, and then after approx 30 seconds: "Gave up waiting for suspend/resume device /dev/mapper/xubuntu--vg-root: clean XXX/XXX files, XXX/XXX blocks"

See https://i.imgur.com/66bYGky.png or attached

Ah, sorry, let me be precise. Not the "ubuntu and the xubuntu CD" but these ISO images:

# sha1sum xubuntu-18.04-desktop-amd64.iso ubuntu-18.04-desktop-amd64.iso
a1bcc46d01387337d4be81ba76e89b495a7b5331 xubuntu-18.04-desktop-amd64.iso
f373c0aec6162cdba76ee9084e695866a15e441a ubuntu-18.04-desktop-amd64.iso

This is also happening to me, in addition, it mounts the system in read-only mode.
This is on a new installation, on a VM

I have this issue at every boot in my Ubuntu Virtualbox VM. It started happening after updating it from Ubuntu 17.10 to Ubuntu 18.04.

Someone has proposed a workaround here : https://askubuntu.com/a/1031667/454520, adding "noresume" to the kernel command line.

this happened to me when I just updated from 17.X to 18.04 LTS in virtualbox. I used the automatic GUI updater that popped up and informed me that there is an update available.

Is this bug only occuring in a virtual setting (e.g. 17.10 to 18.04 in VirtualBox) or also on non-virtual upgrade (from 17.10 to 18.04) ?

This bug exists on real machines, but it's far more easier to test in on a virtual one.

Happens to my install that is on older dell hardware, with a 120 GB SSD.
Optiplex 3010

On Wed, May 23, 2018, 5:11 AM thinkpad, <email address hidden> wrote:

> Is this bug only occuring in a virtual setting (e.g. 17.10 to 18.04 in
> VirtualBox) or also on non-virtual upgrade (from 17.10 to 18.04) ?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1768230
>
> Title:
> Long time booting : Failed to connect to lvmetad. Falling back to
> device scanning.
>
> Status in ubiquity package in Ubuntu:
> Confirmed
>
> Bug 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/ubiquity/+bug/1768230/+subscriptions
>

This bug also affects me; clean install of Bionic onto real hardware. Let me know if I can supply any data that would be helpful in debugging.

Fresh install on my Laptop 18.04 and using lvm with ext4 filesystem. Boot is slowdown about 30 seconds while display the error message in bug desscription. I'm using a manual created lvm setup druing installation.

Same issue here, from a fresh install on Lenovo T460. I have tried to add "noresume" to the kernel command line as proposed here (https://askubuntu.com/questions/1034359/boot-hangs-for-30-seconds-at-begin-running-scripts-local-premount) but only got a tiny bit faster. Any other workaround?

Same bug after upgrading 16.04 to 18.04, using lvm with ext4 filesystem

Same bug here, firstly after upgrading from 17.10 to 18.04, then I installed fresh ubuntu from .iso - the same result.

This bug seems wrongly linked to ubiquity since updating the system can also lead to the bug. Can someone find a better package to link this bug to? the kernel?

I should add that my system was an upgrade, using LVM with EXT4. I'm
honestly debating about backing up, blowing it up and installing fresh
without LVM, I'm not sure I see the advantage to using it.

On Thu, Jun 14, 2018 at 10:31 AM Marc Pignat <email address hidden>
wrote:

> This bug seems wrongly linked to ubiquity since updating the system can
> also lead to the bug. Can someone find a better package to link this bug
> to? the kernel?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1768230
>
> Title:
> Long time booting : Failed to connect to lvmetad. Falling back to
> device scanning.
>
> Status in ubiquity package in Ubuntu:
> Confirmed
>
> Bug 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/ubiquity/+bug/1768230/+subscriptions
>

--
Steve Lougheed
<email address hidden>
BCS Junior High Computer Science
905-843-3771

This email, including any attachments, is for the sole use of the intended
recipient and may contain confidential information. If you are not the
intended recipient, please immediately notify us by reply email or by
telephone, delete this email and destroy any copies. Thank-you.

Two bugs:
- ubiquity creates an /etc/initramfs-tools/conf.d/resume which lists the swap device by UUID; this is not the correct way to reference a device that's on LVM, and with the current lvm initramfs hooks it fails because it won't be found to be activated.
- if /etc/initramfs-tools/conf.d/resume is absent, initramfs-tools itself auto-creates a file on update-initramfs -u that references the uuid.

We need to fix both.

I'm not sure if we should add some upgrade handling to detect broken /etc/initramfs-tools/conf.d/resume for this case and remove it on upgrade.

This bug was fixed in the package initramfs-tools - 0.130ubuntu10

---------------
initramfs-tools (0.130ubuntu10) cosmic; urgency=medium

  * Avoid redundant call to dmsetup.

 -- Steve Langasek <email address hidden> Thu, 14 Jun 2018 22:26:51 -0700

@vorlon,

I can't get it work

Tested that:
[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.

Downloaded:
initramfs-tools_0.130ubuntu10_all.deb
initramfs-tools-bin_0.130ubuntu10_amd64.deb
initramfs-tools-core_0.130ubuntu10_all.deb

done : dpkg -i *.deb

7. Reboot.
8. Verify that dmesg no longer shows a 30-second delay before mounting the root filesystem.

30 second delay still there
/etc/initramfs-tools/conf.d/resume still exists

If the file `/etc/initramfs-tools/conf.d/resume` is deleted manually, it is not re-created by update-initramfs -u

And this warning is not really reassuring:

sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/xubuntu--vg-swap_1)
I: Set the RESUME variable to override this.

Hello Marc, or anyone else affected,

Accepted initramfs-tools into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.130ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Test case]
1. Install using the "Use LVM" option in the desktop installer.
 - installed using xubuntu-18.04-desktop-amd64.iso (7c24318d3b1de1efd584b5aea034ce1aafd2d0f06c59812d989a5fc95bf947e3)
4. Reboot.
5. Verify that dmesg shows a 30-second delay before mounting the root filesystem.
 - sure it does
 - file /etc/initramfs-tools/conf.d/resume exists
6. Install initramfs-tools from bionic-proposed.
 - file /etc/initramfs-tools/conf.d/resume still exists
7. Reboot.
8. Verify that dmesg no longer shows a 30-second delay before mounting the root filesystem.
 - problem persists.

apt list initramfs-tools
Listing... Done
initramfs-tools/bionic-proposed,bionic-proposed,now 0.130ubuntu3.2 all [installed]

The workaround is to delete /etc/initramfs-tools/conf.d/resume.

Tested http://cdimage.ubuntu.com/daily-live/20180620/cosmic-desktop-amd64.iso, which includes initramfs-tools 0.130ubuntu3.2. It is still affected.

Upgrading initramfs-tools to 0.130ubuntu3.2 should be sufficient to resolve the symptom of this bug, even with a broken /etc/initramfs-tools/conf.d/resume still on disk.

Marc, when you are able to still reproduce this bug with initramfs-tools 0.130ubuntu3.2, what is the full output of 'sudo update-initramfs -u'?

If the output is that which you posted in comment #25:

I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/xubuntu--vg-swap_1)

... then that is exactly what we *expect* to see as the output and it needs investigating why this does not take precedence over /etc/initramfs-tool/conf.d/resume for you.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1768230

As you requested, the full output of sudo update-initramfs -u :

pim@pim:~$ sudo update-initramfs -u
[sudo] password for pim:
update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic
pim@pim:~$

After that the 30 second delay is still there.

The warning messages only appears when I manually remove the /etc/initramfs-tool/conf.d/resume file.

Please note that there is a change between 0.130ubuntu3.1 and 0.130ubuntu3.2

0.130ubuntu3.1 (/etc/initramfs-tool/conf.d/resume not deleted by hand) : 30s delay at boot
0.130ubuntu3.1 (/etc/initramfs-tool/conf.d/resume deleted by hand) : 30s delay at boot
0.130ubuntu3.2 (/etc/initramfs-tool/conf.d/resume not deleted by hand) : 30s delay at boot
0.130ubuntu3.2 (/etc/initramfs-tool/conf.d/resume deleted by hand) : no delay at boot

Please note that once the /etc/initramfs-tool/conf.d/resume file has been removed neither 3.1 nor 3.2 will re-create it.

I can still reproduce the problem after upgrading to 3.2 and manually deleting /etc/initramfs-tool/conf.d/resume. Help appreciated!

On 06/25/2018 07:56 AM, Silvio Moioli wrote:
> I can still reproduce the problem after upgrading to 3.2 and manually
> deleting /etc/initramfs-tool/conf.d/resume. Help appreciated!
>

Did you run "initrams -u" after deleting the file?

I can confirm that the bug is still there with version 3.2! :-( I did "update-initramfs -u".

Ooops, i was testing with version 3.1! Where can i get version 3.2? It's still not in the update channel

https://wiki.ubuntu.com/Testing/EnableProposed

Thanks! Now tested with versuion 3.2 and the bug is still there. :-(

Daniel, Silvio, can you please confirm that your disk configuration matches
that of Marc, with full-disk LVM selected at install time? It's possible
you have boot delays due to some other cause.

After the update to the latest available version of the package ..

initramfs-tools/bionic-updates,bionic-updates,now 0.130ubuntu3.5 all [installed]

the problem still exists!

Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic

Yes can’t boot into system after updating this morning.

Initramfs

Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic

Seems okay now, after typing exit and following the commands to run the (fsck.ext4 /dev/mapper... something) command that it had listed and following the prompt to fix.

tl;dr: initramfs-tools 0.130ubuntu3.5 and running update-initramfs -u seems to have fixed it.

I have been putting up with this problem for months, thinking it was due to a kernel update (from 4.13 to 4.15). Finally, I find this thread today. Anyhow, here's my info:

OS: Linux Mint 19 (based on Ubuntu 18.04)
Kernel: 4.18.15-041815-generic kernel
initramfs-tools version: 0.130ubuntu3.5
LVM root and swap partitions setup during install
Symptom: waiting 30 sec during boot, with message "failed to connect to lvmetad" ....... "falling back".

After reading previous comments, I did following:
sudo vim /etc/initramfs-tools/conf.d/resume
 .. changed from RESUME=UUID=e6675202-6e2f-4c1b-b6e6-4ffe3ef7c882
 .. to RESUME=/dev/mint-vg/swap_1
sudo update-initramfs -u
  ,, (this indicated that it would only apply to latest kernel, not older ones, which is what I wanted in case it borked my boot)
reboot

It now boots without the 30sec delay, but does display a message about "[something something] disabled by BIOS" or somesuch. This seems to override the mint logo that would normally display during boot if one did not press del to see boot messages.
Note that I only guessed that RESUME=/dev/mint-vg/swap_1 would work, since I do want to be able to resume from sleep, but not sure if that's the correct syntax for the resume file, but it is a valid symlink for my swap partition, the alternatives being /dev/dm-1 and /dev/mapper/mint--vg-swap_1. Resume from sleep still works, not sure if it'd affected by this anyhow.

Finally, I apologise if reporting on mint 19 is not welcome/appropriate here, but it is based on ubuntu 18.04 and I did have relevant info to contribute.

I have this exact same problem too. Upgraded from 16.04 (which ran just fine) to 18.04, now get a 30 second delay before boot, with this "failed to connect to lvmetad. Falling back to device scanning Gave up waiting for suspend/resume" error.

Not sure what help I can be at this point, but should anybody think they could do with additional data in this regard, give me a shout.

I have logged a question about the problem here:
https://askubuntu.com/questions/1097013/error-on-boot-failed-to-connect-to-lvmetad-after-18-04-install

System: Ubuntu 18.04 4.15.0-42-generic #45-Ubuntu SMP

I also was able to fix it with the "=none" and then running update-initramfs -u

I upgraded to ubuntu 18.10 last night, and I had this problem all over again.

Grub with noresume doesn't work
RESUME=none doesn't work
RESUME=/dev/mapper/ubuntu-root doesn't work
RESUME=/dev/mapper/ubuntu-swap doesn't work

changing /etc/initramfs-tools/conf.d/resume to none or to any lvm volume doesn't work.

I always have the lvmetad can't connect, and then the kernel tries to find DHCP leases (now I actually have messages about it unlike 18.04).
After a looooonnng while it ends up booting.

Is there any way I can do a grub boot to stop trying to boot from the network?

I'm still on 18.04, but this problem remains for me, as well.

Grub with noresume doesn't work
RESUME=none doesn't work
RESUME=/dev/mapper/ubuntu-root doesn't work
RESUME=/dev/mapper/ubuntu-swap doesn't work

Just as an additional confirmation, having the full LVM device path inside /etc/initramfs-tools/conf.d/resume like:

RESUME=/dev/vg_system/lv_swap

and running:

sudo update-initramfs -u

fixed the issue (also) for me.

my /etc/initramfs-tools/conf.d/resume file contains one line

RESUME=UUID=99a2d3b2-0f29-4080-977c-35a5744279a8

I have tried several suggestions in this thread but I haven't found anything that works. I tried

RESUME=/dev/vg_system/lv_swap

then I ran the update-initramfs -u, as suggested. I got this:

update-initramfs: Generating /boot/initrd.img-4.15.0-43-generic
W: initramfs-tools configuration sets RESUME=/dev/vg_system/lv_swap
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/dm-1
I: (UUID=99a2d3b2-0f29-4080-977c-35a5744279a8)
I: Set the RESUME variable to override this.

I'm not what to do from here.

Hey Dennis,
the value you put in RESUME variable must match your logical volume path. /dev/vg_system/lv_swap matches mine, but yours might be different. Check with lvdisplay what is the name of your logical volume and then use it inside the resume file.

I'm in 18.10

Adding my volume to the resume file with RESUME=/dev/mapper/ubuntu-swap doesn't work.
Something to add to my story, /etc/initramfs-tools/conf.d/resume did not exist until I created it after reading this.

Also,
I had started using /var/swap/swap.img file for swap, could that have anything to do with it?

My booting time is far greater than 30seconds. It just takes about 3 to 4 minutes if not more.
Any help is greatly appreciated.

Hello Marc, or anyone else affected,

Accepted initramfs-tools into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.130ubuntu3.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Łukasz,

The problem persists.

* installed sha256sum ubuntu-18.04.1-desktopmd64.iso (5748706937539418ee5707bd538c4f5eabae485d17aa49fb13ce2c9b70532433)
* used update-manager to enable proposed-update
* sudo apt-get update
* sudo apt-get install initramfs-tools
(initramfs-tools is now in version 0.130ubuntu3.7)
* reboot
* still showing WARNING:Failed to connect to lvmetad. Falling back to device scanning.

Best regards

Marc

Hello Marc, or anyone else affected,

Accepted ubiquity into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubiquity/18.04.14.11 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Similar issue appears when zram swap is used, see bug #1781746
This bug is already fixed in Debian initramfs-tools ver 0.132, please accept this simple 3 lines patch from Debian into Ubuntu 18.04 LTS
https://salsa.debian.org/kernel-team/initramfs-tools/commit/312393b0cf1231125eeff3d1a2b6b778a935c21d

Hello Brian,

On 1/26/19 12:47 AM, Brian Murray wrote:
> Hello Marc, or anyone else affected,
>
> Accepted ubiquity into bionic-proposed. The package will build now and
> be available at
> https://launchpad.net/ubuntu/+source/ubiquity/18.04.14.11 in a few
> hours, and then in the -proposed repository.

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?

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
<email address hidden>

Installed system using latest bionic daily, which contains ubiquity 18.04.14.11.

There is no /etc/initramfs-tools/conf.d/resume file created, and grepping for RESUME= setting, there are none hardcoded.

> * still showing WARNING:Failed to connect to lvmetad. Falling back to device scanning.

That is NOT the defining symptom of the bug. This message would always be shown. The question is whether there is an unreasonable and unnecessary boot delay after the message is displayed.

This bug was fixed in the package ubiquity - 18.04.14.11

---------------
ubiquity (18.04.14.11) bionic; urgency=medium

  [ Steve Langasek ]
  * scripts/plugininstall.py: don't hard-code a resume partition in
    /etc/initramfs-tools/conf.d/resume at install time. In bionic and later,
    initramfs-tools will autodetect an appropriate resume partition at
    initramfs generation time, so ubiquity's resume setting is redundant and
    possibly wrong. LP: #1768230.

 -- Dimitri John Ledkov <email address hidden> Mon, 21 Jan 2019 20:25:03 +0000

The verification of the Stable Release Update for ubiquity has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Affects me on Ubuntu Budgie 18.04.2 after manually upgrading the kernel to 4.20.10

Hello Steve,

> * still showing WARNING:Failed to connect to lvmetad. Falling back to device scanning.

> That is NOT the defining symptom of the bug. This message would always be shown. The question is whether there is an unreasonable and unnecessary boot delay after the message is displayed.

I have followed the same steps as Marc Pignat (who you quoted) and can confirm that I am still getting the problem. To clarify, I am getting the same unreasonable and unnecessary boot delay after the message is displayed, as I was getting before upgrading the package.

Well, if you're a LVM user i recommend to leave ubuntu/debian. I know this sounds somewhat hard, but this nasty bug inside the ramdisk mouning script exist now more or less since a year! I can't accept a 30 seconds delay on boot for nothing and moved on to other distros.
Yes you can fix it inside the script which will be copied, but with a new package the file will be overwritten without any warning or save/new file.

Time to untrack this bug now. Good luck!

Bug persists on 18.04.2 with kernel 4.18.05-15 and initframfs-tools 130ubuntu3.6. Kernel was upgraded via the HWE stack

Finaly I was able to get rid of the 30s delay.

TL;DR
1. Changed RESUME=UUID=... to RESUME=none in /etc/initramfs-tools/conf.d/resume (removing the file didn't help)
2. sudo update-initramfs -u

---
I've got a custom LVM layout.

$ cat /etc/lsb-release
DISTRIB_ID=neon
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="KDE neon User Edition 5.15"

$ uname -r
4.15.0-45-generic

$ sudo apt-cache policy initramfs-tools
initramfs-tools:
  Installed: 0.130ubuntu3.6
  Candidate: 0.130ubuntu3.6
...

$ sudo cat /etc/initramfs-tools/conf.d/resume
RESUME=none

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-45-generic

$

With "RESUME=UUID..." in /etc/initramfs-tools/conf.d/resume:
[ 3.418544] Btrfs loaded, crc32c=crc32c-intel
[ 3.487208] BTRFS: device fsid ... devid 1 transid 272021 /dev/mapper/vg_00-lv_root
[ 34.587759] BTRFS info (device dm-0): disk space caching is enabled

With "RESUME=none" in /etc/initramfs-tools/conf.d/resume:
[ 3.422572] Btrfs loaded, crc32c=crc32c-intel
[ 3.487216] BTRFS: device fsid ... devid 1 transid 272833 /dev/mapper/vg_00-lv_root
[ 3.501201] BTRFS info (device dm-0): disk space caching is enabled

Hope it helps someone.

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

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

  [ Steve Langasek ]
  * hooks/resume: cherry-pick patch from upstream git to fix
    auto-configuration of resume devices that are on LVM; always refer to
    them by name, never by UUID. LP: #1768230.

  [ Thadeu Lima de Souza Cascardo ]
  * Do not include graphical drivers when FRAMEBUFFER is not set.
    (LP: #1561643)

 -- Brian Murray <email address hidden> Thu, 17 Jan 2019 12:26:22 -0800

18.04 and mint 19 x64 newly installed
5 notebooks with ssd have.

alex@NOUT:~$ systemd-analyze time
Startup finished in 10.388s (kernel) + 8.148s (userspace) = 18.536s
graphical.target reached after 8.134s in userspace

REAL STARTUP TIME 5 MINUTES!
it's really annoy mint 18 n ubuntu 16 work normal.(without systemd?)

systemd-analyze blame
    6.416s NetworkManager-wait-online.service
    3.319s dev-sda1.device
    1.700s vboxdrv.service

[x]alex@NOUT:~$ /etc/initramfs-tools/conf.d/resume
bash: /etc/initramfs-tools/conf.d/resume: Нет такого файла или каталога создал
no file resume,
i create it,update initramfs, but it not helped me
[x]systemctl disable fstrim.timer -this too not helped me
[x]install new kernel - not helped
alex@NOUT:~$ uname -a
Linux NOUT 5.0.0-050000rc1-generic #201901062130 SMP Mon Jan
7 02:32:47 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
alex@NOUT:~$

Issue still persists in initramfs-tools - 0.130ubuntu3.7 version

$18.04.1 LTS (Bionic Beaver)"
$4.15.0-46-generic

$dpkg -l | grep initramfs-tools
ii initramfs-tools 0.130ubuntu3.7
ii initramfs-tools-bin 0.130ubuntu3.7
ii initramfs-tools-core 0.130ubuntu3.7

$cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=115a16f5-bb9a-4ff2-a7b7-cf143deefcd4

RESUME=auto / none works fine as a workaround. Also removing this file "/etc/initramfs-tools/conf.d/resume " also fixed the issue.
I tested on virtual box. tested with 4.15.0.29 generic kernel also.

Then I tried to download ubuntu-18.04.2 LTS Desktop image, and did a fresh installation. Over there I couldn't find the lvmetad problem during startup.

Then I checked the kernel it installed with HWE - 4.18.0.15 and initramfs-tools - 0.130ubuntu3.6 version.

Then tried to download 4.15.0.46 generic kernel and removed the HWE kernel and then rebooted and see the issue persists.

Then tried to install initramfs-tools - 0.130ubuntu3.7 version with 4.15.0.46 generic kernel then the issue resolved.

But in my #92 , i tried with ubuntu-18.04.1 LTS desktop image and installed only initramfs-tools - 0.130ubuntu3.7 over there the delay issue still persist.

So my question, even in my case fresh installation of 18.04.2 works fine even after installed initramfs-tools 3.7 vers. But in fresh installation of 18.04.1 failed after installed initramfs-tools 3.7 vers.

I'm on "Ubuntu 19.04" (disco), with initramfs-rools at version 0.131ubuntu19, and this is still broken for me.

lvdisplay gives /dev/xubuntu-vg/swap_1 as the swap logical volume path and dzVm4y-Xeh5-o9UB-jLnI-0ldX-azSN-9w6QZq as the UUIS.

I've tried separately with /etc/initramfs-tools/conf.d/resume as

RESUME=UUID=dzVm4y-Xeh5-o9UB-jLnI-0ldX-azSN-9w6QZq

and

RESUME=/dev/xubuntu-vg/swap_1

and

RESUME=none

each time running sudo update-initramfs after updating the resume file. But, I always get a 30 second delay and the following in boot.log at the following boot:

  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  Volume group "xubuntu-vg" not found
  Cannot process volume group xubuntu-vg
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  Reading all physical volumes. This may take a while...
  Found volume group "xubuntu-vg" using metadata type lvm2
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  2 logical volume(s) in volume group "xubuntu-vg" now active
/dev/mapper/xubuntu--vg-root: clean, 465752/30736384 files, 67280723/122926080 blocks
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  Volume group "xubuntu-vg" not found
...

This looks likely to be some kind of incompatibility with full-disk encrypted systems. I just spotted that the errors I am getting are not about the swap partition at all, but instead about /dev/mapper/xubuntu--vg-root, which is the encrypted root. From /etc/fstab:

/dev/mapper/xubuntu--vg-root / ext4 errors=remount-ro 0 1

I've tried to boot up the recently upgraded Ubuntu Disco system in the text mode and found, that the delay happens after the script:

1. fails to connect to lvmetad
2. falls back to device scanning
3. probes for btrfs.

I DO NOT have any btrfs volumes in the system so I would like to simply avoid this step. I'd like to keep the ability to hibernate/resume though, that's why I'd prefer to keep all configuration options needed for RESUME.

I will continue to experiment and probably will take a look into the booting script, but maybe the information gathered so far will be useful for someone.

Installed packages [probably related to the problem]:

initramfs-tools_0.131ubuntu19
initramfs-tools-bin_0.131ubuntu19
initramfs-tools-core_0.131ubuntu19
lvm2_2.02.176-4.1ubuntu4
udisks2-lvm2_2.8.2-1
systemd_240-6ubuntu5
btrfs-progs_4.20.2-1

I'm experiencing this on Linux Mint 19.1 fully updated and NOT encrypted disk or home.
This is an LVM install though.

2019 May 15
Ubuntu 18.04 (VM snapshot) - works well.

2019 Sep 04:
$ sudo apt update && sudo apt upgrade -y
...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.0.0-27-generic
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/ubuntu--vg-swap_1)
I: Set the RESUME variable to override this.
/etc/kernel/postinst.d/zz-update-grub:
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.0.0-27-generic
Found initrd image: /boot/initrd.img-5.0.0-27-generic
Found linux image: /boot/vmlinuz-4.18.0-15-generic
Found initrd image: /boot/initrd.img-4.18.0-15-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
done
Processing triggers for initramfs-tools (0.130ubuntu3.8) ...
update-initramfs: Generating /boot/initrd.img-5.0.0-27-generic
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/ubuntu--vg-swap_1)
I: Set the RESUME variable to override this.
Processing triggers for dbus (1.12.2-1ubuntu1.1) ...
$ sudo reboot

Baseline:
Fail:

```
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
/dev/mapper/ubuntu--vg-root: clean, 1934309/4136960 files, 1775141/16522240 blocks
```

Test 00:
# Drop into the shell with ctrl+alt+f3
sudo rm /etc/initramfs-tools/conf.d/resume
sudo update-initramfs -u
sudo reboot

Result: Fail

Test 01:
# Drop into the shell with ctrl+alt+f3
sudo rm /etc/initramfs-tools/conf.d/resume
sudo reboot

Result: Fail

Test 02:
# Add this RESUME config
sudo vim /etc/initramfs-tools/conf.d/resume
RESUME=/dev/mapper/ubuntu--vg-swap_1
# Update
sudo update-initramfs -u

Result: Fail

This is really crippling. Please help! I can't work!

Resolved by tossing the entire VM and then performing a fresh install of the latest Ubuntu Desktop 18.04 with default deviations:

- minimal installation
- NO LVM (this is the default selection)
- do NOT install updates while installing

I get this error on a new minimal VM install with all LVM disks except '/boot':

--
root@img-ults18:/var/log# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 89.1M 1 loop /snap/core/8268
loop1 7:1 0 88.5M 1 loop /snap/core/7270
sda 8:0 0 1G 0 disk
├─sda1 8:1 0 1M 0 part
└─sda2 8:2 0 1021M 0 part /boot
sdb 8:16 0 32G 0 disk
├─VGroot-LVroot 253:0 0 7G 0 lvm /
├─VGroot-LVtmp 253:1 0 3G 0 lvm /tmp
├─VGroot-LVvar 253:2 0 4G 0 lvm /var
├─VGroot-LVvartmp 253:3 0 3G 0 lvm /var/tmp
├─VGroot-VGlog 253:4 0 4G 0 lvm /var/log
├─VGroot-LVaudit 253:5 0 2G 0 lvm /var/log/audit
├─VGroot-LVswap 253:6 0 4G 0 lvm [SWAP]
└─VGroot-LVhome 253:7 0 5G 0 lvm /home
sr0 11:0 1 1024M 0 rom

root@img-ults18:/var/log# pvs
  PV VG Fmt Attr PSize PFree
  /dev/sdb VGroot lvm2 a-- <32.00g 0

root@img-ults18:/var/log# vgs
  VG #PV #LV #SN Attr VSize VFree
  VGroot 1 8 0 wz--n- <32.00g 0

root@img-ults18:/var/log# lvs -a
  LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
  LVaudit VGroot -wi-ao---- 2.00g
  LVhome VGroot -wi-ao---- <5.00g
  LVroot VGroot -wi-ao---- 7.00g
  LVswap VGroot -wi-ao---- 4.00g
  LVtmp VGroot -wi-ao---- 3.00g
  LVvar VGroot -wi-ao---- 4.00g
  LVvartmp VGroot -wi-ao---- 3.00g
  VGlog VGroot -wi-ao---- 4.00g

--
...
0 packages can be updated.
0 updates are security updates.

No mail.
Last login: Thu Jan 9 21:09:04 2020 from 137.82.124.99
root@img-ults18:~#
root@img-ults18:~# apt-get install selinux
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  policycoreutils selinux-policy-dummy selinux-utils
The following packages will be REMOVED:
  apparmor snapd
The following NEW packages will be installed:
  policycoreutils selinux selinux-policy-dummy selinux-utils
0 upgraded, 4 newly installed, 2 to remove and 0 not upgraded.
Need to get 544 kB of archives.
After this operation, 62.7 MB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://mirror.it.ubc.ca/ubuntu bionic/universe amd64 selinux-utils amd64 2.7-2build2 [81.7 kB]
Get:2 http://mirror.it.ubc.ca/ubuntu bionic/universe amd64 policycoreutils amd64 2.7-1 [450 kB]
Get:3 http://mirror.it.ubc.ca/ubuntu bionic/universe amd64 selinux all 1:0.11 [11.2 kB]
Get:4 http://mirror.it.ubc.ca/ubuntu bionic/universe amd64 selinux-policy-dummy all 0.1 [1,730 B]
Fetched 544 kB in 0s (7,670 kB/s)
Preconfiguring packages ...

...

(Reading database ... 102901 files and directories currently installed...