[Bug 1228659] New: Snapshot 20240730 - unbootable after transactional-update dup
https://bugzilla.suse.com/show_bug.cgi?id=1228659 Bug ID: 1228659 Summary: Snapshot 20240730 - unbootable after transactional-update dup Classification: openSUSE Product: openSUSE Aeon Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Transactional Update Assignee: aplanas@suse.com Reporter: rbrown@suse.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- All Aeon installations (and I suspect all MicroOS systemd-boot installations) are failing to boot after a transactional-update dup to the latest snapshot I suspect the cause is the misbehaviour of the sdbootutil plugin reported during the transactional-update Example logs below: (25/41) Installing: kernel-default-6.10.2-1.1.x86_64 [... Error: No ESP detected. Legacy system? ................................................................................................... Error: No ESP detected. Legacy system? Error: No ESP detected. Legacy system? dracut[I]: Executing: /usr/bin/dracut -f /boot/initrd-6.10.2-1-default 6.10.2-1-default dracut[I]: Module 'systemd-networkd' will not be installed, because command 'networkctl' could not be found! dracut[I]: Module 'systemd-networkd' will not be installed, because command '/usr/lib/systemd/systemd-networkd' could not be found! dracut[I]: Module 'systemd-networkd' will not be installed, because command '/usr/lib/systemd/systemd-networkd-wait-online' could not be found! dracut[I]: Module 'systemd-portabled' will not be installed, because command 'portablectl' could not be found! dracut[I]: Module 'systemd-portabled' will not be installed, because command '/usr/lib/systemd/systemd-portabled' could not be found! dracut[I]: Module 'systemd-resolved' will not be installed, because command 'resolvectl' could not be found! dracut[I]: Module 'systemd-resolved' will not be installed, because command '/usr/lib/systemd/systemd-resolved' could not be found! dracut[I]: Module 'dbus-broker' will not be installed, because command 'dbus-broker' could not be found! dracut[I]: Module 'rngd' will not be installed, because command 'rngd' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmand' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut[I]: 35network-legacy: Could not find any command of 'dhclient wicked'! dracut[I]: Module 'dmraid' will not be installed, because command 'dmraid' could not be found! dracut[I]: Module 'pcsc' will not be installed, because command 'pcscd' could not be found! dracut[I]: Module 'iscsi' will not be installed, because command 'iscsi-iname' could not be found! dracut[I]: Module 'iscsi' will not be installed, because command 'iscsiadm' could not be found! dracut[I]: Module 'iscsi' will not be installed, because command 'iscsid' could not be found! dracut[I]: 95nfs: Could not find any command of 'rpcbind portmap'! dracut[I]: Module 'nvmf' will not be installed, because command 'nvme' could not be found! dracut[I]: Module 'biosdevname' will not be installed, because command 'biosdevname' could not be found! dracut[I]: Module 'memstrack' will not be installed, because command 'memstrack' could not be found! dracut[I]: memstrack is not available dracut[I]: If you need to use rd.memdebug>=4, please install memstrack and procps-ng dracut[I]: Module 'squash' will not be installed, because command 'mksquashfs' could not be found! dracut[I]: Module 'squash' will not be installed, because command 'unsquashfs' could not be found! dracut[I]: Module 'systemd-portabled' will not be installed, because command 'portablectl' could not be found! dracut[I]: Module 'systemd-portabled' will not be installed, because command '/usr/lib/systemd/systemd-portabled' could not be found! dracut[I]: Module 'systemd-resolved' will not be installed, because command 'resolvectl' could not be found! dracut[I]: Module 'systemd-resolved' will not be installed, because command '/usr/lib/systemd/systemd-resolved' could not be found! dracut[I]: Module 'dbus-broker' will not be installed, because command 'dbus-broker' could not be found! dracut[I]: Module 'rngd' will not be installed, because command 'rngd' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmand' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut[I]: Module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut[I]: 35network-legacy: Could not find any command of 'dhclient wicked'! dracut[I]: Module 'dmraid' will not be installed, because command 'dmraid' could not be found! dracut[I]: Module 'pcsc' will not be installed, because command 'pcscd' could not be found! dracut[I]: Module 'iscsi' will not be installed, because command 'iscsi-iname' could not be found! dracut[I]: Module 'iscsi' will not be installed, because command 'iscsiadm' could not be found! dracut[I]: Module 'iscsi' will not be installed, because command 'iscsid' could not be found! dracut[I]: 95nfs: Could not find any command of 'rpcbind portmap'! dracut[I]: Module 'nvmf' will not be installed, because command 'nvme' could not be found! dracut[I]: Module 'memstrack' will not be installed, because command 'memstrack' could not be found! dracut[I]: memstrack is not available dracut[I]: If you need to use rd.memdebug>=4, please install memstrack and procps-ng dracut[I]: Module 'squash' will not be installed, because command 'mksquashfs' could not be found! dracut[I]: Module 'squash' will not be installed, because command 'unsquashfs' could not be found! dracut[I]: *** Including module: systemd *** dracut[I]: *** Including module: systemd-initrd *** dracut[I]: *** Including module: i18n *** dracut[I]: No KEYMAP configured. dracut[I]: *** Including module: drm *** dracut[I]: *** Including module: health-checker *** dracut-install: ERROR: installing 'grub2-editenv' dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.kGpiZ2/initramfs -a date btrfs awk grub2-editenv dracut[I]: *** Including module: pcr-signature *** dracut[I]: *** Including module: transactional-update *** dracut[I]: *** Including module: btrfs *** dracut[I]: *** Including module: kernel-modules *** udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory dracut[I]: *** Including module: kernel-modules-extra *** dracut[I]: *** Including module: rootfs-block *** dracut[I]: *** Including module: suse-btrfs *** dracut[I]: *** Including module: suse-xfs *** dracut[I]: *** Including module: terminfo *** dracut[I]: *** Including module: udev-rules *** udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory dracut[E]: Failed to detect udev version! dracut[I]: *** Including module: dracut-systemd *** dracut[I]: *** Including module: ostree *** dracut[I]: *** Including module: selinux-microos *** dracut[I]: *** Including module: usrmount *** dracut[I]: *** Including module: base *** dracut[I]: *** Including module: fs-lib *** dracut[I]: *** Including module: shutdown *** dracut[I]: *** Including module: suse *** dracut[I]: *** Including module: suse-initrd *** dracut[I]: *** Including modules done *** dracut[I]: *** Installing kernel module dependencies *** dracut[I]: *** Installing kernel module dependencies done *** dracut[I]: *** Resolving executable dependencies *** dracut[I]: *** Resolving executable dependencies done *** dracut[I]: *** Hardlinking files *** dracut[I]: *** Hardlinking files done *** dracut[I]: *** Generating early-microcode cpio image *** dracut[I]: *** Store current command line parameters *** dracut[I]: Stored kernel commandline: dracut[I]: rd.driver.pre=btrfs dracut[I]: rd.driver.pre=overlay dracut[I]: root=UUID=42fc02eb-e038-424f-b5a5-aed45173338d rootfstype=btrfs rootflags=rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=403,subvol=/@/.snapshots/98/snapshot,subvol=@/.snapshots/98/snapshot dracut[I]: *** Stripping files *** dracut[I]: *** Stripping files done *** dracut[I]: *** Creating image file '/boot/initrd-6.10.2-1-default' *** dracut[I]: *** Creating initramfs image file '/boot/initrd-6.10.2-1-default' done *** /usr/lib/bootloader/bootloader_entry: line 117: /etc/sysconfig/bootloader: No such file or directory CA enrolled. Skip /etc/uefi/certs/1F673297.crt Error: No ESP detected. Legacy system? ... Error: No ESP detected. Legacy system? Error: No ESP detected. Legacy system? /usr/lib/bootloader/bootloader_entry: line 117: /etc/sysconfig/bootloader: No such file or directory done] -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c1 --- Comment #1 from Richard Brown <rbrown@suse.com> --- Tried to get more information by booting with a higher loglevel or systemd status but editing the cmdline proved pointless as the 'panic' clearly happens before that -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c3 Richard Brown <rbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Brown <rbrown@suse.com> --- Workaround / Fix run sudo echo "LOADER_TYPE=systemd-boot" > /etc/sysconfig/bootloader It's then safe to run transactional-update dup again and re-enable the transactional-update.timer We'll work on a better long term fix for such issues in the future, meanwhile I'm afraid every Aeon user will need to run this themselves, sadly. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c4 --- Comment #4 from Richard Brown <rbrown@suse.com> --- Workaround / Fix run echo "LOADER_TYPE=systemd-boot" | sudo tee /etc/sysconfig/bootloader It's then safe to run transactional-update dup again and re-enable the transactional-update.timer We'll work on a better long term fix for such issues in the future, meanwhile I'm afraid every Aeon user will need to run this themselves, sadly. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c5 --- Comment #5 from OBSbugzilla Bot <bwiedemann+obsbugzillabot@suse.com> --- This is an autogenerated message for OBS integration: This bug (1228659) was mentioned in https://build.opensuse.org/request/show/1190689 Factory / tik-osimage-Aeon -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c6 Eduardo Medina <edurayasmedina@outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |edurayasmedina@outlook.com --- Comment #6 from Eduardo Medina <edurayasmedina@outlook.com> --- Hi, the workaround doesn't work for me with Linux Linux 10.2-1. I have 'LOADER_TYPE=systemd-boot' set with the 6.9.9-1-default kernel and the system boots correctly, but with Linux 10.2-1 I can't boot my desktop computer with an ASUS TUF GAMING B660-PLUS WIFI D4 motherbardo and an Intel Core i5-12600K CPU. My desktop uses Aeon from the RC2 while my Acer Laptop uses the system from RC3. My laptop is not using Linux 10.2-1, I don't why because I did the update manually. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c7 --- Comment #7 from Eduardo Medina <edurayasmedina@outlook.com> --- Created attachment 876412 --> https://bugzilla.suse.com/attachment.cgi?id=876412&action=edit failed transactional-update dup This is what I get when I do transactional-update dup in my laptop. I have Secure Boot and TPM disabled to force the use of disk encryption in fallback mode. I don't know if it would be better downgrading the kernel. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c8 --- Comment #8 from Eduardo Medina <edurayasmedina@outlook.com> --- I saw that my laptop doesn't update since I installed the system. All the snapshots are from July 26th, so this is another bug. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c9 --- Comment #9 from Eduardo Medina <edurayasmedina@outlook.com> --- I swear this is my last message here. I could update my laptop successfully with transactional-update shell and I have the same result: the computer doesn't boot, even after enabling Secure Boot. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c10 Benjamin Sabatini <sunscape1@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- CC| |sunscape1@hotmail.com --- Comment #10 from Benjamin Sabatini <sunscape1@hotmail.com> --- Unfortunately, the fix in comment #4 does not fix the problem for everyone, including me. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c11 --- Comment #11 from Richard Brown <rbrown@suse.com> --- in addition to the /etc/sysconfig/bootloader workaround it would appear that folk need to do transactional-update run zypper up systemd-boot systemd Reboot and then do normal updates -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 Alberto Planas Dominguez <aplanas@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aplanas@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c12 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk@suse.com --- Comment #12 from Thorsten Kukuk <kukuk@suse.com> --- (In reply to Richard Brown from comment #11)
in addition to the /etc/sysconfig/bootloader workaround
This workaround does not work for me. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c14 --- Comment #14 from Alberto Planas Dominguez <aplanas@suse.com> --- There are several issues: * /usr/lib/bootloader/bootloader_entry: line 117 That is fixed with the /etc/sysconfig/bootloader creation * libsystemd v255 instead of v256 It is present in some systems, and not in others. I do not see it in this bug report log. * No ESP detected. Legacy system? That is sdbootutil complaining when boot_root cannot be found. I am trying to reproduce this one, and can be related with systemd 256 update, as is fetched from bootctl. I can focused in this last one. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c17 --- Comment #17 from Alberto Planas Dominguez <aplanas@suse.com> --- I cannot reproduce the issue here, maybe because my systems are in systemd v256. Can I request that some one with the issue report the output of: bootctl 2>/dev/null | sed -ne 's/Firmware Arch: *\(\w\+\)/firmware_arch="\1"/p;s/ *token: *\(\w\+\)/entry_token="\1"/p;s, *\$BOOT: *\([^ ]\+\).*,boot_root="\1",p' It should return something like: firmware_arch="x64" boot_root="/boot/efi" entry_token="opensuse"-microos -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c18 Alberto Planas Dominguez <aplanas@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(aplanas@suse.com) | --- Comment #18 from Alberto Planas Dominguez <aplanas@suse.com> --- (In reply to Richard Brown from comment #13)
My suspicion is that the sdbootutil tukit plugin is still trying to call libsystemd v255 even though the snapshot now has v256
That would explain the 255 not found so errors
But I’m no expert on sdbootutil nor the tukit plugin
Alberto, any ideas?
sdbootutil is calling bootctl outside the transaction (v255) via the tukit plugins, and inside the transaction (v256) via the suse-module-tools-scriptlets to install the new kernel. If the kernel gets updated when systemd is upgraded but libsystemd is not, then we can have this fail. This is the only way that I can think that this issue can happen, but in this case the workaround from #c11 would avoid the situation. From my side I can update sdbootutil to set boot_root to a good default value if bootctl fails -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c19 --- Comment #19 from Alberto Planas Dominguez <aplanas@suse.com> --- (In reply to Alberto Planas Dominguez from comment #18)
From my side I can update sdbootutil to set boot_root to a good default value if bootctl fails
Or a better option is to totally avoid the call inside the transaction. I will check how can be done -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c20 --- Comment #20 from Benjamin Sabatini <sunscape1@hotmail.com> --- (In reply to Alberto Planas Dominguez from comment #17)
I cannot reproduce the issue here, maybe because my systems are in systemd v256.
Can I request that some one with the issue report the output of:
bootctl 2>/dev/null | sed -ne 's/Firmware Arch: *\(\w\+\)/firmware_arch="\1"/p;s/ *token: *\(\w\+\)/entry_token="\1"/p;s, *\$BOOT: *\([^ ]\+\).*,boot_root="\1",p'
It should return something like:
firmware_arch="x64" boot_root="/boot/efi" entry_token="opensuse"-microos
Here you go. In my case neither of the fixes posted thus far help. firmware_arch="x64" boot_root="/boot/efi" entry_token="opensuse"-aeon -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c21 --- Comment #21 from Alberto Planas Dominguez <aplanas@suse.com> --- (In reply to Benjamin Sabatini from comment #20)
Here you go. In my case neither of the fixes posted thus far help.
firmware_arch="x64" boot_root="/boot/efi" entry_token="opensuse"-aeon
If you applied the fixed, you are in systemd 256 right? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c22 --- Comment #22 from Benjamin Sabatini <sunscape1@hotmail.com> --- (In reply to Alberto Planas Dominguez from comment #21)
(In reply to Benjamin Sabatini from comment #20)
Here you go. In my case neither of the fixes posted thus far help.
firmware_arch="x64" boot_root="/boot/efi" entry_token="opensuse"-aeon
If you applied the fixed, you are in systemd 256 right?
Alright, the second fix from comment #11 worked today (it did not last night). After rebooting, it dropped me into emergency mode, but it continued to boot normally after hitting enter (insert shrug emoji...). I'm in 256. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c23 --- Comment #23 from Alberto Planas Dominguez <aplanas@suse.com> --- (In reply to Benjamin Sabatini from comment #22)
(In reply to Alberto Planas Dominguez from comment #21)
(In reply to Benjamin Sabatini from comment #20)
Here you go. In my case neither of the fixes posted thus far help.
firmware_arch="x64" boot_root="/boot/efi" entry_token="opensuse"-aeon
If you applied the fixed, you are in systemd 256 right?
Alright, the second fix from comment #11 worked today (it did not last night). After rebooting, it dropped me into emergency mode, but it continued to boot normally after hitting enter (insert shrug emoji...). I'm in 256.
Aha thanks for confirming that. Then the theory that systemd gets partially updated before the kernel upgrade happens is getting support. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c24 --- Comment #24 from Benjamin Sabatini <sunscape1@hotmail.com> --- (In reply to Benjamin Sabatini from comment #22)
(In reply to Alberto Planas Dominguez from comment #21)
(In reply to Benjamin Sabatini from comment #20)
Here you go. In my case neither of the fixes posted thus far help.
firmware_arch="x64" boot_root="/boot/efi" entry_token="opensuse"-aeon
If you applied the fixed, you are in systemd 256 right?
Alright, the second fix from comment #11 worked today (it did not last night). After rebooting, it dropped me into emergency mode, but it continued to boot normally after hitting enter (insert shrug emoji...). I'm in 256.
Sorry, to be clear, after an immediate reboot, it was fine. After running transactional-update dup and rebooting a second time, it dropped into emergency mode. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c25 --- Comment #25 from Richard Brown <rbrown@suse.com> --- Created attachment 876439 --> https://bugzilla.suse.com/attachment.cgi?id=876439&action=edit broken transactional update log -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c26 --- Comment #26 from Alberto Planas Dominguez <aplanas@suse.com> --- (In reply to Benjamin Sabatini from comment #24)
Sorry, to be clear, after an immediate reboot, it was fine. After running transactional-update dup and rebooting a second time, it dropped into emergency mode.
Can you provide the logs of transactional-update dup? Do you see any errors there? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c27 --- Comment #27 from Alberto Planas Dominguez <aplanas@suse.com> --- (In reply to Richard Brown from comment #25)
Created attachment 876439 [details] broken transactional update log
Ah here it is ... the update order is libsystemd0-256.4-1.2.x86_64 systemd-256.4-1.2.x86_64 systemd-experimental-256.4-1.2.x86_64 kernel-default-6.10.2-1.1.x86_64 systemd-boot-256.4-1.2.x86_64 The kernel is installed before systemd-boot, that contains bootctl. This explain both error messages: Error: No ESP detected. Legacy system? kernel-install: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory The bootctl executed from the %post scriptlet in the kernel (from suse-module-tools, that calls sdbootutil, that calls bootctl) is still from v255, and the libraries are already in v256. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c28 --- Comment #28 from Richard Brown <rbrown@suse.com> --- Rolled my system back to 20240726 so I could recreate all the requested info Only fix still present on my system is /etc/sysconfig/bootloader, so we can debug the remaining two issues at will First some sanity checks
zypper se -is systemd
i | libsystemd0 | package | 255.8-1.1 | x86_64 | (System Packages) i+ | systemd | package | 255.8-1.1 | x86_64 | (System Packages) i+ | systemd-boot | package | 255.8-1.1 | x86_64 | (System Packages)
Can I request that some one with the issue report the output of:
bootctl 2>/dev/null | sed -ne 's/Firmware Arch: *\(\w\+\)/firmware_arch="\1"/p;s/ *token: *\(\w\+\)/entry_token="\1"/p;s, *\$BOOT: *\([^ ]\+\).*,boot_root="\1",p'
It should return something like:
firmware_arch="x64" boot_root="/boot/efi" entry_token="opensuse"-microos
bootctl 2>/dev/null | sed -ne 's/Firmware Arch: *\(\w\+\)/firmware_arch="\1"/p;s/ *token: *\(\w\+\)/entry_token="\1"/p;s, *\$BOOT: *\([^ ]\+\).*,boot_root="\1",p' firmware_arch="x64" boot_root="/boot/efi" entry_token="opensuse"-aeon Now showing what happens with transactional-update dup in this state - full log attached https://bugzilla.opensuse.org/attachment.cgi?id=876439 Extracts I think are relevant
( 9/41) Installing: libsystemd0-256.4-1.2.x86_64 [...done]
libsystemd was installed as package number 9
(17/41) Installing: systemd-256.4-1.2.x86_64 [.....
Systemd is installed as package number 17
(18/41) Installing: systemd-experimental-256.4-1.2.x86_64 [...
systemd-experimental is installed as package number 18
(25/41) Installing: kernel-default-6.10.2-1.1.x86_64 [...
Kernel is installed as package number 25
udevadm: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory kernel-install: error while loading shared libraries: libsystemd-shared-255.so: cannot open shared object file: No such file or directory
During the kernel install there are a number of failures all referencing libsystemd v255 being missing..because it should be missing, libsystemd v256 was installed at package number 9
(26/41) Installing: udev-256.4-1.2.x86_64 [....done]
udev 256 only gets installed as package number 26..maybe it should be installed BEFORE the kernel given we just saw the kernel package install trying to use udevadm? udev 256 is the provider of both udevadm and kernel-install
(32/41) Installing: systemd-boot-256.4-1.2.x86_64 [...done]
systemd-boot gets installed as package number 32... HYPOTHESIS - the dependencies of packages udev and the kernel are apparently wrong, with udev being installed AFTER the kernel when it should be BEFORE. The log above shows the installation of the kernel package clearly using udevadam and kernel-install from the udev package, but the udev package at that point is broken because libsystemd v256 was already installed and the out-of-date, not yet updated, udev/kernel-install cannot find the libsystemd v255 they were built against. Based on Alberto's awesome background information in Comment #18 I'm therefore suspecting the correct place to fix this is either in the kernel packaging or suse-module-tools-scriptlets As mwilck is on vacation, any suggestions who to send this bug towards? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 Richard Brown <rbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|rbrown@suse.com |systemd-maintainers@suse.de -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 Wayne Patton <wayne.patton@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wayne.patton@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 Han Hui Teoh <teohhanhui@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |teohhanhui@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1228659 https://bugzilla.suse.com/show_bug.cgi?id=1228659#c40 Jan Engelhardt <jengelh@inai.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jengelh@inai.de --- Comment #40 from Jan Engelhardt <jengelh@inai.de> ---
[comment #35]
The problem is dependencies are computed once for the whole transaction. So, when transaction starts, all dependencies are correct. Now, in the middle of transaction zypper updates systemd from v255 to v256 and it immediately invalidates all computed dependencies involving other systemd subpackages.
However, the v255 libraries should not even have been removed while packages are still getting installed. To the best of my knowledge, "cleanup", as it is called, should happen at the _end_ of the transaction. Of course, when zypper is not running in single-transaction mode, issues as observed can arise. Is there a way for you to retry the operation with `export ZYPP_SINGLE_RPMTRANS=1`? -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com