Description of problem: During update of systemd-udev-246.7-2.fc33.x86_64, dnf emitted the following messages: /usr/bin/udevadm: symbol lookup error: /usr/bin/udevadm: undefined symbol: _set_put_strdup, version SD_SHARED /usr/bin/udevadm: symbol lookup error: /usr/bin/udevadm: undefined symbol: _set_put_strdup, version SD_SHARED Version-Release number of selected component (if applicable): 246.7-2.fc33.x86_64 How reproducible: unknown Steps to Reproduce: 1. dnf upgrade 2. 3. Actual results: Error messages Expected results: Quiet Additional info:
Hmm, looks like systemd-libs was upgraded before systemd-udev. Maybe we need to add a Require(pre) dependency?
Please attach the full log from the transaction: call 'dnf history list' to find the right transaction, and then 'dnf history info NNN | tee logfile' and attach 'logfile' here.
Created attachment 1754491 [details] Requested log
Hmm, this is very strange. It seems that after the installation, systemd-udev and systemd have mismatched versions. But in the log, systemd-udev-246.7-2.fc33.x86_64 and systemd-246.7-2.fc33.x86_64 are installed. https://github.com/systemd/systemd/issues/18822 was similar. But there the installation crashed, so I assumed that the corruption was caused by that. When I create a local installation with systemd-246.7-2.fc33.x86_64, udevadm runs without issue. Hmm. Does the issue still occur if you call udevadm from the command line?
When I install systemd-246.6-3.fc33.x86_64, and then upgrade, udevadm also seems to work as expected: Running scriptlet: systemd-udev-246.7-2.fc33.x86_64 5/10 Upgrading : systemd-udev-246.7-2.fc33.x86_64 5/10 Running scriptlet: systemd-udev-246.7-2.fc33.x86_64 5/10 Running scriptlet: systemd-udev-246.6-3.fc33.x86_64 6/10 Cleanup : systemd-udev-246.6-3.fc33.x86_64 6/10 Running scriptlet: systemd-udev-246.6-3.fc33.x86_64 6/10 System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down Running scriptlet: systemd-246.6-3.fc33.x86_64 7/10 I really don't understand why you can get linkage errors.
I was looking into a similar error on some hosts when trying to run udevadm: ``` Error running /sbin/udevadm info --export-db: /sbin/udevadm: symbol lookup error: /sbin/udevadm: undefined symbol: fchmod_and_chown, version SD_SHARED ``` For us, based on the timing of the command, it seems to be due to running udevadm in the middle of the RPM transaction. This showed up when running udevadm between the `systemctl daemon-reexec` call and `systemctl restart systemd-udevd` calls in the scriptlets. Not sure if there's a way around this except to not not run udevadm during the systemd RPM transaction.
There is a solution that we could do. I have been thinking whether it's worth it based on the single report, but since this seems to occur more often, then it seems reasonable to do. Basically, libsystemd-shared-nnn.so would be packaged as libsystemd-shared-%{release}-%{version}.so, which would make it possible to execute any binary in scriptlets during package upgrades. It would also have the advantage that the upgrade would be slightly more resilient to a failure midway through the transaction, e.g. in case of a hard reboot. I'll try to look into this when I have some time, but if somebody would contribute a patch that'd be great too ;)
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
https://github.com/systemd/systemd/pull/21774
FEDORA-2022-3d496adfa0 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3d496adfa0
FEDORA-2022-3d496adfa0 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-547b0bc17c has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-547b0bc17c
FEDORA-2022-547b0bc17c has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-6b91a6b9db has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6b91a6b9db
FEDORA-2022-6b91a6b9db has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
This was reverted because of selinux issues. They should be fixed now, so let's try again.
Let's mark this as fixed. I hope it doesn't blow up this time.