[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?
_________________
Ever picture systemd as what runs "The Borg"?

PrSo · Tux's lil' helper Joined: 01 Jun 2017 Posts: 136

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 · Moderator Joined: 06 Mar 2007 Posts: 21633

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 · Posted: Fri Jul 20, 2018 11:09 pm Post subject:

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.
_________________
Ever picture systemd as what runs "The Borg"?

khayyam · Posted: Sat Jul 21, 2018 1:57 am Post subject:

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 · Posted: Sat Jul 21, 2018 7:58 am Post subject:

abduct · Apprentice Joined: 19 Mar 2015 Posts: 215

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

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 · Tux's lil' helper Joined: 01 Jun 2017 Posts: 136

@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 · Moderator Joined: 06 Mar 2007 Posts: 21633

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 · Posted: Thu Jul 26, 2018 2:07 pm Post subject:

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.
_________________
Ever picture systemd as what runs "The Borg"?

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

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 · Posted: Fri Jul 27, 2018 8:05 am Post subject:

The_Great_Sephiroth · Posted: Thu Aug 02, 2018 3:43 pm Post subject:

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.
_________________
Ever picture systemd as what runs "The Borg"?

Fitzcarraldo · Posted: Thu Aug 02, 2018 5:56 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

The_Great_Sephiroth · Posted: Tue Aug 07, 2018 1:56 pm Post subject:

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.

Fitzcarraldo · Posted: Tue Aug 07, 2018 5:28 pm Post subject:

Fitzcarraldo · Posted: Tue Aug 07, 2018 5:33 pm Post subject:

The_Great_Sephiroth · Posted: Tue Aug 07, 2018 5:42 pm Post subject:

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).
_________________
Ever picture systemd as what runs "The Borg"?

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

The_Great_Sephiroth · Posted: Thu Aug 09, 2018 4:43 pm Post subject:

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?
_________________
Ever picture systemd as what runs "The Borg"?

khayyam · Posted: Thu Aug 09, 2018 7:30 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

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.