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

Bug #1768230 reported by Marc Pignat on 2018-05-01
268
This bug affects 52 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
High
Steve Langasek
Bionic
Undecided
Unassigned
ubiquity (Ubuntu)
High
Unassigned

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

Related branches

Marc Pignat (swid) wrote :
Marc Pignat (swid) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Marc Pignat (swid) wrote :

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

Peter Valdemar Mørch (pmorch) wrote :

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

Peter Valdemar Mørch (pmorch) wrote :

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

Rigoberto Sanchez (sanch1) wrote :

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

Janne Snabb (snabb) wrote :

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.

Marc Pignat (swid) wrote :

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

Lorenz Pressler (kennerblick) wrote :

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.

thinkpad (fellowsgarden) 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) ?

Marc Pignat (swid) wrote :

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
>

Farzad E. (dnetguru) wrote :

Facing the same issue with multiple clean installs of bionic on esxi hosts.

The warning message persists even after adding `noresume` to the kernel command line!
I also tried changing `use_lvmetad` to 0 in `/etc/lvm/lvm.conf` and removing `/etc/initramfs-tools/conf.d/resume` and updating initramfs with no luck!

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.

Rick Carassai (r-carassai) wrote :

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?

Alexander (azol) wrote :

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

Groobson (groobson) wrote :

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

tags: added: rls-bb-incoming rls-cc-incoming
Marc Pignat (swid) 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?

affects: ubiquity (Ubuntu) → initramfs-tools (Ubuntu)
sonicsteve (slougheed-bcs) wrote :

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.

Steve Langasek (vorlon) on 2018-06-14
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
Steve Langasek (vorlon) wrote :

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.

Changed in ubiquity (Ubuntu):
importance: Undecided → High
status: New → Triaged
Steve Langasek (vorlon) on 2018-06-15
Changed in initramfs-tools (Ubuntu):
status: Confirmed → In Progress
importance: Undecided → High
Steve Langasek (vorlon) on 2018-06-15
description: updated
Steve Langasek (vorlon) on 2018-06-15
Changed in ubiquity (Ubuntu):
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :

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

Changed in initramfs-tools (Ubuntu):
status: In Progress → Fix Released
Marc Pignat (swid) wrote :

@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

Marc Pignat (swid) wrote :

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!

Changed in initramfs-tools (Ubuntu Bionic):
status: New → Fix Committed
tags: added: verification-needed verification-needed-bionic
Marc Pignat (swid) wrote :

[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.

tags: added: verification-failed-bionic
Marc Pignat (swid) wrote :

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

Steve Langasek (vorlon) wrote :

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'?

Steve Langasek (vorlon) wrote :

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.

Ubuntu QA Website (ubuntuqa) wrote :

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

tags: added: iso-testing
Marc Pignat (swid) wrote :

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.

Marc Pignat (swid) wrote :

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.

Silvio Moioli (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!

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

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

Steve Langasek (vorlon) wrote :

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.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 18.10.4

---------------
ubiquity (18.10.4) cosmic; urgency=medium

  [ Chen-Han Hsiao (Stanley) ]
  * Add efivars to mountpoints loaded at bootloader install time.
    (LP: #1772374)

  [ 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.

  [ Łukasz 'sil2100' Zemczak ]
  * Make sure that grub-pc is not removed after installation for both EFI and
    legacy BIOS cases as we now technically need it even for EFI installs.
    (LP: #1775743)

  [ Mathieu Trudel-Lapierre ]
  * Automatic update of included source packages: grub-installer
    1.128ubuntu9.

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 25 Jun 2018 13:57:40 -0400

Changed in ubiquity (Ubuntu):
status: In Progress → Fix Released

@Steve I'm using another LVM setup, which i created manual while using Ubunuts live system ;-)
I wrote this in my first comment already. But basicly i was the same problem with the "30 seconds" problem and my system falls back twice to scanning devices :-(.

But to be honest, yes, i don't in this case and you can ignore me.

Andreas (aec67) wrote :

May I add a comment to this bug as this was marked on bug 1763611 to be a duplicate of this.

I can confirm comment #10 here. I got long boot time after upgrading from Ubuntu 16.04 LTS to 18.04 LTS but there was one release in between. I just followed the update announcements.

I use Mate.

I don't use LVM.1763611

I did solve my problem by editing /etc/initramfs-tools/conf.d/resume.

You can also read my comments #30 and #31 on bug 1763611. Maybe you find it helpful.

Andreas

I've tested this on a system while testing the other SRU that goes with this upload (bug 1769682). I don't have any delays with the SRU installed, and see no lvmetad warnings. I do have an /etc/initramfs-tools/conf.d/resume file that points to my swap partition, but that doesn't seem to adversely affect the behavior at all.

Heiko Sieger (h-sieger) wrote :

I ran into the same bug (30 sec boot delay) running Bionic with Mate desktop.

The following steps solved the problem for now:

1. Edit /etc/initramfs-tools/conf.d/resume

2. Change as follows:
RESUME=none

3. Run
sudo update-initramfs -u

4. Reboot - no more delay

Dan Aur (dan45) wrote :

Hello everyone,

I'm struggling for a few days to find a solution to my problem on a ubuntu 18.04
I have tried all the suggestions on many forums, but unfortunately I have not found a simple solution to solve this problem.

I have recently upgraded Ubuntu 16.04 to Ubuntu 18.04 with enabling full disk encryption and with LVM. After this upgrade, every time I'm starting the machine, I see some messages appearing on the boot screen.

(for more details, please see the attached photo)

I need yours precious help, I hope someone help me with a simple solution!

Please let me know,
Dan.

icyrock.com (icyrock-com) wrote :

I am using a custom LVM setup. Similar to what https://launchpad.net/~daniel-mehrmann described in https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1768230/comments/42.

I've manually installed the debs from https://launchpad.net/ubuntu/+source/initramfs-tools/0.130ubuntu3.2/+build/15032391:

initramfs-tools-bin_0.130ubuntu3.2_amd64.deb (13.3 KiB)
initramfs-tools-core_0.130ubuntu3.2_all.deb (46.7 KiB)
initramfs-tools_0.130ubuntu3.2_all.deb (9.1 KiB)

$ apt list initramfs-tools -a
Listing... Done
initramfs-tools/now 0.130ubuntu3.2 all [installed,local]
initramfs-tools/bionic-updates,bionic-updates 0.130ubuntu3.1 all
initramfs-tools/bionic,bionic 0.130ubuntu3 all

I've followed https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1768230/comments/45 and there's no 30s delay anymore.

Thanks https://launchpad.net/~vorlon and others!

jnns (jnns) wrote :

initramfs-tools-0.130ubuntu3.2 seems to remove the wait time on my system as well!

What I did:

> rm /etc/initramfs-tools/conf.d/resume
> sudo update-initramfs -u

ZhangWenChao (zhangwenchao) wrote :

> rm /etc/initramfs-tools/conf.d/resume
> sudo update-initramfs -u

I tried this method, but the bug still exists

ZhangWenChao (zhangwenchao) wrote :

Ubuntu 18.04.1

It takes a long time to boot, then enter the password to unlock the disk.

Giancarlo (giancast-i) wrote :

I tried today Aug 5, 2018 to upgrade from 16.04 to 18.04. I have been using 16.04 in this machine for the last 10 months without any issues. Installed from LiveCD. I did the upgrade not the LiveCD. It went through the entire upgrade/installation without any issues. It finished and asked to reboot. After it rebooted and after the Dell logo the screen went blank and I could see text popping up on the top left corner of the display, disappearing, popping up again. This repeats every 2-3 seconds. The message is
"Gave up waiting for suspend/resume device
/dev/sda2/: clean, 213855/14712832 files, 3013745/58847488 blocks". This message keeps appearing continuously. Did not wait 30 seconds to see if it rebooted (my fault for not being patient). I tried the 16.04 LiveCD to try to fix. Changed the conf.d resume to RESUME=none as suggested by someone, did not work. So had to do a clean re-install of 16.04 again.
My machine is a Dell Inspiron 15 5000 series with Intel Core i5 8th Gen.

Keith (krussell-jbar) wrote :

Same issue - only latest Ubunutu updates and OS (GUI based) as of today. Did following:

> rm /etc/initramfs-tools/conf.d/resume
> sudo update-initramfs -u

Resume file is gone and issue still happens. Please help with any other solutions to this issue.

guillermo (gfarfanp) wrote :

Used Ubuntu 18.04 in my 8 year old Toshiba Satellite L675 laptop for months without issues, progressed to 18.04.1, no problems, until upgraded to kernel 4.15.0-32-generic 2 days ago, then, same bug as described. only in my case the waiting didn't finished automatically so I had to manually hit the keyboard to obtain a message for press the Enter key to boot. I fixed it editing /etc/initramfs-tools/conf.d/resume to RESUME=none and then regenerating initramfs with sudo update-initramfs -u. Now I boot again without delays.

Keith (krussell-jbar) wrote :

Is there a way to re-create the resume file? The commands I mentioned earlier removed it, so I can't try the edit option.

Christian Zettel (ccztux) wrote :

For me it looks like, that steve's patch got lost in version 3.3 of initramfs-tools:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/0.130ubuntu3.3

When will this patch be released?

Manuel Rösel (manuel-roesel) wrote :

I had the same problem after the update from 16.04 to 18.04. I was able to solve this with RESUME = none and sudo update-initramfs -u.

Christian Zettel (ccztux) wrote :

I have installed a fresh system (Ubuntu 18.04, with LVM) on a virtual machine and this machine is also affected.

I have updated the initramfs-tools to version: 0.130ubuntu3.3 but this doesnt solve the issue.

Other things i have done without success:

1.) Delete resume file:
> rm /etc/initramfs-tools/conf.d/resume
> sudo update-initramfs -u

2.) Change resume file:
> vim /etc/initramfs-tools/conf.d/resume
RESUME=none
> sudo update-initramfs -u

3.) Another change to the resume file:
> vim /etc/initramfs-tools/conf.d/resume
RESUME=auto
> sudo update-initramfs -u

WeeHong Yeo (weihong-85) wrote :

Hi, I am running Lubuntu 18.04 with LVM as a VM in VirtualBox 5.2.18 r124319.

I encountered the above problem and I triedusing guillermo suggestion of

1. editing /etc/initramfs-tools/conf.d/resume to RESUME=none
2. regenerating initramfs with sudo update-initramfs -u

and it seems to fix it for me.

Kilian Felder (k.felder) wrote :

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

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

the problem still exists!

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

Daniel (danposp) wrote :

I can confirm that the bug is back in initramfs-tools 0.130ubuntu3.3 (it was OK with 0.130ubuntu3.2)

The difference is even visible when running update-initramfs -u -k all (on 3.2 you see LVM name, on 3.3 you see UUID).
with initramfs-tools 0.130ubuntu3.2:
update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.15.0-34-generic
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/vg_system-lv_swap)
I: Set the RESUME variable to override this.

=> no delay while booting

and with initramfs-tools 0.130ubuntu3.3:
update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.15.0-34-generic
I: The initramfs will attempt to resume from /dev/dm-1
I: (UUID=c2849fd0-bfeb-11e8-82df-e63cc106402d)
I: Set the RESUME variable to override this.

=> delay 30s while booting

Janne Snabb (snabb) wrote :

I agree. It appears that version 0.130ubuntu3.3 is broken again.

When looking at the changelog here: http://changelogs.ubuntu.com/changelogs/pool/main/i/initramfs-tools/initramfs-tools_0.130ubuntu3.3/changelog

...and comparing it to the changelog at: http://changelogs.ubuntu.com/changelogs/pool/main/i/initramfs-tools/initramfs-tools_0.130ubuntu3.2/changelog

...it looks like the Steve Langasek's fixes introduced in version 0.130ubuntu3.2 to fix this bug are lost in package version 0.130ubuntu3.3.

Changed in initramfs-tools (Ubuntu Bionic):
status: Fix Committed → Confirmed
Kilian Felder (k.felder) wrote :

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

Jim Keller (bellusterra) wrote :

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

Jim Keller (bellusterra) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers