Deleted a partition, now getting 'Gave up waiting for suspend/resume device' message during boot

Question

I've recently deleted a partition around 8GB in size. This partition was located after the main partition, but seems to not be critical as I can still boot the OS and run all the applications.

The boot process now takes an extra two-minutes to complete, displaying the following messages:

Gave up waiting for suspend/resume device
/dev/sda4: clean, .../... files .../... blocks
[ ***] A start job is running for dev-disk-by\.....\....\... .device
Dependencies failed!

My question is:

What was this second partition, and how can restore or recreate it?

Solution 1

I just encountered that same error message on Debian and a similar boot delay, with a slight variation: I knew that I had just voluntarily deleted my swap partition, and didn't plan to recreate it.

The partition was no longer listed in /etc/fstab but the delay persisted. Nothing in /etc/initramfs-tools/conf.d/resume (Thanks @KamilMaciorowski for the hint).

The key was to figure out that the initial RAM disk is "compiled", and in some case (like this), must be regenerated. Solution: sudo update-initramfs -u.

Solution 2

Because of the message

Gave up waiting for suspend/resume device

I suspect a problem with your swap partition. Check if your system uses swap by running swapon. Next run swapon -a and observe the output. It may complain with cannot find the device message. If so, you will know you should recreate your swap partiton.

The procedure:

Refer to a previous question: How do I restore a swap partition I deleted?

1. Modify your partition table with fdisk, gdisk, gparted or another equivalent tool. Recreate the partition entry. The partition type should be 0x82 Linux swap.
2. Set the partition up with mkswap.
3. Modify your /etc/fstab accordingly (the previous output from swapon -a should tell you which entry you need to change in case you're not sure).
4. Important: Replace the UUID in /etc/initramfs-tools/conf.d/resume, with that used in the above step.
5. Run update-initramfs -u.

Solution 3

In my case, the boot message looked like this. The swap partition was deleted.

Gave up waiting for suspend/resume device
/dev/sda4 ... ...

[***] A start job is running for dev-disk-by\...\...\...\.device
...
...
...

First, look at the content of your fstab file, cat /etc/fstab will return this kind of output

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda4 during installation
UUID=8c1977eb-ac90-426b-bc9b-a7fb2ec8d760 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda3 during installation
UUID=00fd67-123DE-4b98-aa17-2d4025aed54 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Then you notice , "swap was on /dev/sdax during installation".

Recreate the deleted partition (fdisk or Gparted for instance), then use this command to find the new uuid of the partition.

ls -l /dev/disk/by-uuid/

This outputs:

total 0
lrwxrwxrwx 1 root root 10 févr. 19 07:18 00151dcd-2bf5-4b98-aa17-8f40ef4cfd86 -> ../../sda4
lrwxrwxrwx 1 root root 10 févr. 19 07:18 6C5A1AC45A1A8B4A -> ../../sda2
lrwxrwxrwx 1 root root 10 févr. 19 07:18 8c1977eb-ac90-426b-bc9b-a7fb2ec8d760 -> ../../sda3
lrwxrwxrwx 1 root root 10 févr. 19 07:18 C064106664106188 -> ../../sda1

Update your fstab with the correct uuid that were displayed by the last command by copy/pasting the adequate uuid of the swap in the fstab file. Then reboot, It should correct the problem.

Comments

[G Cab]

In my case, /etc/initramfs-tools/conf.d/resume contained an old UID reference for the swap. . update-initramfs -u solved the matter. thanks.

[maninak]

In my case, the above answer hinted me that my recently formated+encrypted (with veracrypt) partition probably failed to mount and all I had to do was sudo nano /etc/fstab and then comment-out (prefix with a #) the line referring to the partition I encrypted.

[Apropos]

In my case, find /boot/vmli* listed 5 available kernels and uname -r showed my system uses 5.13.0-27-generic. Beware that update-initramfs -u will only update the latest kernel, I needed update-initramfs -u -k all.