My first install did not include LVM and took about 15 seconds after BIOS to boot. My second install included LVM and took about 45 seconds after BIOS to boot. After much Googling the general consensus seems to be that this is a bug in which choosing LVM while using "certain" SSD's during installation will cause a long boot while the system looks for and does not find a swap file. The timeout is 30 seconds. Has anyone found a work around for this?

  • Could you please edit your question to include the content of /etc/fstab and the output of sudo lsblk -f? Thanks. – David Foerster Jul 10 at 8:42

Try either of the following two methods, or both.

First method

Verify how long the kernel boot time is by opening a terminal and typing:

systemd-analyze

The wait-for-root in /usr/share/initramfs-tools/scripts/local times out after expiring 30 seconds (slumber value). The dev_id variable is assigned the value of RESUME which is defined at /etc/initramfs-tools/conf.d/resume. This UUID which is assigned to RESUME is the UUID of LVM swap partition. Assign device file path of LVM swap partition to RESUME and use wait_for_udev instead of wait-for-root.

To do this, type (in the terminal):

sudo sed -e 's/^RESUME=/#RESUME=/g' \
   -i /etc/initramfs-tools/conf.d/resume

After that is finished, type:

echo "RESUME=/dev/mapper/ubuntu--YOUR FLAVOR OF UBUNTU HERE--vg-swap_1" | \
sudo tee -a /etc/initramfs-tools/conf.d/resume

Recreate initrd and reboot system.

sudo update-initramfs -u

After that is finished, type:

sudo reboot

The kernel boot time should be faster. Verify by typing:

systemd-analyze

You will also be able to use hibernation after this.

(Source)

Second method

Navigate to /etc/initramfs-tools/conf.d/

Right click on "resume" and choose Edit as Administrator. Change the line

RESUME=UUID=<WHATEVER YOUT NUMBER IS>

(e. g. RESUME=UUID=67b3fe6f-1ec4-413f-8c5a-1136bc7f3270) to:

RESUME=none

Now open a terminal and type:

sudo update-initramfs -u

After that is finished, type:

sudo reboot

The kernel boot time should be faster. Verify by typing:

systemd-analyze

(Source)

  • 1
    Because link targets can vanish and we want the content here to still work, please add to this answer the details from those links on how to improve things. – Chai T. Rex May 19 at 4:57
  • The first method worked for me. Make sure you include you flavor of Ubuntu not capitalized (ex - mate). I went from 42.811s to 10.612s. The second method after the first did not do anything more for me. – Dave May 19 at 7:21
  • Hello David. Thank you for your very timely and detailed reply. I was not able to implement either of your methods because my new installation of 18.04 does not have the files that are to be edited. I'm new to Linux and that may answer why I might have missed something. – wirebender May 20 at 19:27
  • Hello again, sorry, I hit return and my input was posted. As I said, newbe. After posting my question I decided the problem was that there was no swap partition so I used GParted to make one and format as swap. I made note of the UUID and added a line in fstab to mount it during boot. I also disabled all swap files and partitions with swapoff. I then enabled the partition I added and my boot time went back to about 17 seconds after BIOS. – wirebender May 20 at 19:31
  • Still no hibernation, though. Suspend sort of works. I have to hit the power button to resume. My USB keyboard and mouse won't cause a resume. – wirebender May 20 at 19:35

Disclaimer: at the time of writing, I haven't enough reputation to comment other answers, so I must enter a new one (mainly as a reference for myself)

I had a similar issue on a fresh Ubuntu install, with bare metal install booting in ~15s while the boot on a LVM install took ~50s (with a pause of about 30s on a black screen).

A first call to sudo systemd-analyze blame pointed out that I had another problem:

$ sudo systemd-analyze blame
     40.699s snapd.seeded.service
     ...

That I have been able to solve thanks to this other Q&A: Long boot delay on Ubuntu loading/splash screen following regular dist-upgrade on clean SSD install (18.04) by installing rng-tools and defining HRNGDEVICE=/dev/urandom as input source for random data in /etc/default/rng-tools.

This solved the snapd entropy issue:

$ sudo journalctl -u snapd.seeded.service --since today
  -- Logs begin at Tue 2018-08-21 18:22:53 CEST, end at Tue 2018-08-21 19:40:09 CE
  # Before: ~40s
  Aug 21 18:22:54 zen systemd[1]: Starting Wait until snapd is fully seeded...
  Aug 21 18:23:36 zen systemd[1]: Started Wait until snapd is fully seeded.
  Aug 21 18:50:18 zen systemd[1]: Stopped Wait until snapd is fully seeded.   
  -- Reboot --
  # After: <1s
  Aug 21 18:51:19 zen systemd[1]: Starting Wait until snapd is fully seeded...
  Aug 21 18:51:19 zen systemd[1]: Started Wait until snapd is fully seeded.
  ....

But the kernel still took ~35s to start so I went through the "Idiot Proof" way of nils-fenner, it did not work at first but after mixing with the first solution from Arni and David I finally managed to lower down starting time to ~10s.

So for (my own) reference, here is my version of a safe path to solve the issue:

 $ cd <whatever back up folder on your machine>
 # backup initial config
 $ cp /etc/initramfs-tools/conf.d/resume .

 # Retrieve the correct path to the swap partition (for manually configured LVMs)
 $ sudo fdisk -l

   ... some partitions

   Disk /dev/mapper/vg_zen-uswap: 4 GiB, 4294967296 bytes, 8388608 sectors
   Units: sectors of 1 * 512 = 512 bytes
   Sector size (logical/physical): 512 bytes / 512 bytes
   I/O size (minimum/optimal): 512 bytes / 512 bytes

   ... some more partitions

 # Update the "resume" file with the new path
 # Caution "vg_zen-uswap" is for *my* machine only :)
 $ echo "RESUME=/dev/mapper/vg_zen-uswap" | sudo tee /etc/initramfs-tools/conf.d/resume
   RESUME=/dev/mapper/vg_zen-uswap   

 # Recreate initrd
 $ sudo update-initramfs -u 
   update-initramfs: Generating /boot/initrd.img-4.15.0-32-generic

 # reboot

That has done the trick for me. HTH.

Seems like the second way described above does not work in general. Also I recommend a little more "idiot proof" way to avoid accidentally overriding the swap UUID.

sudo -i    #become root
cd /etc/initramfs-tools/config.d
mv resume resume.uuid
echo "RESUME=/dev/mapper/YOUR UBUNTU FLAVOUR HERE--vg-swap_1" > resume
#Example: echo "RESUME=/dev/mapper/lubuntu--vg-swap_1" > resume

update-initramfs -uk all
sync && reboot

Now we can simply switch back and forth by renaming the two files.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.