ERROR: resume: hibernation device not found
You gotta love a cryptic error message during boot like: “ERROR: resume: hibernation device ‘UUID=long number here’ not found.” Love even more the fact you need roughly ten minutes of patience to get past it.
The thing about having quite a few machines you experiment with is you stumble across the really stupid stuff. I had stuck a 6Gb/s 1TB drive in this i5 to experiment with Manjaro. Eventually I was going to be building CopperSpice or something like that. I thought really fast hard drive would make life better.
For those of you who haven’t followed along, I always thought this was a 4th gen i5, then I actually looked at the system info during Manjaro experiment. Yep, it is just a gen-3.
So, I shrunk the partition down to about 200Gig because I was going to stick in one of my oldest drives to return this machine to the “BOINC Rack.” Did an image backup, Stuck in a 300Gig ATA-150, restored, then booted GParted CD to resize.
“I don’t want to wait for GParted to move the swap partition all the way to the end of the drive.“
Admit it, you’ve all said that. Most of you have done what I did. You just deleted the existing 9Gig swap and created a new one at the end of the drive. It took mere seconds. Then you had GParted expand the primary partition to consume all space in between.
Then you suffer through the boot you think will never complete. Much of that time you get to see the above error message on the screen. Then you wonder if you are going to have a roughly 20 minute reboot each time or if you can fix it.
Linux, over the past five or so years, has been doing a lot of work on hibernation. It has to. Microsoft absolutely sucks at it. Go into any pre-pandemic company and you will see managers carrying laptops open down the hall between meetings. Why? Because Microsoft blows when it comes to hibernation. Something always gets corrupted. Not every time and not with any predictable pattern, but something always gets corrupted.
Hibernation has been forced on the world by so-called “modern” browsers. Chromium, Firefox, Opera, and others will launch upwards of 100 processes when you start the browser. Many of these will never get used. They are “just there in case.”
Some Linux distros have opted to Hibernate in RAM
The phrase causes a lot of confusion when people read it. “Hibernate in RAM” sounds so unsafe. It is. This type of hibernation is basically storing compressed versions of these hundred or so unused processes off in some corner of RAM until they are actually needed. They aren’t supposed to survive a boot.
Some Linux distros use a hibernate partition
Basically they create a partition about the size of what they think they will need to store a compressed image of RAM (or most of it) while the machine is going into hibernation. This makes a little more sense to most people because the system theoretically should recover from hibernation. At startup the system can look for some certain value in the hibernation partition and choose to load the contents based on that certain value.
Some Linux distros use swap
The original intent of swap was to provide virtual memory to an over taxed system. Most of you reading this aren’t old enough to remember trying to run Linux from floppy on a PC with 640K. Things didn’t really get much better when we could finally address 2MEG. Being able to swap processes in and out of precious RAM allowed a computer to do more.
RAM has gotten cheap. Even the Raspberry Pi 2 comes with 1Gig. When I started in IT we couldn’t get a Gig of storage without filling a room full of tape reels.
That’s why companies bought computer operators roller skates. I kid you not.
Even this old i5 gen-3 came with 4Gig of RAM initially. As you can see I boosted it to 24Gig. As such, the swap partition, created by default in most installation scripts for most distros, rarely, if ever, gets used. For over a decade the rule of thumb was at least one byte of disk for each byte of RAM.
Back when a 20MEG hard drive was big and PC RAM was capped at 640K this meant we allocated at least 1/20th of our storage (usually way more) to swap. Today many distros just use a file or directory in root. Standard “corporate issue” desktops come with 8-16Gig of RAM and 1TB disk. They have stopped trying to “get by” with smaller hard drives because it is just not worth it.
You end up wasting quite a bit of disk trying to create a small partition. Sectors have to be skipped so it is properly aligned. Creating a directory with files that can expand to however much you need is a much more efficient use of disk . . . provided the reason for hibernation wasn’t a “disk full” condition.
What has that got to do with the error?
I’m glad you asked!
Long ago Linux moved to using UUID to identify disks so they could find them if they moved around. This was particularly important during the days of SCSI. It remained important during the days of IDE when master/slave jumpers could be changed.
For Manjaro (and probably many other Linux distros) they identify the resume location in Grub. When you (I) nuked the swap partition the new partition I created got a new UUID. For swap, Linux looks around for all of them and just uses them. For resume, not so much.
The first step at fixing this is identifying the new UUID.
You need the UUID, not the PARTUUID.
On Manjaro you can just use nano and edit this file directly as a cheap hack to test your ideas.
sudo nano /boot/grub/grub.cfg
Note: The next time something forces grub to update your cheap hack will be gone.
You really need to edit /etc/default/grub then run update-grub.
sudo nano /etc/default/grub sudo update-grub
After that this particular problem will be solved.