You are not logged in.

#1 2018-03-10 18:55:33

shazow
Member
Registered: 2016-03-25
Posts: 8

Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

Hi archy friends,

I've been thrashing on trying to get this configuration to work.

Everything works without the `resume=...` kernel init param, but the moment I add `resume=...` I get some unlocking conflicts during boot (maybe systemd is at fault?) with a bunch of "A start job is running for dev-disk-by \..." ultimately followed by "Timed out waiting for device ..." errors after waiting 1.5min.

Setup Overview

- Three partitions: 1. EFI, 2. Encrypted swap (luks), 3. Encrypted btrfs root (luks)
- /boot (and /home, etc) lives inside the encrypted btrfs root partition.
- Swap had to be a separate partition because there are issues with swap on btrfs.
- I skipped lvm because btrfs subvolumes are otherwise convenient. I've read that adding a top-layer of lvm can make this setup easier, which I have not tried yet but would prefer to avoid for the sake of reducing complexity and having to redo too much.
- There is an initramfs-embedded key that lives at /root/cryptbtrfs.key, this allows me to only enter a password once during the EUFI phase before /boot is unlocked.

In case anyone is curious or this progress is helpful, the hardware is a Thinkpad X1 Carbon 6th gen.

Theories

- I probably have some redundant configuration that is stepping on itself, but I'm not sure where/what. Would love suggestions for how to simplify things further.
- I read somewhere that if systemd tries to unlock a luks partition that is already unlocked, it gets confused or it times out because the resource is locked, or something? Any suggestions for how to alleviate this?

Setup Details

$ lsblk -f

NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
nvme0n1
├─nvme0n1p1 vfat         542D-D27D
├─nvme0n1p2
│ └─cryptswap
│           swap         31389297-c20f-4126-b80b-6bdcceba88b7 [SWAP]
└─nvme0n1p3 crypto       9dc5fead-2f4a-4094-9f0f-565fc74b8d96
  └─luks-9dc5fead-2f4a-4094-9f0f-565fc74b8d96
            btrfs        3af5b147-3f68-4a9f-98f1-714df2d45c94 /home

The btrfs used to mount as /dev/mapper/cryptbtrfs, but now it mounts as the UUID for some reason. Haven't figured out why but works either way.

/etc/fstab:

UUID="3af5b147-3f68-4a9f-98f1-714df2d45c94"                    /                       btrfs   defaults,noatime,nodiratime,compress=lzo,autodefrag,commit=100,subvol=@rootarch     0 1
UUID="3af5b147-3f68-4a9f-98f1-714df2d45c94"                    /boot                   btrfs   defaults,noatime,compress=lzo,autodefrag,subvol=@boot                            0 1
UUID="3af5b147-3f68-4a9f-98f1-714df2d45c94"                    /home                   btrfs   defaults,noatime,compress=lzo,autodefrag,subvol=@home                            0 1
/dev/mapper/cryptswap						swap			swap			defaults,discard	0 0

I've tried using paths for everything, I've tried using UUIDs for everything, does not seem to make a difference.

/etc/crypttab:

#cryptbtrfs	/dev/nvme0n1p3				/root/cryptbtrfs.key	discard,luks
cryptswap 	/dev/nvme0n1p2				/root/cryptbtrfs.key    discard,luks,swap

#cryptbtrfs	UUID=9dc5fead-2f4a-4094-9f0f-565fc74b8d96				/root/cryptbtrfs.key	discard,luks
#cryptswap 	UUID=d578e380-9400-4c0a-9f7f-24910ee47ca1				/root/cryptbtrfs.key    discard,luks,swap

You can see some of the permutations of things I've commented/uncommented. Right now, without resume enabled, having just the cryptswap in crypttab seems to work best. If I uncomment the cryptbtrfs then I get a conflict again and end up having to put in a password a second time during boot, and the whole timeout thing happens.

/etc/default/grub:

...
GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX_DEFAULT="rd.luks=1 rd.luks.key=/root/cryptbtrfs.key rd.luks.uuid=luks-9dc5fead-2f4a-4094-9f0f-565fc74b8d96 rd.luks.allow-discards rd.luks.name=cryptbtrfs rootfstype=btrfs root=UUID=3af5b147-3f68-4a9f-98f1-714df2d45c94 rootflags=subvol=@rootarch mem_sleep_default=deep"
...

This is where adding something like `resume=/dev/mapper/cryptswap` breaks the boot.

Before I encrypted my swap*, I had this setup which *did* work:

#GRUB_CMDLINE_LINUX="cryptdevice=/dev/nvme0n1p3:cryptbtrfs:allow-discards root=/dev/mapper/cryptbtrfs resume=/dev/nvme0n1p2 cryptkey=/root/cryptbtrfs.key"

This was quite many iterations ago, before I switched to systemd and using rd.luks params, etc. Alas, encrypted swap is a requirement for me, so carrying on.

Another setup I tried (in a custom menuentry, for funsies):

/etc/grub.d/40_custom:

menuentry "Experimental" {
        ...
	linux /@boot/vmlinuz-linux  \
		rd.luks=1 \
		rd.luks.allow-discards \
		rd.luks.key=/root/cryptbtrfs.key \
		rd.luks.uuid=9dc5fead-2f4a-4094-9f0f-565fc74b8d9r \
		rd.luks.uuid=d578e380-9400-4c0a-9f7f-24910ee47ca1 \
		rd.luks.name=9dc5fead-2f4a-4094-9f0f-565fc74b8d96=cryptbtrfs \
		rd.luks.name=d578e380-9400-4c0a-9f7f-24910ee47ca1=cryptswap \
		rd.luks.key=9dc5fead-2f4a-4094-9f0f-565fc74b8d96=/root/cryptbtrfs \
		rd.luks.key=d578e380-9400-4c0a-9f7f-24910ee47ca1=/root/cryptbtrfs \
		rd.crypttab=no \
		resume=/dev/mapper/cryptswap \
		rootfstype=btrfs \
		root=/dev/mapper/cryptbtrfs \
		rootflags=subvol=@rootarch

Alas, no luck. I also tried getting rid of the rd.* prefix, but that didn't help.

/etc/mkinitcpio.conf:

MODULES=(i915)
BINARIES=(/usr/bin/btrfs)
FILES=(/root/cryptbtrfs.key)
HOOKS=(base systemd autodetect sd-vconsole modconf block sd-encrypt openswap uresume filesystems keyboard fsck)

Maybe there's a better sequence for these hooks? Anything extraneous?

And the accompanying openswap hook:

/etc/initcpio/hooks/openswap:

run_hook() {
	#rootdevice="/dev/mapper/cryptbtrfs"
	rootdevice="/dev/mapper/luks-9dc5fead-2f4a-4094-9f0f-565fc74b8d96"
	keypath="root/cryptbtrfs.key"
	tmpmount="_tmp_crypt_device"

	if [[ -f "/$keypath" ]]; then
		cryptsetup --allow-discards open /dev/nvme0n1p2 cryptswap --key-file "/$keypath"
		return 0
	fi

	if [[ ! -b "$rootdevice" ]]; then
		sleep 1
	fi

	mkdir "$tmpmount"
	mount -o "compress=lzo,subvol=@rootarch" "$rootdevice" "$tmpmount"
	cryptsetup --allow-discards open /dev/nvme0n1p2 cryptswap --key-file "$tmpmount/$keypath"
	umount "$tmpmount"
	rm -rf "$tmpmount"
}

It's mildly customized but it works, at least without resume.

Thank you

I appreciate any help/suggestions/feedback on this setup. Would love to get suspend-to-disk working, but at least everything else seems to work.

<3

Last edited by shazow (2018-03-10 19:02:29)

Offline

#2 2018-03-11 10:39:14

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 592

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

So many wrong things:

  • Your openswap hook will not work with "systemd" hook. But you don't need it, "sd-encrypt" can unlock multiple devices.

  • /etc/crypttab is used to unlock volumes after boot, don't use it for volumes that need to be unlocked during boot in the initramfs phase. If you want to use a crypttab format file to unlock volumes at boot instead of kernel parameters you can use /etc/crypttab.initramfs. See https://wiki.archlinux.org/index.php/Dm … crypt_hook .

  • "swap" in crypttab doesn't do what you think it does, you do not want if you use hibernation. Read https://jlk.fjfi.cvut.cz/arch/manpages/man/crypttab.5

The "swap" option in crypttab recreated your 'cryptswap' partition after every boot with plain dmcrypt which doesn't have UUIDs, so your UUID in grub config would not match and systemd couldn't find it.

Use 'cryptsetup luksFormat' to create a new 'cryptswap' volume, take a note of the new UUID.

Remove everything in /etc/crypttab, change your HOOKS to

HOOKS=(base systemd autodetect sd-vconsole modconf block sd-encrypt filesystems keyboard fsck)

Change GRUB config to:

menuentry "Experimental" {
        ...
	linux /@boot/vmlinuz-linux  \
		rd.luks.uuid=9dc5fead-2f4a-4094-9f0f-565fc74b8d9r \
		rd.luks.uuid=YOUR_NEW_UUID \
		rd.luks.name=9dc5fead-2f4a-4094-9f0f-565fc74b8d96=cryptbtrfs \
		rd.luks.name=YOUR_NEW_UUID=cryptswap \
		rd.luks.key=9dc5fead-2f4a-4094-9f0f-565fc74b8d96=/root/cryptbtrfs \
		rd.luks.key=YOUR_NEW_UUID=/root/cryptbtrfs \
		rd.luks.options=discard \
		root=/dev/mapper/cryptbtrfs rw\
		rootflags=subvol=@rootarch
		rootfstype=btrfs \
		resume=/dev/mapper/cryptswap \

Last edited by nl6720 (2018-03-11 10:40:04)

Offline

#3 2018-03-11 20:12:16

shazow
Member
Registered: 2016-03-25
Posts: 8

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

Thanks for the suggestions! Alas not quite there yet.

Similar thing is happening as before:

...
[ OK ] Started Cryptography Setup for cryptswap.
[ OK ] Found device /dev/mapper/cryptbtrfs
[ OK ] Started Cryptography Setup for cryptswap.
[ OK ] Reached target Initrd Root eDevice.
[ OK ] Started Load Kernel Modules.
[ TIME ] Timed out waiting for device dev-disk-by\2xduuid-9dc5fea....
[ DEPEND ] Dependency failed for Cryptography Setup for luks-9dc5fea...
[ DEPEND ] Dependency failed for Local Encrypted Volumes.
[ *** ] A start job is running for dev-mapper-cryptswap.device (1min 56s / no limit)_

Things I did:

- Closed the cryptswap and remade it with luksFormat, added the /boot/cryptbtrfs.key to it
- Grabbed the new UUID from blkid, updated the experimental grub menuentry.
- Noted that I had a typo in my key path, /root/cryptbtrfs should have been /root/cryptbtrfs.key, fixed.
- Updated the /etc/mkinitcpio.conf with the new hooks line (removed openswap and uresume).
- Commented out all of /etc/crypttab
- mkinitcpio -p linux && grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Linux --recheck && grub-mkconfig -o /boot/grub/grub.cfg
- Reboot

New lsblk -f looks like:

NAME                                          FSTYPE      LABEL UUID                                 MOUNTPOINT
nvme0n1
├─nvme0n1p1                                   vfat              542D-D27D
├─nvme0n1p2                                   crypto_LUKS       bfd405ed-e164-4760-b5c3-a91b2bb3a62a
└─nvme0n1p3                                   crypto_LUKS       9dc5fead-2f4a-4094-9f0f-565fc74b8d96
  └─luks-9dc5fead-2f4a-4094-9f0f-565fc74b8d96 btrfs             3af5b147-3f68-4a9f-98f1-714df2d45c94 /boot

New grub menuentry looks like:

...
		rd.luks.uuid=9dc5fead-2f4a-4094-9f0f-565fc74b8d9r \
		rd.luks.uuid=bfd405ed-e164-4760-b5c3-a91b2bb3a62a \
		rd.luks.name=9dc5fead-2f4a-4094-9f0f-565fc74b8d96=cryptbtrfs \
		rd.luks.name=bfd405ed-e164-4760-b5c3-a91b2bb3a62a=cryptswap \
		rd.luks.key=9dc5fead-2f4a-4094-9f0f-565fc74b8d96=/root/cryptbtrfs.key \
		rd.luks.key=bfd405ed-e164-4760-b5c3-a91b2bb3a62a=/root/cryptbtrfs.key \
		rd.luks.options=discard \
		root=/dev/mapper/cryptbtrfs rw\
		rootflags=subvol=@rootarch \
		rootfstype=btrfs \
		resume=/dev/mapper/cryptswap

Thanks again for the help. Any suggestions for what to try next?

Last edited by shazow (2018-03-11 20:14:18)

Offline

#4 2018-03-11 21:03:15

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 592

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

shazow wrote:

...
[ TIME ] Timed out waiting for device dev-disk-by\2xduuid-9dc5fea....
[ DEPEND ] Dependency failed for Cryptography Setup for luks-9dc5fea...
[ DEPEND ] Dependency failed for Local Encrypted Volumes.
[ *** ] A start job is running for dev-mapper-cryptswap.device (1min 56s / no limit)_

"dev-disk-by\2xduuid-9dc5fea...." looks like the UUID of 'cryptbtrfs'.

Do you get dumped to initramfs shell when the boot fails? If so try looking if the keyfile in actually there ( ls -l /root ).
If it's there try removing the "rd.luks.key" parameters and unlocking the volumes by typing the password during boot. That way you'll see if the issue is the keyfile, maybe the problem is using the same keyfile for both volumes.

Offline

#5 2018-03-11 21:22:35

shazow
Member
Registered: 2016-03-25
Posts: 8

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

Before, it would just lock up waiting for swap forever (had to hard-reboot). I cleaned some stuff up (honestly not sure what changed, just double checked that everything was right, re-ordered some lines, rebuilt, rebooted) and now it doesn't get stuck forever but it does timeout waiting for the crypbtrfs device, then continues to boot just fine. Either way, it does not dump me into a shell.

After boot, both luks partitions are mounted properly in /dev/mapper:

/dev/mapper
├── control
├── cryptbtrfs -> ../dm-1
└── cryptswap -> ../dm-0

Given that it does ultimately mount both properly, it feels like it's fine that it's the same keyfile. I can add a separate keyfile if you think that will help?

Can you think of another config somewhere I'm forgetting that is forcing systemd to try to re-unlock an already-unlocked device and thus the timeout?

Here's the journalctl output for the failing section:

-- The start-up result is RESULT.
Mar 11 17:12:02 archlinux systemd[1]: dev-disk-by\x2duuid-9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc74b8d9r.device: Job dev-disk-by\x2duuid-9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc7>
Mar 11 17:12:02 archlinux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc74b8d9r.device.
-- Subject: Unit dev-disk-by\x2duuid-9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc74b8d9r.device has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit dev-disk-by\x2duuid-9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc74b8d9r.device has failed.
--
-- The result is RESULT.
Mar 11 17:12:02 archlinux systemd[1]: Dependency failed for Cryptography Setup for luks-9dc5fead-2f4a-4094-9f0f-565fc74b8d9r.
-- Subject: Unit systemd-cryptsetup@luks\x2d9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc74b8d9r.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-cryptsetup@luks\x2d9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc74b8d9r.service has failed.
--
-- The result is RESULT.
Mar 11 17:12:02 archlinux systemd[1]: Dependency failed for Local Encrypted Volumes.
-- Subject: Unit cryptsetup.target has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit cryptsetup.target has failed.
--
-- The result is RESULT.
Mar 11 17:12:02 archlinux systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
Mar 11 17:12:02 archlinux systemd[1]: systemd-cryptsetup@luks\x2d9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc74b8d9r.service: Job systemd-cryptsetup@luks\x2d9dc5fead\x2d2f4a\x2d4094\x2>
Mar 11 17:12:02 archlinux systemd[1]: dev-disk-by\x2duuid-9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc74b8d9r.device: Job dev-disk-by\x2duuid-9dc5fead\x2d2f4a\x2d4094\x2d9f0f\x2d565fc7>
Mar 11 17:12:02 archlinux systemd[1]: Reached target System Initialization.

In case it's useful, here's the full menuentry as it's generated in /boot/grub/grub.conf: (There's a few extra things in the end that is specific to my hardware, I can remove them if it's suspicious.)

menuentry "Experimental" {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod cryptodisk
	insmod luks
	insmod gcry_rijndael
	insmod gcry_rijndael
	insmod gcry_sha256
	insmod btrfs
	cryptomount -u 9dc5fead2f4a40949f0f565fc74b8d96
	set root='cryptouuid/9dc5fead2f4a40949f0f565fc74b8d96'

	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint='cryptouuid/9dc5fead2f4a40949f0f565fc74b8d96'  3af5b147-3f68-4a9f-98f1-714df2d45c94
	else
	  search --no-floppy --fs-uuid --set=root 3af5b147-3f68-4a9f-98f1-714df2d45c94
	fi

	echo	'Loading Linux ...'
	linux /@boot/vmlinuz-linux \
		rd.luks.uuid=9dc5fead-2f4a-4094-9f0f-565fc74b8d9r \
		rd.luks.uuid=bfd405ed-e164-4760-b5c3-a91b2bb3a62a \
		rd.luks.name=9dc5fead-2f4a-4094-9f0f-565fc74b8d96=cryptbtrfs \
		rd.luks.name=bfd405ed-e164-4760-b5c3-a91b2bb3a62a=cryptswap \
		rd.luks.key=9dc5fead-2f4a-4094-9f0f-565fc74b8d96=/root/cryptbtrfs.key \
		rd.luks.key=bfd405ed-e164-4760-b5c3-a91b2bb3a62a=/root/cryptbtrfs.key \
		rd.luks.options=discard \
		root=/dev/mapper/cryptbtrfs rw\
		rootflags=subvol=@rootarch \
		rootfstype=btrfs \
		resume=/dev/mapper/cryptswap \
		mem_sleep_default=deep \
		i915.i915_enable_fbc=1 \
		acpi_osi="!Windows 2012" \
		acpi_brightness=vendor

	echo	'Loading initial ramdisk ...'
	initrd  /@boot/intel-ucode.img /@boot/initramfs-linux.img
}

Edit: Worth noting that removing the resume=... line no longer fixes the problem. Seems to get  the same timeout situation either way. Progress? tongue

Last edited by shazow (2018-03-11 21:27:07)

Offline

#6 2018-03-11 21:32:27

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 592

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

shazow wrote:

Worth noting that removing the resume=... line no longer fixes the problem. Seems to get  the same timeout situation either way. Progress? tongue

The "dependency" makes me think that the issue is the keyfile.

Try booting without the "rd.luks.key" options, if that works make a copy of the keyfile for the other volume and see if it solves the issue.

Offline

#7 2018-03-11 21:58:58

shazow
Member
Registered: 2016-03-25
Posts: 8

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

Okay, a bit more data:

I tried removing the "rd.luks.key" lines, so it asked me for a password for each of both partitions. I entered one twice (I think I mistyped it), then ultimately it tossed me into a recovery shell. I confirmed that /root/cryptbtrfs.key is there, and I confirmed that /dev/mapper/crypt{btrfs,swap} are both mounted. Not sure why it failed here altogether, maybe I mistyped it too many times?

Then I put the rd.luks.key lines back in, and I made a copy of the /root/cryptbtrfs.key to /root/cryptswap.key. I also luksAddKey'd it for good measure (though I imagine it doesn't matter since they're the same). Then I changed the swap rd.luks.key to use /root/cryptswap.key instead. I did not add it to mkinitcpio FILES.

During booting this time, the crypbtrfs was fine, then it asked me to put it a password for cryptswap (I guess it was in the initramfs phase still), then it went through and timed out on unlocking cryptbtrfs again (same as before).

I'll try adding the cryptswap.key to mkinitcpio but I'm not expecting much from that as the redundant unlock seems to be happening after that phase.

I also pacman -Syu'd which put me on 4.15.8-r1 (up from 4.14 I think), but didn't help.

Last edited by shazow (2018-03-11 22:00:02)

Offline

#8 2018-03-12 09:18:24

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 592

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

I think it asks for the passphrase 3 or 5 times before giving up.

The keyfiles need to be in the initramfs image when using "sd-encrypt" hook, so you must add them to the FILES array in mkinitcpio.conf and regenerate the initramfs.

Reading systemd-cryptsetup-generator(8) gave me an idea. Remove the "rd.luks.uuid=*" lines and try booting, according to the man page the UUID should be implied by the "rd.luks.name=" param.

Edit:
I recreated your setup in a VM. Everything works for me with /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="rd.luks.name=INSERTUUID1HERE=cryptbtrfs rd.luks.name=INSERTUUID2HERE=cryptswap rd.luks.key=INSERTUUID1HERE=/root/cryptbtrfs.key rd.luks.key=INSERTUUID2HERE=/root/cryptbtrfs.key resume=/dev/mapper/cryptswap"

Using the same keyfile for both volumes didn't cause any problems, nether did using "rd.luks.uuid" together with "rd.luks.name".

Triple check all the UUIDs, remember that "rd.luks" needs the UUID of partition with the type 'crypto_LUKS' not of the unlocked filesystem.

Last edited by nl6720 (2018-03-12 11:01:37)

Offline

#9 2018-03-12 16:45:02

shazow
Member
Registered: 2016-03-25
Posts: 8

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

Hey nl6720, thanks for going above and beyond. I really appreciate it.

Could you share the final generated menuentry that worked in your VM? I tried taking out the rd.luks.uuid lines but it failed to boot (dropped into a recovery shell). The relevant systemctl error: https://i.imgur.com/TRkKeg4.jpg, perhaps the search preambles are different or something.

What's strange to me is it worked before without resume=, and I'm having trouble figuring out what exactly was responsible for making that work which is no longer doing the trick. Was it the crypttab?

Overall, would you agree that it feels like some systemd hook is redundantly trying to unlock the root fs? Are there any strategies for weeding these out? (I'm sure it's some redundant thing that I installed/attempted to configure but ultimately didn't help and forgot about it.)

If so, maybe I'll make a separate systemd-focused post with a more cleaned up config layout. Ultimately I can try a clean install which I suspect will end up working, but I'd rather avoid that for now.

Offline

#10 2018-03-12 17:28:17

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 592

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

/sysroot doesn't contain the Arch installation meaning that the "root" parameter most likely is wrong. /etc/crypttab shouldn't cause this problem since it's only read after the real root is mounted not during the initramfs phase. And since you only need to unlock the root and swap partitions, both of which you need already in the initramfs, there's nothing you would need to place in /etc/crypttab .

Here are the files from the VM: lsblk -O, fstab and grub.cfg. P.S. resuming from hibernation works in the VM.

Edit:
I just noticed that the image says /usr/local/lib/systemd/system/initrd-switch-root.service. Are you adding custom stuff to the initramfs?

Last edited by nl6720 (2018-03-12 19:22:24)

Offline

#11 2018-03-15 16:13:53

shazow
Member
Registered: 2016-03-25
Posts: 8

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

Sorry, lost a bit of steam on this, catching up.

Noticed a couple of differences I'll try:
- Your fstab uses /dev/mapper/cryptbtrfs instead of UUID=...
- Your grub.cfg uses root=UUID=... instead of root=/dev/mapper/cryptbtrfs

The rest looks similar.

nl6720 wrote:

I just noticed that the image says /usr/local/lib/systemd/system/initrd-switch-root.service. Are you adding custom stuff to the initramfs?

Custom where? I have the custom embedded files (keys) in mkinitcpio.conf, the btrfs binary, the i915 module. I also have this initrd line:

initrd  /@boot/acpi_override /@boot/intel-ucode.img /@boot/initramfs-linux.img

But I'm assuming you mean something different? I can't think of anything else I'm doing custom. Where can I check?

Offline

#12 2018-03-15 16:40:19

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 592

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

It shouldn't matter if it's UUID or /dev/mapper/ , both should work, i have UUID in grub.cfg because grub-mkconfig uses it by default.

shazow wrote:

But I'm assuming you mean something different? I can't think of anything else I'm doing custom. Where can I check?

No Arch Linux package puts binaries in /usr/local/ .
I'm thinking you either have some hook in /etc/initcpio/{hook,install}/ with the same name as one of the packaged hooks, or some custom binary in /usr/local/ that gets added to the initramfs image.

Post the output of:

ls -R /etc/initcpio
ls -R /usr/local/{lib,bin,sbin}

Last edited by nl6720 (2018-03-15 16:48:17)

Offline

#13 2018-03-15 17:31:40

shazow
Member
Registered: 2016-03-25
Posts: 8

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

For a while, I had that openswap hook which I removed.

# ls -R /etc/initcpio
/etc/initcpio:
hooks  install
/etc/initcpio/hooks:
/etc/initcpio/install:
# ls -R /usr/local/{lib,bin,sbin}
/usr/local/bin:
/usr/local/lib:
/usr/local/sbin:

Last edited by shazow (2018-03-15 17:52:41)

Offline

#14 2018-03-15 18:01:43

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 592

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

I'm out of ideas, it should just work. sad
I can only suggest regenerating the initramfs, generating new grub.cfg and trying to boot again.

Offline

#15 2018-03-15 18:03:22

shazow
Member
Registered: 2016-03-25
Posts: 8

Re: Hibernate resume support with BTRFS+LUKS+systemd (no LVM)

No worries, thanks for trying!

I'll update this thread if I manage to make it work.

Offline

Board footer

Powered by FluxBB