Latest upstream release: 2.3.0 Current version/release in rawhide: 2.2.53-10.fc34 URL: https://savannah.nongnu.org/projects/acl Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/16/
Created attachment 1762769 [details] [patch] Update to 2.3.0 (#1937956)
the-new-hotness/release-monitoring.org's scratch build of acl-2.3.0-1.fc32.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=63616746
dist-git commit: https://src.fedoraproject.org/rpms/acl/c/3b266dc3
FEDORA-2021-15b0781993 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-15b0781993
FEDORA-2021-15b0781993 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-15b0781993` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-15b0781993 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The upgrade of fc34 trigger a lot from missing lilbacl.1.so errors by postinstall scripts for grub2/kernel Upgraded: libacl-2.3.0-1.fc34.x86_64 There was no kernel files for version -5.11.6-300.fc34.x86_64 in /boot and grub is TBD: cp: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory warning: %posttrans(grub2-common-1:2.04-39.fc34.noarch) scriptlet failed, exit status 127 sed: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory ... head: write error: Broken pipe sed: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory head: write error: Broken pipe cp: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory dracut: dracut: creation of /boot/initramfs-5.11.6-300.fc34.x86_64.img failed warning: %posttrans(kernel-core-5.11.6-300.fc34.x86_64) scriptlet failed, exit status 1 Workaround was to reinstall grub2/kernel before reboot: dnf reinstall kernel-*-*5.11.6-300.fc34 kernel-*5.11.6-300.fc34 grub2-*
Honestly, I have no idea what happened on your system. I am not able to reproduce it but will revoke the f34 update to stay on the safe side. Could you please check what happened with libacl.so.1 ? Please paste the output of the following commands: # ldd /usr/bin/cp # ls -l /usr/lib64/libacl.so* # stat /usr/lib64/libacl.so.1 $(realpath /usr/lib64/libacl.so.1) # rpm -V libacl
This PC have been system-upgrade from FC33 10 day ago and the last upgrade before was 6 days ago. ldd /usr/bin/cp linux-vdso.so.1 (0x00007ffc6c7c7000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f87fbac1000) libacl.so.1 => /lib64/libacl.so.1 (0x00007f87fbab6000) libattr.so.1 => /lib64/libattr.so.1 (0x00007f87fbaae000) libc.so.6 => /lib64/libc.so.6 (0x00007f87fb8df000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f87fb848000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f87fb841000) /lib64/ld-linux-x86-64.so.2 (0x00007f87fbb29000) ls -l /usr/lib64/libacl.so* lrwxrwxrwx. 1 root root 17 Mar 13 11:45 /usr/lib64/libacl.so.1 -> libacl.so.1.1.230 -rwxr-xr-x. 1 root root 41208 Mar 12 09:32 /usr/lib64/libacl.so.1.1.230 stat /usr/lib64/libacl.so.1 $(realpath /usr/lib64/libacl.so.1) File: /usr/lib64/libacl.so.1 -> libacl.so.1.1.230 Size: 17 Blocks: 8 IO Block: 4096 symbolic link Device: 23h/35d Inode: 1660415 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Context: unconfined_u:object_r:lib_t:s0 Access: 2021-03-13 11:45:26.083672539 +0100 Modify: 2021-03-13 11:45:26.083672539 +0100 Change: 2021-03-13 11:45:26.083672539 +0100 Birth: 2021-03-13 11:45:26.083672539 +0100 File: /usr/lib64/libacl.so.1.1.230 Size: 41208 Blocks: 88 IO Block: 4096 regular file Device: 23h/35d Inode: 1618674 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:lib_t:s0 Access: 2021-03-12 09:32:45.000000000 +0100 Modify: 2021-03-12 09:32:45.000000000 +0100 Change: 2021-03-13 11:42:52.932981512 +0100 Birth: 2021-03-13 11:42:52.931981522 +0100 rpm -V libacl #no issue: rpm -V libacl --verbose ......... a /usr/lib/.build-id ......... a /usr/lib/.build-id/70 ......... a /usr/lib/.build-id/70/94938cb34f623676283e98762b40867adba416 ......... /usr/lib64/libacl.so.1 ......... /usr/lib64/libacl.so.1.1.230 The upgrade was done with: dnf --verbose --allowerasing --obsoletes distro-sync --refresh --skip-broken. Can it be the creation of the link to libacl.so.1.1.230 that is delayed 2021-03-13T11:42:52+0100 SUBDEBUG Upgrade: libibverbs-34.0-2.fc34.x86_64 2021-03-13T11:42:52+0100 SUBDEBUG Upgrade: libattr-2.5.0-1.fc34.x86_64 2021-03-13T11:42:52+0100 SUBDEBUG Upgrade: libacl-2.3.0-1.fc34.x86_64 2021-03-13T11:42:52+0100 SUBDEBUG Upgrade: acl-2.3.0-1.fc34.x86_64 2021-03-13T11:42:52+0100 SUBDEBUG Upgrade: librdmacm-34.0-2.fc34.x86_64 2021-03-13T11:42:53+0100 SUBDEBUG Upgrade: librados2-2:16.1.0-0.5.snapshot.fc34.x86_64 2021-03-13T11:44:51+0100 SUBDEBUG Upgraded: mariadb-common-3:10.5.8-8.fc34.x86_64 2021-03-13T11:44:51+0100 SUBDEBUG Upgraded: libacl-2.2.53-10.fc34.x86_64 2021-03-13T11:44:51+0100 SUBDEBUG Upgraded: perl-NDBM_File-1.15-472.fc34.x86_64 2021-03-13T11:44:51+0100 SUBDEBUG Upgraded: perl-libs-4:5.32.1-472.fc34.x86_64 2021-03-13T11:44:54+0100 SUBDEBUG Upgraded: btrfs-progs-5.10-2.fc34.x86_64 2021-03-13T11:44:54+0100 INFO cp: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory warning: %posttrans(grub2-common-1:2.04-39.fc34.noarch) scriptlet failed, exit status 127 2021-03-13T11:44:54+0100 ERROR Error in POSTTRANS scriptlet in rpm package grub2-common 2021-03-13T11:44:55+0100 INFO systemctl: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory I have 2 other PC with FC34 i can give it a try and one FC33 that i would like to give system-upgrade.
Can it be the creation of the link to libacl.so.1.1.230 that is delayed? This link is create after the error: lrwxrwxrwx. 1 root root 17 Mar 13 11:45 /usr/lib64/libacl.so.1 -> libacl.so.1.1.230 Access: 2021-03-13 11:45:26.083672539 +0100 2021-03-13T11:44:54+0100 INFO cp: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory warning: %posttrans(grub2-common-1:2.04-39.fc34.noarch) scriptlet failed, exit status 127
This link is create 1s after the last error in dnf.rpm.log this is also the last entry: dracut: dracut: creation of /boot/initramfs-5.11.6-300.fc34.x86_64.img failed warning: %posttrans(kernel-core-5.11.6-300.fc34.x86_64) scriptlet failed, exit status 1 2021-03-13T11:45:25+0100 ERROR Error in POSTTRANS scriptlet in rpm package kernel-core but still in dnf transaction dnf.log: 2021-03-13T11:45:37+0100 DDEBUG RPM transaction over. 2021-03-13T11:45:43+0100 DDEBUG timer: verify transaction: 5492 ms
The resulting state seems correct to me. Both libacl.so.1 and libacl.so.1.1.230 are installed by a single RPM package. I can see with strace that the files are installed in a suboptimal order (the symlink first) but unless something else tries to load libacl.so.1 in the critical window during installation of a single RPM package, everything should just work. I know that `rpm` itself links against libacl but if the updates runs sequentially, this should also be fine. In any case, it is unclear what libacl could do better. I will clone this bug for dnf.
(In reply to Lars S. Jensen from comment #8) > I have 2 other PC with FC34 i can give it a try and one FC33 that i would > like to give system-upgrade. Please let me know how the other updates went. Unless you encounter the same problem again, I will conclude that it was just an unfortunate coincidence and push the f34 update back to testing. Thanks in advance!
This in not a bug in libacl because libattr have the same issue: this link is update after the rpm was done: ls -l /usr/lib64/libattr.so* lrwxrwxrwx. 1 root root 18 Mar 13 11:45 /usr/lib64/libattr.so.1 -> libattr.so.1.1.250 -rwxr-xr-x. 1 root root 28656 Mar 12 09:29 /usr/lib64/libattr.so.1.1.250 stat /usr/lib64/libattr.so.1 $(realpath /usr/lib64/libattr.so.1) File: /usr/lib64/libattr.so.1 -> libattr.so.1.1.250 Size: 18 Blocks: 8 IO Block: 4096 symbolic link Device: 23h/35d Inode: 1660416 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Context: unconfined_u:object_r:lib_t:s0 Access: 2021-03-13 11:45:26.083672539 +0100 Modify: 2021-03-13 11:45:26.083672539 +0100 Change: 2021-03-13 11:45:26.083672539 +0100 Birth: 2021-03-13 11:45:26.083672539 +0100 File: /usr/lib64/libattr.so.1.1.250 Size: 28656 Blocks: 56 IO Block: 4096 regular file Device: 23h/35d Inode: 1618671 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:lib_t:s0 Access: 2021-03-12 09:29:55.000000000 +0100 Modify: 2021-03-12 09:29:55.000000000 +0100 Change: 2021-03-13 11:42:52.905981774 +0100 Birth: 2021-03-13 11:42:52.904981784 +0100
I have done the upgrade on PC that was last upgrade yesterday and that is OK. So is a bad combination of rpm version. I will do a system-upgrade on the FC33 machine to check if it is issue.
(In reply to Lars S. Jensen from comment #13) > This in not a bug in libacl because libattr have the same issue: libacl and libattr are both from the same update update, which has been temporarily unpushed: https://bodhi.fedoraproject.org/updates/FEDORA-2021-15b0781993
System-upgrade on the FC33 machine to FC34 is OK. So is a bad combination of fc34 rpm versions that trigger the issue.
FEDORA-2021-97d1d801e4 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-97d1d801e4
FEDORA-2021-97d1d801e4 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-97d1d801e4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-97d1d801e4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-97d1d801e4 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.