fix(dracut-shutdown): add cleanup handler on failure

[rmetrich]

It may happen that dracut-shutdown.service fails, for example on timeout due to very low bandwidth.
In such case, for hardening purposes, a new dracut-shutdown-onfailure.service unit doing dracut-shutdown.service cleanup needs to execute to make sure switching root to an incomplete initramfs won't occur later.

See also RHBZ #1924587.

This pull request changes...

Changes

Checklist

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

Fixes #

[rmetrich]

See also related plymouth PR https://github.com/freedesktop/plymouth/pull/6
(plymouth must run after dracut-shutdown-on-failure when the latter executes)

[rmetrich]

Serial console output on success (similar to current code):

[  OK  ] Stopped Restore /run/initramfs on shutdown.
         Starting Tell Plymouth To Jump To initramfs...
[  OK  ] Stopped target Local File Systems.
         Unmounting /boot...
[  OK  ] Started Tell Plymouth To Jump To initramfs.
[  OK  ] Unmounted /boot.

Serial console output on failure (no jump to initramfs):

[  OK  ] Stopped Restore /run/initramfs on shutdown.
         Starting Service executing upon dra…down failure to perform cleanup...
[  OK  ] Stopped target Local File Systems.
         Unmounting /boot...
[  OK  ] Started Service executing upon drac…utdown failure to perform cleanup.
[  OK  ] Unmounted /boot.

[johannbg]

@rmetrich looking at that bz.rh report I think you should do two things before proceeding further a) try to find what's the actual root cause for the unpacking failing in the first place and b) try to duplicate it on a distribution which has more modern core/baseOS stack since RHEL releases are made out of outdate core/base OS components.

[rmetrich]

I agree RHEL is quite behind but IMHO hardening is still valuable.

I saw this recently on HP hardware which was sending burst of Ctrl-Alt-Del. There was a PR to harden this which is now upstream (commit #b9ba3c8bb8f0f1328cd1ffaa8dbf64585b28c474).
More generally hardware issues may happen that lead to getting to emergency prompt, I see this regularly, e.g. Virtual DVD being unmounted due to iLO timeout while shutdown of installation occurs.

[johannbg]

With regards to the dvd/ilo issue is not the issue there that the admin has not increased the idle timeout in the firmware? In properly designed OS it needs to be consistent throughout the OS ( which is not the case in Fedora/rhel ) and the relevant hw firmware as well.