Bug 2164404
Summary: | systemd-253~rc1-1.fc38.x86_64 breaks initramfs, infinite wait on device mapper devices | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Petr Pisar <ppisar> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 38 | CC: | darrellpf, dtardon, fedoraproject, filbranden, lnykryn, msekleta, ryncsn, systemd-maint, yuwatana, zbyszek, zjedrzej |
Target Milestone: | --- | Keywords: | Regression |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | systemd-253-3.fc39 systemd-253-6.fc38 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-02-21 15:58:29 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Petr Pisar
2023-01-25 13:45:02 UTC
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. |