FS#48222 - [mkinitcpio] sd-shutdown hook doesn't work, proposed fixes.

Attached to Project: Arch Linux
Opened by Vorbote (vorbote) - Wednesday, 17 February 2016, 15:26 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 17 February 2016, 22:53 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Thomas Bächler (brain0)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This report started as a small murder mystery in the thread starting at <https://lists.archlinux.org/pipermail/arch-general/2016-February/040732.html>. The OP has problems with losing the encrypted root before finishing shutdown, pulling the rug under systemd so to speak and leaving the system in an unstable state.

Some digging showed an oversight in the sd-shutdown hook: it doesn't include the needed systemd service in the generated initramfs. The fix is simple but makes sd-shutdown depend on the add_systemd_unit() function provided by the systemd hook. Not a real loss, it doesn't work otherwise.

The second problem is the dissapearing root if using an encrypted filesystem for roofs. My proposal is to move to copy the initramfs to RAM at the start of the OS session, when basic.target is reached so that it is available even when booting into rescue mode; this matches more or less the behaviour of the old shell-based base+udev+shutdown hooks and not at the end of the live of the OS session.

Another option is to use "Requires/Before=shutdown.target umount.target final.target" as do the upstream services such as poweroff and related targets (I haven't tested this yet).

And there is a third problem. The base hook and the systemd hook have serious incompatibilities. Case in point: the combination of the base and systemd hooks break the sd-shutdown hook. I suspect that there is a need to add actual system utilities to the initramfs if using the systemd hook, instead of relying on busybox. Pulling in systemd already included glibc, thus including bash, the strictly necessary parts of coreutils and util-linux and the fsck utils if the hook is added by the user is not too crazy. For example, Fedora's dracut includes everything and the kitchensink in its initramfs by default and Debian iintramfs scripts are not too far behind.
This task depends upon

Closed by  Dave Reisner (falconindy)
Wednesday, 17 February 2016, 22:53 GMT
Reason for closing:  Works for me
Comment by Vorbote (vorbote) - Wednesday, 17 February 2016, 15:29 GMT
Forgot to mention. That the inclusion of coreutils and uti-linux files could be from the systemd hook or creating an sd-base hook.
Comment by Dave Reisner (falconindy) - Wednesday, 17 February 2016, 15:35 GMT
You aren't supposed to add the sd-shutdown hook directly to your config. It's essentially an implementation detail called by mkinitcpio-generate-shutdown-ramfs.service (not the opposite). Your first proposed patch isn't a sane thing to do.

I think the best I can offer here is a documentation update.
Comment by Vorbote (vorbote) - Wednesday, 17 February 2016, 16:51 GMT
Hmmm... I understand. I'll keep digging into the shutdown hang on encrypted root. BTW, is sd-vconsole an implementation detail as well? I found no evidence in the source code I've read until now.

I do think that adding "Before=shutdown.target umount.target final.target" creates a safety net as it pivots out of the physical filesystem.
Comment by Dave Reisner (falconindy) - Wednesday, 17 February 2016, 17:17 GMT
I'm not sure what this safety net is... the service I mentioned *will* run before the pivot takes place. It can't possibly occur after that.

edit: no, sd-vconsole isn't an implementation detail. It's meant to be added if you want vconsole stuff to be dealt in early userspace.
Comment by Vorbote (vorbote) - Wednesday, 17 February 2016, 22:45 GMT
I'll do more digging with encrypted root setups using VMs and see how my suspicions hold. Untill now, I've used arch on bare metal (reinstalling with encryption as it is is a bore). I'll report back if I find something in this direction of thought or anything that looks strange wrt the behavior reported in the arch-general thread.

The safety net I refer to is the warranty that initramfs unpacking will happen before the encrypted filesystem is closed. That, I suspect, is what causes the shutdown process to hang.

Cheers.
Comment by Dave Reisner (falconindy) - Wednesday, 17 February 2016, 22:53 GMT
Closing for now, then.

Loading...