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?

rubo77
  • 32,486

3 Answers3

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.

rubo77
  • 32,486
mt7
  • 906
  • 3
    thanks, that worked! I also posted your solution here: https://unix.stackexchange.com/a/443272/20661 – rubo77 May 16 '18 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 09 '18 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 '18 at 15:45
  • I'm not sure what do you mean with "The file should contain the UUID...". I have two TYPE="swap" UUID, the real (/dev/sda6) and the mapped (/dev/mapper/cryptswap1). Maybe this happen if you don't have swap partition OR its encrypted. Anyway, I left the =none and everything works fine now. – Pablo Bianchi Dec 24 '18 at 03:36
  • 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. –  Apr 30 '19 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. https://manpages.ubuntu.com/manpages/xenial/man8/initramfs-tools.8.html – Mark Doliner Oct 18 '22 at 14:46
  • The problem with this method is that when the "update-initramfs-tools -u" is executed, in my case, it output the following: Generating /boot/initrd.img-5.15.0-56-generic. This implies that the next time the kernel gets updated, which should also change the version number in initrd.img, then this entire procedure has to be re-done. If what I said is true, then would there be any other way of overcoming the problem of 30s delay? – Ram Sambamurthy Feb 16 '23 at 03:31
  • For me adding an existing UUID to that file also worked, as I previously had deleted my SWAP partition, making the stored UUID invalid. – Lampe2020 Dec 04 '23 at 22:30
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

xeruf
  • 412
fsevenm
  • 743
  • 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 '20 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

moocan
  • 21