46

After upgrade from Ubuntu 17.10 to 18.04 the bootprocess takes 30s longer than before.

it stops for 30 seconds at the step

Begin: Running /scripts/local-premount

Then it continues.

At first it continued one step further to

scanning for btrfs file systems

so I uninstalled btrfs support, but that didn't help with the problem.

I see no notice of that step neither in dmesg nor in var/log/boot.log

How can I debug this problem? Can I enable additional logging?

3 Answers 3

79

Try the following:

  • open /etc/initramfs-tools/conf.d/resume
  • replace RESUME=UUID=xxx with RESUME=none
  • issue sudo update-initramfs -u
  • reboot your system

(create the file if it does not exist and just add RESUME=none in it)

The file should contain the UUID of your swap partition, you can check this with sudo blkid | grep swap.

I found the following bug on launchpad which is supposed to be Lubuntu specific but the commands above also resolved the same issue on my Xubuntu installation.

See comments #27 and #28.

This file seems to be related to hibernate/suspend, I can confirm suspend still works on my system after the changes.

8
  • 3
    thanks, that worked! I also posted your solution here: unix.stackexchange.com/a/443272/20661
    – rubo77
    May 16, 2018 at 21:39
  • I removed my swap parition manually before upgrading, but I guess it was still remembered somewhere as the RESUME field was set to the old UUID. Setting it to none shaved at least 30s from my bootup time! Top!
    – Michel
    Jun 9, 2018 at 10:03
  • 1
    For me the issue was that I didn't have a swap partition at all (no idea how that happened). I fixed my problem by creating a swap partition and adding it to the file as described in this answer.
    – tjespe
    Nov 26, 2018 at 15:45
  • 1
    Do not add a backup or save a renamed copy of that file in the same directory. I did that, and it still tried using resume=UUID when I ran initramfs. Removing the copy fixed it, so I'm assuming it scans all files in that directory.
    – user697440
    Apr 30, 2019 at 18:03
  • 1
    Just want to note that deleting RESUME=UUID=xxx also seems to fix the problem (or deleting the entire file if the only thing it contains is RESUME=UUID=xxx). Also FYI the RESUME variable is discussed in the initramfs-tools man page. manpages.ubuntu.com/manpages/xenial/man8/initramfs-tools.8.html Oct 18, 2022 at 14:46
11

In my case, the hang at Running /scripts/local-premount was caused by grub configs. So the workaround that I found is updating GRUB_CMDLINE_LINUX config to noresume. Type this in your terminal:

sudoedit /etc/default/grub

Find GRUB_CMDLINE_LINUX and change its value to noresume.

GRUB_CMDLINE_LINUX="noresume"

If you don't find that line, you can add it at the end of file. You can update the default one, too:

GRUB_CMDLINE_LINUX_DEFAULT="noresume"

For me, I did both. Save the configs. Then update the grub:

sudo update-grub

Reboot the computer. It should now be faster. Btw, you can combine noresume with quite and splash, if you use splash boot.

See also related answers on askubuntu and superuser, as well as documentation about this parameter on linuxtopia

1
  • 1
    This will prevent suspend-to-disk and resume. (Can also be done by uninstalling ...resume... probably.) But thanks for the hint, I disabled resume from command prompt, and could boot once to fix my problems.
    – simohe
    Jun 15, 2020 at 13:40
1

I had the same problem with all the install of Ubuntu.

I'm using LVM with swap on a LV.

On a desktop /etc/initramfs-tools/conf.d/resume is referring to an UUID which avoid the possibility to hibernate.

On a Server /etc/initramfs-tools/conf.d/resume does not exists after install and introduce delay at boot and/or lvmetad error.

sudo su -c 'echo RESUME=/dev/mapper/the_swap_LV_name > /etc/initramfs-tools/conf.d/resume' 
sudo update-initramfs -u

https://launchpad.net/bugs/1768230

No more delay at boot or lvmetad error.

Kind Regards

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .