Description of problem: I needed to install a package onto an arm64 image, from a amd64 host. To verify the installation, I executed 'rpm --root=… -V …', and was surprised that UG discrepancy was reported for all files. It turns out that rpmverify reports that for any package: $ rpm --root /tmp/root -V bash error: Failed to dlopen /usr/lib64/rpm-plugins/selinux.so /usr/lib64/rpm-plugins/selinux.so: cannot open shared object file: No such file or directory error: Failed to dlopen /usr/lib64/rpm-plugins/systemd_inhibit.so /usr/lib64/rpm-plugins/systemd_inhibit.so: cannot open shared object file: No such file or directory .....UG.. c /etc/skel/.bash_logout .....UG.. c /etc/skel/.bash_profile .....UG.. c /etc/skel/.bashrc .....UG.. /usr/bin/bashbug-64 .....UG.. /usr/bin/bg .....UG.. /usr/bin/cd .....UG.. /usr/bin/command .....UG.. /usr/bin/fc .....UG.. /usr/bin/fg … But there is no problem with the ownership: $ stat /tmp/root/usr/bin/fg File: /tmp/root/usr/bin/fg Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) … Hmm, the same result occurs for the native architecture: $ rpm -V --root=/var/lib/machines/rawhide bash .....UG.. c /etc/skel/.bash_logout .....UG.. c /etc/skel/.bash_profile .....UG.. c /etc/skel/.bashrc .....UG.. /usr/bin/bashbug-64 $ ls -l /var/lib/machines/rawhide/usr/bin/bashbug-64 -rwxr-xr-x 1 root root 7063 Nov 5 12:30 /var/lib/machines/rawhide/usr/bin/bashbug-64 Version-Release number of selected component (if applicable): rpm-4.17.0-1.fc35.x86_64 How reproducible: Seems deterministic. Steps to Reproduce: 1. rpm -V --root=/path/to/image bash Actual results: UG mismatch reported Expected results: No output
Possibly same as/related to https://github.com/rpm-software-management/rpm/issues/1789
Got any convenient pointer to image(s) that I could use for testing? I'm not able to reproduce with local chroot install of the same arch...
$ sudo dnf '--disablerepo=*' --enablerepo=fedora --enablerepo=updates --releasever=35 --installroot=/var/tmp/f35 --setopt install_weak_deps=False install bash rpm -y $ rpm -V --root=/var/tmp/f35 bash .....UG.. c /etc/skel/.bash_logout .....UG.. c /etc/skel/.bash_profile .....UG.. c /etc/skel/.bashrc .....UG.. /usr/bin/alias I don't think https://github.com/rpm-software-management/rpm/issues/1789 is related — here the image is all installed by the time 'rpm -V' is executed, so all users are defined. $ sudo chroot /var/tmp/f35 rpm -V bash (nothing, i.e. all good) $ sudo chroot /var/tmp/f35 id 0 uid=0(root) gid=0(root) groups=0(root) So it's something about crossing --root being used.
Oh... now I see it - you're running verify as a regular user, which doesn't generally work. In older versions, you'd just get "error: Unable to change root directory: Operation not permitted" instead, which is annoying but the current behavior is misleading which tends to be worse.
(hit enter too soon...) This happens because rpm now uses user namespace for performing the chroot if necessary (ie running as a regular user) but that messes up the user/group situation :-/
Oh, and for full disclosure, rpm -V with --root is not reliable in any case, even as root, never was. It uses the user info from the "host" which is sometimes what you want (think anaconda) and at others it's just plain wrong.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. 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 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
No change with rpm-4.18.0-1.fc37.x86_64. I really think rpm should either implement the operation correctly or refuse it altogether. Partial operation just leads to user frustration.
This is now fixed upstream and will land in Fedora with rpm 4.19 beta.