Gave up waiting for suspend/resume device ubuntu 22 framework 12 gen

anybody else experiencing intermittent boot issue on ubuntu 22 with framework 12 gen?

in roughly 50/50 boot attempts boot hangs and results in this message

“gave up waiting for suspend/resume device” followed by shell.

A workaround is to modify grub on the fly (‘e’ → crtrl-x) and replace resume with noresume.

It never happens when booting from hibernation. So in a way hibernate before power off in another workaround, but not ideal.

Anybody found a permanent resolution?

I am on ubuntu mate 22.04 and don t have boot problems at all.
What usb c modules do you have?
Have you tried unplugging all of them ?

Hi @Maciek_Kolesnik,

Wanted to clarify some things.

  • Ubuntu 22.04 or 22.10?
  • Suspend or hibernate? You indicated both, so I wanted to be absolutely sure.
  • Any external monitors or Bluetooth devices attached or connected?

Its 22.04

Messgage is as i quoted.

Workaround is via hibernation

No extra monitors and no blue tooth

I have never had this problem on my Kubuntu 22.04 system running kernel 5.19.17. However, I think that we might be booting with different grub/Linux options. This is my /proc/cmdline:

BOOT_IMAGE=/boot/vmlinuz-5.19.17-051917-generic root=UUID=4b30f456-fda2-4eac-8d39-47087f92bace ro quiet splash mem_sleep_default=deep nvme.noacpi=1 vt.handoff=7

i have micro sd 2x usbc and 1xusba. will experiment by removing microsd reader

more /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.15.0-53-generic root=UUID=433da999-5abe-4d93-91eb-5d3
d104f57cb ro quiet splash resume=UUID=80bde57a-015f-4f42-bd63-a9a86a38d6e6

I run 22.04 on mine and I do not have any issues with resuming from standby (or hibernation after updating the kernel temporarily until the LTS kernel caught up).

I have a storage expansion drive, 1 USB A, and 2 USB C expansion slots.

My testing last night. 11 hours suspended. No applications running during suspend. No external monitors attached.

Fedora 37 is 81%, TLP only (Gnome power profile removed), 2 USB C, hdmi, DP. 12th Gen. s2idle deep.

Pop OS 24.04 at 61% system76-power only, USB C, hdmi, s2idle deep.

Ubuntu 22.04 at 89% TLP only (Gnome power profile removed), USB C, hdmi, 12th Gen. s2idle deep.


Just to be clear, the boot issue ONLY happens after proper shutdown or reboot.
As i mentioned in my original post, boot from hibernation/suspence is all working well.

It sounds counterintuitive but that’s what’s happening.

I failed to mention that my swap is setup as a partition and not file.

here is what it looks like

Its root. And its fine. The busybox sees it fine. Verified.

Your suspend/resume device should be the UUID for the swap partition you are using; if that UUID shown is for root that may be why normal shutdowns and/or reboots are giving you the busybox interface after boot.

From my Ubuntu 22.04 install …

 yetiman :~   $   sudo blkid -c /dev/null -o list | grep swap
[sudo] password for yetiman: 
           swap             [SWAP]         4df*****-****-****-****-***********2
 yetiman :~   $   cat /etc/initramfs-tools/conf.d/resume

I have masked most of the UUIDs for privacy but left enough to display the resume device listed in /etc/initramfs-tools/conf.d/resume is the same as my swap partition. I have had troubles in the past with the busybox interface after disk layout alterations when these two don’t match.

I’d suggest you run the blkid command in the above code box and get your swap partition UUID. Edit the file /etc/initramfs-tools/conf.d/resume as root in your favourite text editor and add or alter the line “RESUME=UUID=” to match the two up. Once done, in terminal run the command…

sudo update-initramfs -u -k all

Note: This will update all your kernels, if you only want the current kernel updated don’t include the " -k all".

Also one last check is to check your /etc/fstab also uses the same UUID for your swap partition entry.

If in any doubt about this info wait for @Matt_Hartley to check it out and respond. I have had that suspend/resume device error and a busybox interface a few times now after adjusting partition layouts which include changing the swap partition. I really don’t know why it works if you do a hibernation; I could only guess that the hibernation process is retrieving the information from somewhere else and not accessing the normal details as per a reboot or a fresh boot.

Edit: If you can’t get into your install this may need to be done from a live cd or usb boot and using a chroot set up to do the fix. Let us know if you need further help with such. Or if you have other “parallel” linux installs this can be done very easily without a cd or usb live boot.

Good luck and regards, yeti.


thanks Yeti

couple of clarifying points

  • the issue is intermittent so i have no issues getting in
  • the screenshot above is confusing - the listed UUID is indeed for the root partition because sequentially root partition access is the second check the bootloader is performing
    -my fstab and initfram UUIDs for root and swap are all consistent and inline with what you recomended above and they came out that way straight from the original install. I did not mock with the boot or swap setting at all. Just enabled hibernation to swap partition pre-created during install