[SOLVED] Hibernation not working...

[The_Great_Sephiroth]

I have an odd issue here. If I tell my laptop to hibernate it will appear to do so, but upon startup it starts normally instead of resuming. I have an 8GiB swap partition and 8GiB of RAM. I did not specify the default resume partition in my kernel configuration because it may change. I know you do not need to do this because binary distros come with prebuilt kernels and you can configure swap anywhere and it works. What am I doing wrong?

[PrSo]

Maybe this sounds trivial but have you included "resume=" ("real_resume=" in case of luks on lvm) in your kernel command line?
EDIT:
also double check UUID's of swap patition in kernel command line.

[Hu]

The binary distributions might ship an initramfs that goes searching for a hibernation image and resumes from whatever it can find. They might ship some helper tool that builds a customized initramfs for this purpose based on where the main system discovers you put swap.

Regardless, the pertinent question is: what did you do to ensure the kernel can find the resume partition? How did you tell it to activate that partition when found? What error messages are displayed at the point where it probes for the resume partition, fails to use it, and chooses to boot normally instead?

[The_Great_Sephiroth]

Well, since I never had to do anything before I assumed the kernel would find said partition and use it. I geuss I need to edit my kernel command line as outlined above!

*UPDATE*

No go. I added "resume=UUID=x-y-z" to the kernel parameters and now if I hibernate I get "swapon: /dev/sda5: hibernation data detected, rewriting swap signature" but no actual resume.

[khayyam]

The_Great_Sephiroth ...

I have some recollection of genkernel needing to be patched for hibernate, but I can't find the thread in question on a quick search ... or perhaps my memory is failing.

best ... khay

[fedeliallalinea]

I have some recollection of genkernel needing to be patched for hibernate, but I can't find the thread in question on a quick search ... or perhaps my memory is failing.

I don't know if in past this was needed, but in my system hibernate work without any patch to genkernel

[abduct]

The_Great_Sephiroth ...

I have some recollection of genkernel needing to be patched for hibernate, but I can't find the thread in question on a quick search ... or perhaps my memory is failing.

best ... khay

You are correct. It was probably me that you were recalling: https://forums.gentoo.org/viewtopic-t-1 ... bduct.html specifically my last post in the thread offers the solution and links to the data I found regaurding the issue.

I am not sure if it was fixed in the latest genkernel (probably not since the time of that post people were waiting years for devs to fix it), but you need to add the resume binaries to the initramfs as well as patch the initramfs script to actually run the resume binaries.

Although I am runing a LVM system so perhaps it's different on other systems.

Also be aware that if you update genkernel and run dispatch-conf that you don't overwrite the genkernel configuration or else your hibernate will be broken again and you will need to repatch it. Likewise if you update the suspend binaries you need to copy them to the genkernel overlay.

Edit::

Suspend to ram though works out of the box once configured though.

[Hu]

Assuming we are talking about the kernel's native hibernate/resume (as opposed to tuxonice or uswsusp, each of which may behave differently), then I think UUID= is not a valid way of specifying the device to use. kernel/power/hibernate.c:software_resume uses init/do_mounts.c:name_to_dev_t to convert your input into a device. According to the banner comment above name_to_dev_t, it accepts 8 different formats, none of which are the one you used. The closest match is that it can accept a PARTUUID=, which is specified in the partition table. You used a UUID=, which is a property of the filesystem. Try using the PARTUUID instead. You can use blkid to print both the PARTUUID and filesystem UUID.

Also, since this is a laptop, I should note that you may not be able to resume without an initramfs. It is traditional for hibernated laptops to use LUKS-encrypted swap to protect the image at rest, in case the laptop is stolen. The kernel cannot open the LUKS volume without an initramfs, and cannot resume until the LUKS volume is opened. If you opted not to encrypt swap, then ignore this paragraph.

[PrSo]

@Hu,
If full disk encryption is used swap volume has no PARTUUID since it is LVM member.
Besides that it is good to know that to properly setup resume from disk you have to give "real_resume=/dev/mapper/swap" (I can resume from hibernate with UUID but have to disable radeon/amdgpu module - that's another story). Thanks.

[Hu]

You can use LUKS encryption to encrypt full filesystems without using LVM, in which case the hierarchy would be:

• block device
  • partition with UUID and content type=LUKS
    • filesystem inside LUKS
  • partition with UUID and content type=LUKS
    • swap inside LUKS

If it were an LVM member, its name would not be /dev/sda5. You are correct that if this were LVM, then the PARTUUID would point to the LVM physical volume, which is not what OP would need here.

real_resume has no meaning to the kernel. That is an initramfs-specific setting, so it depends on which initramfs is used.

[The_Great_Sephiroth]

I do not use LUKS nor do I use genkernel or an initramfs. I will try the PARTUUID next. Honestly, LUKS wouldn't stop me if I stole a laptop. I use System Rescue CD, change root password, and be in.

[Hu]

You're thinking of the wrong attack model. LUKS-encrypted swap is to maintain the privacy of the hibernated image, so that no secrets from the running session are disclosed to the thief. Encrypting swap is not about denying the attacker access to the home directory. In most cases, encrypted swap is combined with an encrypted home and possibly encrypted root volume, in which case you cannot access any of the rightful owner's data without defeating LUKS first.

[Yamakuzure]

I do not use LUKS nor do I use genkernel or an initramfs. I will try the PARTUUID next. Honestly, LUKS wouldn't stop me if I stole a laptop. I use System Rescue CD, change root password, and be in.

Not if the root partition is encrypted as well.

But that encryption counts next to nothing if someone stole the laptop, booted off a sysresccd, and can read your last sessions memory content through your unencrypted hibernation data in your swap partition.

Having said that, I have a poweron password, a HD password, and all personal files are stored in a ZRAID2 that consists of 8 Veracrypt containers. With 32GB I never hibernate and thus need no encrypted swap, bit I think that four passwords to get onto my data is enough in any case.
(Nicely enough the HDD password protection from my Dell laptop is written on the drives and the controller. So without the password you can not use the drive on a different controller, or a different drive in that laptop.)

[The_Great_Sephiroth]

Four levels of encryption? Holy cow, that's the type of crap we pulled back on Fort Bragg a few years ago! Nice setup!

Either way you are correct. I have had a lack of sleep as of late and was not thinking about the rest of the disk being encrypted. If it was only swap which was encrypted my method would indeed work, but if somebody encrypted swap then they likely encrypted at LEAST the home directory as well.

Either way, is it not possible to hibernate without an initramfs? I do not care to use one. I will try a PARTUUID next.

[Fitzcarraldo]

Either way, is it not possible to hibernate without an initramfs? I do not care to use one.

One of my laptops running Gentoo has an initramfs, the other does not. Both are able to suspend to RAM and both are able to hibernate. So it is possible to hibernate without an initramfs.

EDIT: Oh, and I didn't have to patch genkernel in order to get hibernation to work on the laptop that does have an initramfs.

[Hu]

Four levels of encryption?

Four levels of password protection. Some of those are definitely passwords that unlock encryption, but some may not be (or may be implemented in a way that is not of the same quality as current generation software encryption).

I have had a lack of sleep as of late

I thought this thread was about hibernation, not sleep.

Either way, is it not possible to hibernate without an initramfs?

It should be possible, although it will be much less flexible than if an initramfs is available.

[The_Great_Sephiroth]

Hu, my hibernation function seems to be broken also. Something about having a 2yr old breaks that functionality! Unfortunately there are no kernel patches for this...

I haven't tried the PARTUUID yet but I just edited them now. I will try hibernation when I leave here to go to the next client.

*EDIT*

Here's what I modified in /etc/default/grub.

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="resume=PARTUUID=3f819681-26e6-4f32-9796-a8625689fc8c"

That is the correct part uuid.

*UPDATE*

That did it! I will change the other laptops to part-uuid instead of normal uuid. We're golden now! Thanks for the help!

[Fitzcarraldo]

Either way, is it not possible to hibernate without an initramfs?

It should be possible, although it will be much less flexible than if an initramfs is available.

Why is it much less flexible? Resuming from hibernation on my Clevo W230SS laptop without an initramfs is just as easy and fast as resuming from hibernation on my Compal NBLB2 laptop with an initramfs.

[Fitzcarraldo]

Here's what I modified in /etc/default/grub.

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="resume=PARTUUID=3f819681-26e6-4f32-9796-a8625689fc8c"

That is the correct part uuid.

*UPDATE*

That did it! I will change the other laptops to part-uuid instead of normal uuid. We're golden now! Thanks for the help!

I wonder why your installation requires you to specify the resume partition as a PARTUUID specifically? On my Clevo W230SS laptop without an initramfs I just specify the swap partition device (/dev/sda2):

Code: Select all

clevow230ss /home/fitzcarraldo # mount /dev/sda1 /boot
clevow230ss /home/fitzcarraldo # grep resume= /boot/grub/grub.cfg
        linux   /vmlinuz-4.12.12-gentoo root=/dev/sda5 ro  i915.modeset=1 rcutree.rcu_idle_gp_delay=1 acpi_enforce_resources=lax reboot=force raid=noautodetect resume=/dev/sda2
                linux   /vmlinuz-4.12.12-gentoo root=/dev/sda5 ro  i915.modeset=1 rcutree.rcu_idle_gp_delay=1 acpi_enforce_resources=lax reboot=force raid=noautodetect resume=/dev/sda2

EDIT: Ah, just noticed you stated 'I did not specify the default resume partition in my kernel configuration because it may change.' in your first post, so please ignore this post!

[The_Great_Sephiroth]

That may work also. I stopped using device names years ago though. I believe if I leave my eSATA dock plugged in, with a disk in it, that gets detected as sda at times, so /dev/sda5 would fail to resume (sda5 is my swap).

[Hu]

It should be possible, although it will be much less flexible than if an initramfs is available.

Why is it much less flexible? Resuming from hibernation on my Clevo W230SS laptop without an initramfs is just as easy and fast as resuming from hibernation on my Compal NBLB2 laptop with an initramfs.

The kernel's resume code is fairly simplistic compared to what an initramfs can do and has far less opportunity for easy customization. As discussed up thread, the kernel alone cannot resume from certain types of encrypted swap, because the encryption device needs to be opened first, and there is no way to express that without some sort of userspace. More generally, you cannot resume from any swap device that will not be made fully available by the kernel's automatic discovery procedures.

[The_Great_Sephiroth]

We keep talking security, so I am curious. How possible is it to crack my BIOS password? Pulling the battery does not remove it. I am guessing the only way encryption would help me (and thus require an initramfs) is if my disk was physically removed from my laptop. Assuming it was soldered to the board like an Apple, would my BIOS password be enough since it cannot be removed?

[khayyam]

We keep talking security, so I am curious. How possible is it to crack my BIOS password? Pulling the battery does not remove it. I am guessing the only way encryption would help me (and thus require an initramfs) is if my disk was physically removed from my laptop. Assuming it was soldered to the board like an Apple, would my BIOS password be enough since it cannot be removed?

The_Great_Sephiroth ... the bios password won't prevent someone removing the disk, and reading data on that disk from another machine. That is the senario in which disk encyption might help. As for the bios, if you're skilled, and have the right tools, then de-soldering, and replacing/flashing the chip, isn't a huge undertaking ... I know someone who's designed boards/tools for this purpose, and can flash a variety of chips, including Apple.

best ... khay

[Hu]

As an emergency recovery mechanism, some boards may provide a way to wipe the password (often by short-circuiting a specific pair of pins) without damaging the system. This is usually justified on the basis that, without it, the customer would scrap or RMA the board.

There is also the usual suspicion that, since we cannot see how your BIOS implements the password mechanism, it is hard to trust that there are no exploits that could bypass it (such as a hardcoded but super-secret "master" password set by the vendor that is accepted regardless of what password you, as the owner, set). We've seen enough of that in other devices that it's not out of the realm of possibility, and usually the vendor even has a non-malicious (if stupid) reason for having done it.

More generally, if we assume that: (1) your firmware will only permit the system to boot when given the password you chose and (2) your drive cannot be transplanted to a more compliant system, then yes, it's probably acceptable not to encrypt the drive. Personally, I'm not comfortable making either of those assumptions, so if it were me, I would encrypt the drive.