Open miabbott opened 1 month ago
Comment from @jlebon that was made on original issue (https://github.com/dracutdevs/dracut/issues/2656) :
OK yeah, I thought FCOS/RHCOS didn't actually use the initramfs on shutdown. And it doesn't by default, but that changed when we started supporting iSCSI and multipathing, whose dracut modules both use need_shutdown (which is what signals that going back to the initramfs at shutdown is desirable).
So yeah... booting FCOS with multipath enabled reproduces this bug. Which means we weren't running this bit of code. Though talking with @bmarzins, the consequence of this cannot result from data loss in any way.
As for iSCSI, the module itself doesn't install a shutdown hook like the multipath one does, but maybe it's for the purpose of running the generic umount shutdown code to unmount the rootfs to ensure all data is flushed back to the target?
But yes, we should definitely fix this.
(Originally filed as https://github.com/dracutdevs/dracut/issues/2656)
Describe the bug
The
dracut-initramfs-restore.sh
script fails duringdracut-shutdown.service
on ostree-based systems because it incorrectly looks for the initramfs in the wrong location.Distribution used
I've observed this on RHEL for Edge 9.4 and Fedora Silverblue 40
Dracut version
dracut-057-53.git20240104.el9.x86_64
dracut-101-1.fc40.x86_64
Init system
systemd
To Reproduce
Expected behavior
The
dracut-initramfs-restore.sh
script should correctly find the initramfs image and unpack it to/run
Additional context
The script appears to be incorrectly identifying the initrd at
/boot/efi/$MACHINE_ID/$KERNEL_VERSION/initrd
, but that doesn't exist on ostree systems. However, the error does not appear to be fatal to the overall system shutdown.On the Fedora Silverblue 40 system:
On the RHEL for Edge 9.4 system:
I think the script could be changed to look for
/run/ostree-booted
and then unpack the initramfs.img from/usr/lib/modules/${KERNEL_VERSION}/initramfs.img
Logs from RHEL from Edge 9.4
Logs from Fedora Silverblue 40