Bug 1937956
| Summary: | acl-2.3.0 is available | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Upstream Release Monitoring <upstream-release-monitoring> | ||||
| Component: | acl | Assignee: | Kamil Dudka <kdudka> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 34 | CC: | jmoskovc, kdudka, lars.s.jensen, steved, svashisht | ||||
| Target Milestone: | --- | Keywords: | FutureFeature, Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | acl-2.3.0-1.fc35 acl-2.3.1-1.fc34 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1938459 (view as bug list) | Environment: | |||||
| Last Closed: | 2021-04-01 00:51:31 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1938459 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Upstream Release Monitoring
2021-03-11 19:22:47 UTC
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-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. 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. |