Slow boot process on "waiting for resume device"

[Ceesaxp]

Binary package hint: initramfs-tools

$ lsb_release -rd
Description: Ubuntu hardy (development branch)
Release: 8.04

$ uname -a
Linux andrei-eee 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 GNU/Linux

dmesg output attached; the system was apt-get dist-upgrade'ed to Hardy from Gutsy.

When booting generic kernel, splash screen freezes after about 10 seconds of normal boot and stays this way for about a minute or so. When using recovery boot option the out put shows that boot process is stuck after launching local-premount scripts with following message:

   Begin: Waiting for resume device ...

After a while it gets through and proceeds with the rest of boot process. There were no issues like this on Gutsy. Hardy's 2.6.22-14 kernel/initrd do not exhibit this behavior (or do so to a much lesser extent).

[Lowell Alleman (lowell-alleman)]

I'm having the same issue.

You may want to check and see if the local-premount script is actually waiting for the right device. I found that my system had an incorrect UUID in the resume configuration file: /etc/initramfs-tools/conf.d/resume This file doesn't appear to have been changed as part of the Hardy upgrade on my system, based on the file modification time, so something else must have also changed due to the upgrade. I'm curious as to when/how this file is created and updated. I've had to reformat my swap partition several times in the past (the kernel kept telling me my swap had an invalid signature), so maybe the resume config file was never updated. Perhaps it is never updated after the first install?

You can check the UUIDs with stuff like this:
cat /etc/initramfs-tools/conf.d/resume | cut -b13-
cat /etc/fstab | grep swap | head -1 | cut -b6-41
ls -l /dev/disk/by-uuid/

I'm not all that familiar with the initrd stuff, but I am surprised that my system is attempting to look for a resume device, since I had disabled suspend/resume. I removed the "resume=<dev>" boot parameter via the grub configuration file. I glanced over the resume startup script, or at least what I think is the correct startup script (/usr/share/initramfs-tools/scripts/local-premount/resume), and it does not appear to check the kernel command line (/proc/cmdline) for the "resume=" parameter, of course, I'm not even sure if /proc is mounted at that point in time...

Does anyone know if there is there a better (more official) way to disable resume?

[Jeremy Visser (jeremy-visser)]

I don't like the fact that the resume UUID gets built into the initramfs (at least, that's what I pick up from reading this) as my swap partition's UUID changes every few days for some weird reason. Is it possible to write the resume partition into a file on the hard disk (something like /etc/pm-resume-device) and that gets read by the initramfs on bootup?

Or don't we want to mount anything until we're resumed? I guess if that's a problem, it could be mounted read-only to avoid corrupting the journal.

[Lowell Alleman (lowell-alleman)]

Yeah, the whole pre-boot environment is intentionally limited and simplistic, from what I understand. So I would guess that reading from /etc/ during boot isn't really an option.

I think the right approach would be to determine why your swap keeps getting modified and resolve that issue. Have you looked for any related bug reports for that issue?

That said, one possible workaround might be to just keep recreating your swap partition with the same UUID each time. You could just stick it in a script and re-run it whenever your swap partition gets corrupted; or even have it run at system shutdown time:

    mkswap -U UUID /dev/swapdev

(Side note: It appears that the "-U" option is new to mkswap. I had a similar issue with my swap partition in 7.10, but ended up using a somewhat complicated script to update a whole bunch of config files because I had to keep using new UUIDs.)

Hope that helps,

- Lowell Alleman

[Murz (murznn)]

I'm having the same issue too on Kubuntu 8.04 KDE4 release. In Gutsy system boots normally without waiting for image.

I found that /etc/initramfs-tools/conf.d/resume file have an incorrect UUID, I change it ot UUID of swap partition but this isn't help.
What does the system waits 15 or more seconds when booting?

[Lowell Alleman (lowell-alleman)]

Double check the contents of your "/etc/initramfs-tools/conf.d/resume"
file. Mine looks like this:

RESUME=UUID=fd24b8a2-61c0-4c97-961e-e5e89777cca8

If that looks good, then you can use this command to check that such a
device actually exists. This will show any typos when copying the UUIDs, I
know I've made that mistake a few times dispite being very careful.

   sudo /lib/udev/vol_id /dev/disk/by-uuid/`cat
/etc/initramfs-tools/conf.d/resume | cut -b13-`

Note: The "vol_id" command is what the startup "resume" script is using to
check that your swap partition exists. So if this command fails, then it
will not find your swap partition at boot either thus causing the statup
delay.

Here is the output that I got on my system (of course, the UUIDs will be
different from yours)

ID_FS_USAGE=other
ID_FS_TYPE=swap
ID_FS_VERSION=2
ID_FS_UUID=fd24b8a2-61c0-4c97-961e-e5e89777cca8
ID_FS_UUID_ENC=fd24b8a2-61c0-4c97-961e-e5e89777cca8
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=

[Jeremy Visser (jeremy-visser)]

Murz, after changing the config file, you have to regenerate your initramfs.

$ sudo update-initramfs -u

[mamue (mathe-mueller)]

hi there,
I'm having the same problems with the break at: 'Begin: Waiting for resume device'. But none of the hints up there did change anything in speeding up ma boot-time.

I'm using a toshiba satellite m30 laptop with the phoenix bios.

Does anybody know anything else to prevent that pausing during boot?

[aldebx (aldebx)]

This behavior is caused by the fact that you have somehow modified your swap partition (new linux setup? new hard disk? swap partition resize?) and thus initramfs-tools cannot find the swap/resume partition through the old UUID.

Summing some of the advices given here and there

1. first make the swap partition work again by
sudo mkswap /dev/sda9
(where sda9 should be the corresponding partition on your system. Check gparted to ensure this. This will DESTROY all your data if you use it on a data partition, like your /home one)

2. then compute the UUID of the new swap partition
sudo blkid /dev/sda9

3. change the UUID code in both these files
/etc/fstab
(only change the one concerning /dev/sda9!)
/etc/initramfs-tools/conf.d/resume

4. rebuild the initramfs with
update-initramfs -u

5. reboot

You can also change back the swap UUID with this command (thanks Lowell)
    mkswap -U UUID /dev/swapdev
where UUID is the ID shown in both mentioned /etc files (the ID should be the same in both them, otherwise follow the 1-3 steps!)

[mamue (mathe-mueller)]

hi aldebx!

the hints you gave me solved the problem!

thanks a lot!