search

nailfarmer / debian-luks-suspend

Lock encrypted root volume on suspend in Debian
13 stars 4 forks source link

Use unmkinitramfs to extract images (was: chroot fails to run '/bin/encrypton-suspend' after commit 40de449) #4

Closed themchn closed 4 years ago

themchn commented 4 years ago

The commit that changed extracting the initramfs to use unmkinitramfs has broken suspend on my Bullseye system. Manually invoking "systemctl start systemd-suspend.service" to view the output results in:

cpio: Removing leading '/' from hard link targets cpio: Removing leading '../' from hard link targets chroot: failed to run command '/bin/encrypt-on-suspend': No such file or Directory

Rolling back to the previous commit fixes everything. Is anyone else seeing this behavior?

nailfarmer commented 4 years ago

Thanks @themchn. Yes, can confirm this behaviour. unmkinitramfs is now generating a different file structure and is creating some broken symlinks when extracting the initrd. I've reverted the changes for now. If I can get unmkinitrams to work more consistently in the future, I'll reconsider using it.

t2d commented 4 years ago

Sorry, that the commit caused problems for you. My machines are running fine, virtual and physical. Can you tell me more about your specific setup, so I can investigate?

themchn commented 4 years ago

I am running a testing + unstable repos system with testing pinned as priority. I've drive both the latest 5.3.0-2 kernel in the repos as well as building 5.3.9 from repo source to enable the CONFIG_SUSPEND_SKIP_SYNC option. Overall the system is very minimal with no login manager and only awesomewm which is initiated via startx. If you want any specific information please let me know, I'm just not sure what is all relevant.

nailfarmer commented 4 years ago

Hi @t2d! I'm running debian unstable and the same kernels as @themchn.

So it looks like there are two separate issues with unmkinitramfs.

The first is that unmkinitramfs handles prepended initramfs images differently, by extracting the first bit into a subdirectory called "early" and the rest into a subdirectory called "main". Unprepended initramfs images are just extracted directly. So when we use unmkinitramfs, we need to handle these two cases.

The bigger issue is that when the prepended image is extracted, the symlink to the linker at main/lib64/ld-linux-x86-64.so is broken, so it's not even possible to chroot into the extracted image using the shipped main/bin/sh. What's strange is that not all of the symlinks in the extracted image are broken; main/lib, main/lib32, and main/lib64 are all functional.

Looking at the unmkinitramfs source and with some minimal testing, this looks to be a result of passing the "--no-absolute-filenames" flag to cpio. Removing this flag allows unmkinitramfs to extract prepended images without breakage.

I'll file a bug against unmkinitramfs, since this is probably not intended behaviour. Hopefully, we can make use of it again in the near future!

t2d commented 4 years ago

Thanks @nailfarmer. On my systems there are no prepended images, so this explains why it introduces an error for you. Thank you for investigating and even filing a bug report upstream!

nailfarmer commented 4 years ago

@t2d Thanks for discovering unmkinitramfs and submitting a pull request! I think it's the right way to go if we can get this behaviour fixed.

nailfarmer commented 4 years ago

It turns out that unmkinitramfs was failing as a result of a bug in cpio, which has since been fixed in testing/unstable (and never manifested in stable). I've switched back over to unmkinitramfs in the interests of robustness. Both prepended and unprepended images should be supported, but please let me know if this breaks anything, since I don't have any unprepended images to test against.