After upgrading systemd from 0:252.4-4.fc38.x86_64 to 0:253~rc1-1.fc38.x86_64, initramfs images created with dracut are slightly smaller and they hang on waiting on lvm devices when rebooted. -rw------- 1 root root 20858769 Jan 25 14:36 initramfs-6.2.0-0.rc4.20230120gitd368967cb103.35.fc38.x86_64.img -rw------- 1 root root 21087601 Jan 25 14:31 initramfs-6.2.0-0.rc4.20230120gitd368967cb103.35.fc38.x86_64.img.good The only change in verbose dracut output is this: # diff -u /tmp/good /tmp/bad |less --- /tmp/good 2023-01-25 14:34:58.565000000 +0100 +++ /tmp/bad 2023-01-25 14:36:30.378000000 +0100 @@ -66,12 +66,12 @@ dracut: *** Hardlinking files *** dracut: Mode: real dracut: Method: sha256 -dracut: Files: 1643 +dracut: Files: 1641 dracut: Linked: 12 files dracut: Compared: 0 xattrs dracut: Compared: 434 files dracut: Saved: 396.88 KiB -dracut: Duration: 0.029792 seconds +dracut: Duration: 0.029782 seconds dracut: *** Hardlinking files done *** dracut: *** Generating early-microcode cpio image *** dracut: *** Store current command line parameters *** This is the infinite wait on boot in initramfs: [ OK ] Started systemd-journald.service - Journal Service. Starting systemd-tmpfiles- Volatile Files and Directories... [ OK ] Finished systemd-tmpfiles- te Volatile Files and Directories. [ OK ] Finished systemd-vconsole- rvice - Setup Virtual Console. Starting dracut-cmdline.service - dracut cmdline hook... [ OK ] Finished dracut-cmdline.service - dracut cmdline hook. Starting dracut-pre-udev.s vice - dracut pre-udev hook... [ OK ] Finished dracut-pre-udev.service - dracut pre-udev hook. Starting systemd-udevd.ser ger for Device Events and Files... [ OK ] Started systemd-udevd.serv nager for Device Events and Files. Starting systemd-udev-trig [0m - Coldplug All udev Devices... [ OK ] Finished systemd-udev-trig e - Coldplug All udev Devices. [ OK ] Reached target sysinit.target - System Initialization. [ OK ] Reached target basic.target - Basic System. Starting dracut-initqueue. ice - dracut initqueue hook... [ OK ] Finished dracut-initqueue. rvice - dracut initqueue hook. [ OK ] Reached target remote-fs-p eparation for Remote File Systems. [ OK ] Reached target remote-fs.target - Remote File Systems. Starting dracut-pre-mount. ice - dracut pre-mount hook... [ OK ] Finished dracut-pre-mount. rvice - dracut pre-mount hook. [ *** ] Job dev-mapper-vg_dhcp30157\x2dlv_r vice/start running (5s / no limit) [ 7.398676] systemd-udevd (354) used greatest stack depth: 12584 bytes left [ *** ] Job dev-mapper-vg_dhcp30157\x2dlv_r vice/start running (9s / no limit)
This is the difference in files presented in the initramfs images: # diff -u good.list bad.list --- good.list 2023-01-25 15:42:13.369000000 +0100 +++ bad.list 2023-01-25 15:42:18.495000000 +0100 @@ -208,9 +208,6 @@ ./usr/lib64/libedit.so.0.0.70 ./usr/lib64/libext2fs.so.2 ./usr/lib64/libext2fs.so.2.4 -./usr/lib64/libffi.so -./usr/lib64/libffi.so.8 -./usr/lib64/libffi.so.8.1.2 ./usr/lib64/libfreebl3.so ./usr/lib64/libfreeblpriv3.chk ./usr/lib64/libfreeblpriv3.so @@ -236,9 +233,6 @@ ./usr/lib64/libnss_mymachines.so.2 ./usr/lib64/libnss_resolve.so.2 ./usr/lib64/libnss_systemd.so.2 -./usr/lib64/libp11-kit.so -./usr/lib64/libp11-kit.so.0 -./usr/lib64/libp11-kit.so.0.3.0 ./usr/lib64/libpam.so ./usr/lib64/libpam.so.0 ./usr/lib64/libpam.so.0.85.1 @@ -258,13 +252,13 @@ ./usr/lib64/libsmartcols.so.1.1.0 ./usr/lib64/libsystemd.so ./usr/lib64/libsystemd.so.0 -./usr/lib64/libsystemd.so.0.35.0 +./usr/lib64/libsystemd.so.0.36.0 ./usr/lib64/libtinfo.so ./usr/lib64/libtinfo.so.6 ./usr/lib64/libtinfo.so.6.4 ./usr/lib64/libudev.so ./usr/lib64/libudev.so.1 -./usr/lib64/libudev.so.1.7.5 +./usr/lib64/libudev.so.1.7.6 ./usr/lib64/libuuid.so ./usr/lib64/libuuid.so.1 ./usr/lib64/libuuid.so.1.3.0 @@ -275,8 +269,8 @@ ./usr/lib64/libzstd.so.1 ./usr/lib64/libzstd.so.1.5.2 ./usr/lib64/systemd -./usr/lib64/systemd/libsystemd-core-252.4-4.fc38.so -./usr/lib64/systemd/libsystemd-shared-252.4-4.fc38.so +./usr/lib64/systemd/libsystemd-core-253-rc1-1.fc38.so +./usr/lib64/systemd/libsystemd-shared-253-rc1-1.fc38.so ./usr/lib/dracut ./usr/lib/dracut/build-parameter.txt ./usr/lib/dracut-dev-lib.sh @@ -1818,7 +1812,6 @@ ./usr/lib/systemd/system/slices.target ./usr/lib/systemd/system/sockets.target ./usr/lib/systemd/system/sockets.target.wants -./usr/lib/systemd/system/sockets.target.wants/systemd-journald-audit.socket ./usr/lib/systemd/system/sockets.target.wants/systemd-journald-dev-log.socket ./usr/lib/systemd/system/sockets.target.wants/systemd-journald.socket ./usr/lib/systemd/system/sockets.target.wants/systemd-udevd-control.socket
/usr/lib64/libp11-kit.so is now dlopen'ed, instead of being linked statically. libp11-kit was linked to libffi. But I don't think libp11-kit is necessary for lvm. I don't think that this is the cause of the boot failure. Also systemd-journald-audit.socket is probably unrelated. I'll try to debug this, but maybe attach a boot log if you have it.
Booted qithout rhgb quiet and level 3 Last message is Reached target remote-fs.target Is there a more detailed debug parameter? I can help test either a workaround or a fix
This is likely the same issue as bug 2164594.
I first suffered from bug #2164594. Then I noticed selinux_status_open() failure in initramfs run. But neither kernel, nor libselinux, nor selinux-policy have changed. So I tried regenerating initramfs to see whether it helps. It did not help (what helped was disabling SELinux in kernel arguments), but surfaced this initramfs generation bug #2164404. Maybe they have the same cause.
The LVM issue still happens with systemd-253~rc1-3.fc38.x86_64. (Also the SELinux issue continues. But I'm unable to ascribe the SELinux issue to any RPM package.)
Changing selinux to enforcing=0 on boot allowed a successful boot for me
systemd-253~rc1-3 solved the selinux enforcing problem for me.
I was able to overcome the SELinux failure with relabeling the whole file system. I had to boot with enforcing=0 for that. It seems that selinux=0 prevents from relabaling the file system. Nevertheless, dracut run on systemd-0:253~rc1-3.fc38.x86_64 still creates a broken initramfs for me manifesting the same infinite wait on a block device. Tested with kernel-6.2.0-0.rc6.20230131git22b8077d0fce.45.fc38.x86_64.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
Still an issue for me (systemd-0:253~rc2-7.fc39.x86_64).
This seems to be the same as https://github.com/systemd/systemd/issues/26488. We discussed this with dracut maintainers and somebody will prep a patch for dracut. But for now I'll apply the upstream PR to disable the sandbox in the initrd.
FEDORA-2023-9e6007f165 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-9e6007f165
FEDORA-2023-73fea9469f has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-73fea9469f
Thanks. I confirm that this fixes the problem for me in Fedora 39.
FEDORA-2023-9e6007f165 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-5690f5f379 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5690f5f379 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-5690f5f379 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
The patch in systemd was supposed to be temporary. Does anyone know if dracut was updated? I'd like to drop the patch from systemd.
Upstream Dracut issue <https://github.com/dracutdevs/dracut/issues/2211> is closed, pull request implementing the fix <https://github.com/dracutdevs/dracut/pull/2270> is closed. The fix in upstream git tree <https://github.com/dracutdevs/dracut/commit/86c8a5a7c2573645e67537fb9975efab808d42c9>. No yet released. Maybe because it caused a regression <https://github.com/dracutdevs/dracut/issues/2349> which is still unresolved. So I guess Fedora's dracut is still affected.
Thanks. I'll recheck after the next dracut release then.