Bug 728118 – genkernel-4.0.7-r1 initramfs is unable to resume from hibernation using UUID as image source

• Status: RESOLVED WORKSFORME
• Product: Gentoo Hosted Projects

[Description Felix Tiede 2020-06-13 10:11:57 UTC]

If a system's disk uses a single LUKS-encrypted LVM volume group, with swap being a logical volume in that group, genkernel's default initramfs is unable to resume from suspend-to-disk when 'resume=UUID=<swap UUID>' is used as kernel parameter.

With 'resume=/dev/mapper/vg0-lv_swap' (with 'vg0' and 'lv_swap' being the names of LVM volume group and logical volume respectively) as kernel parameter it works flawlessly.

It also works when every logical volume is separately encrypted using LUKS.

I therefore assume that finding the REAL_RESUME device in /usr/share/genkernel/default/linuxrc, starting at line 608, happens too soon after start_LUKS returns and UUIDs are not properly populated for either findfs or blkid to find the swap partition based on its UUID for do_resume().

Reproducible: Always

Steps to Reproduce:
1. Setup a system with a single LUKS-container with logical volumes for swap and rootfs.
2. Note swap's UUID and provide as 'resume=' kernel parameter
3. Suspend to disk
4. Attempt system resume with resume=UUID=<swap UUID> as kernel parameter
Actual Results:  
Resuming from stored image fails and the system boots as if cold started.

Expected Results:  
Clean resume back into the working environment as left at suspending.

A workaround is to directly specify the device in the kernel's 'resume' parameter, skipping both findfs and blkid.

The repeated failure to resume from suspend to disk may cause a loss of data if filesystem recovery is not successful, as well as possible loss of data on any unsaved work.

Since an operational workaround is easy to implement and loss of data is easily avoidable, by either applying the workaround or not suspending to disk at all, I've left the severity at normal despite it actually being a crash with potential loss of data.

[Comment 1 Thomas Deutschmann (RETIRED) 2020-06-15 17:25:23 UTC]

Please show your kernel command-line.

Did you set CRYPT_SWAP to let genkernel init script know that it has to open a LUKS device?

[Comment 2 Felix Tiede 2020-06-17 17:29:33 UTC]

(In reply to Thomas Deutschmann from comment #1)
> Please show your kernel command-line.

Current commandline:
$ cat /proc/cmdline 
quiet dolvm crypt_silent scandelay=1 vsyscall=emulate i915.enable_guc=2 crypt_root=UUID=<redacted> root_keydev=UUID=<redacted> root_key=boot/sys_root.gpg real_root=UUID=<redacted> rootfstype=ext4 resume=/dev/mapper/vg0-lv_swap CONSOLE=/dev/tty1

> 
> Did you set CRYPT_SWAP to let genkernel init script know that it has to open
> a LUKS device?

Before switching to a single LUKS container I have indeed used CRYPT_SWAP and SWAP_KEYDEV instead of REAL_ROOT as it is now.

[Comment 3 Thomas Deutschmann (RETIRED) 2020-06-21 22:09:32 UTC]

I cannot reproduce. My test system will look like:

> # lsblk
> NAME                         MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
> sda                            8:0    0   20G  0 disk
> ├─sda1                         8:1    0  128M  0 part
> │ └─md127                      9:127  0  128M  0 raid1 /boot
> └─sda2                         8:2    0 19,9G  0 part
>   └─md126                      9:126  0 19,9G  0 raid1
>     └─root                   253:0    0 19,9G  0 crypt
>       ├─ vmStorage-swap      253:1    0    1G  0 lvm   [SWAP]
>       ├─ vmStorage-portage   253:2    0    2G  0 lvm   /usr/portage
>       ├─ vmStorage-distfiles 253:3    0    4G  0 lvm   /usr/portage/distfiles
>       └─ vmStorage-rootfs    253:4    0 12,2G  0 lvm   /
> sdb                            8:16   0   20G  0 disk
> ├─sdb1                         8:17   0  128M  0 part
> │ └─md127                      9:127  0  128M  0 raid1 /boot
> └─sdb2                         8:18   0 19,9G  0 part
>   └─md126                      9:126  0 19,9G  0 raid1
>     └─root                   253:0    0 19,9G  0 crypt
>       ├─ vmStorage-swap      253:1    0    1G  0 lvm   [SWAP]
>       ├─ vmStorage-portage   253:2    0    2G  0 lvm   /usr/portage
>       ├─ vmStorage-distfiles 253:3    0    4G  0 lvm   /usr/portage/distfiles
>       └─ vmStorage-rootfs    253:4    0 12,2G  0 lvm   /
> sdc                            8:32   0   10G  0 disk
> └─sdc1                         8:33   0   10G  0 part
>   └─dataVault                253:5    0   10G  0 crypt /secureData
> 

> # blkid
> /dev/sdb1: UUID="b23a10ab-9dc2-1e17-cd75-86dda65dbef9" UUID_SUB="2b4122ec-7960-5745-8f68-07967c16983c" LABEL="vm-setup:boot" TYPE="linux_raid_member" PARTLABEL="Boot" PARTUUID="6c2a0007-94e8-4b4a-91e2-03a3345d85b3"
> /dev/sdb2: UUID="0b135d52-ab24-1210-4144-798f025b1b94" UUID_SUB="1deec41c-25b3-4123-58a4-70132683ab9e" LABEL="vm-setup:Bank" TYPE="linux_raid_member" PARTLABEL="Bank" PARTUUID="5492aa71-2129-4d2a-a11f-e2b160e6a700"
> /dev/sda1: UUID="b23a10ab-9dc2-1e17-cd75-86dda65dbef9" UUID_SUB="428bbb9d-4532-246e-7f19-ca115f38efda" LABEL="vm-setup:boot" TYPE="linux_raid_member" PARTLABEL="Boot" PARTUUID="b48c5a74-fd9d-4f5b-8c75-761f8fef7b75"
> /dev/sda2: UUID="0b135d52-ab24-1210-4144-798f025b1b94" UUID_SUB="b9155737-6dac-c42d-0049-046b956b6ee1" LABEL="vm-setup:Bank" TYPE="linux_raid_member" PARTLABEL="Bank" PARTUUID="47faf210-95bd-4541-9701-bd4a4377b1b5"
> /dev/sdc1: UUID="3b2887f1-24a8-4b87-a67a-2da3b5cb030d" TYPE="crypto_LUKS" PARTLABEL="partTmp" PARTUUID="1f5a0094-f699-4c60-a23c-4ed14d5e41fb"
> /dev/md127: LABEL="Boot" UUID="e55b3d1b-efbb-4984-b958-52e22f188793" BLOCK_SIZE="1024" TYPE="ext4"
> /dev/md126: UUID="6edcbea7-bb2c-4e22-9839-9f682f6fd51f" TYPE="crypto_LUKS"
> /dev/mapper/root: UUID="BLod0A-x3No-TUda-6qu5-Cg0D-tOq2-RfzEa3" TYPE="LVM2_member"
> /dev/mapper/vmStorage-swap: LABEL="Swap" UUID="2dcdaf2d-b0ee-46a0-a762-769385666ca9" TYPE="swap"
> /dev/mapper/vmStorage-portage: LABEL="portage" UUID="d8ef69f3-5498-458d-8272-1bac707fa350" BLOCK_SIZE="1024" TYPE="ext4"
> /dev/mapper/vmStorage-distfiles: LABEL="distfiles" UUID="635acfa5-4faa-4a9a-81d6-e8cc8fe56c74" BLOCK_SIZE="4096" TYPE="ext4"
> /dev/mapper/vmStorage-rootfs: LABEL="root" UUID="06e2ba17-c88a-4d13-bfa0-2dd0845ede6c" BLOCK_SIZE="4096" TYPE="ext4"
> /dev/mapper/dataVault: LABEL="fsSecureData" UUID="0550d5e7-c5b8-49a1-9e1e-af53776d0888" BLOCK_SIZE="4096" TYPE="ext4"
> 

> # cat /proc/cmdline
> BOOT_IMAGE=/kernel ssh domdadm dolvm video=1024x768 crypt_root=UUID=6edcbea7-bb2c-4e22-9839-9f682f6fd51f root=UUID=06e2ba17-c88a-4d13-bfa0-2dd0845ede6c resume=UUID=2dcdaf2d-b0ee-46a0-a762-769385666ca9 rootfstype=ext4 dosshd gk.sshd.wait=10 gk.log.keep=/var/log/genkernel-boot.log initrd=/initramfs


Also, from reading the code I have no idea what should go wrong when just using UUID. I added some debug log to gk.log which will give you some information what system tried to do when resume failed. But I would suggest to check UUIDs...

[Comment 4 Larry the Git Cow 2020-06-21 22:15:32 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=dc3923c6f8d61ac28f9b1edb73b643aa6e7e67c2

commit dc3923c6f8d61ac28f9b1edb73b643aa6e7e67c2
Author:     Thomas Deutschmann <[e-mail]>
AuthorDate: 2020-06-21 22:14:07 +0000
Commit:     Thomas Deutschmann <[e-mail]>
CommitDate: 2020-06-21 22:14:07 +0000

    defaults/initrd.scripts: Log what is happening in *_resume functions
    
    Bug: https://bugs.gentoo.org/728118
    Signed-off-by: Thomas Deutschmann <[e-mail]>

 defaults/initrd.scripts | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

[Comment 5 Felix Tiede 2020-07-08 19:29:37 UTC]

I can confirm it works with genkernel-4.0.9, with and without logging enabled.