Bug 1061486
| Summary: | [abrt] yum-utils-1.1.31-15.fc19: config.py:1187:_getsysver:YumBaseError: Error: rpmdb open failed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Sergio Pascual <sergio.pasra> | ||||
| Component: | mock | Assignee: | Clark Williams <williams> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 20 | CC: | admiller, dcharlespyle, lars, mebrown, packaging-team-maint, pmatilai, tim.lauridsen, williams, zpavlas | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | abrt_hash:86506b4195ebca86a90a629882e1cf395202c891 | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | 982043 | Environment: | |||||
| Last Closed: | 2014-03-03 00:20:50 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: | 982043 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Sergio Pascual
2014-02-04 22:33:16 UTC
I'm having the same problem in Fedora 20 with yum-utils-1.1.31-20.fc20.noarch Adding --disable-plugin=package_state is a valid workaround I have tried to downgrade yum-utils to 1.1.31-19 and 1.1.31-18 but the problem is still there For some reason, the contents of /var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm are like this: 923499 -rw-------. 1 root mock 8192 Feb 5 00:03 Conflictname 923504 -rw-------. 1 root mock 192512 Feb 5 00:03 Dirnames 923509 -rw-------. 1 root mock 8192 Feb 5 00:03 Group 923519 -rw-------. 1 root mock 12288 Feb 5 00:03 Installtid 923518 -rw-------. 1 root mock 16384 Feb 5 00:03 Name 923525 -rw-------. 1 root mock 8192 Feb 5 00:03 Obsoletename 923487 -rw-------. 1 root mock 15974400 Feb 5 00:03 Packages 923498 -rw-------. 1 root mock 98304 Feb 5 00:03 Providename 923505 -rw-------. 1 root mock 77824 Feb 5 00:03 Requirename 923522 -rw-------. 1 root mock 28672 Feb 5 00:03 Sha1header 923510 -rw-------. 1 root mock 16384 Feb 5 00:03 Sigmd5 923523 -rw-------. 1 root mock 8192 Feb 5 00:03 Triggername and in my /var/lib/rpm 7 -rw-r--r--. 1 root root 19615744 feb 4 23:31 Basenames 786451 -rw-r--r--. 1 root root 16384 feb 4 10:37 Conflictname 797724 -rw-------. 1 root root 442368 feb 4 23:31 __db.001 798459 -rw-------. 1 root root 106496 feb 4 23:31 __db.002 798645 -rw-------. 1 root root 1318912 feb 4 23:31 __db.003 789123 -rw-r--r--. 1 root root 0 jun 17 2013 .dbenv.lock 786454 -rw-r--r--. 1 root root 7217152 feb 4 23:31 Dirnames 786448 -rw-r--r--. 1 root root 81920 feb 4 23:31 Group 786455 -rw-r--r--. 1 root root 49152 feb 4 23:31 Installtid 786446 -rw-r--r--. 1 root root 163840 feb 4 23:31 Name 786452 -rw-r--r--. 1 root root 102400 feb 4 23:21 Obsoletename 786445 -rw-r--r--. 1 root root 405737472 feb 4 23:31 Packages 786450 -rw-r--r--. 1 root root 2813952 feb 4 23:31 Providename 786449 -rw-r--r--. 1 root root 1523712 feb 4 23:31 Requirename 786465 -rw-r--r--. 1 root root 0 mar 12 2013 .rpm.lock 786457 -rw-r--r--. 1 root root 495616 feb 4 23:31 Sha1header 786456 -rw-r--r--. 1 root root 286720 feb 4 23:31 Sigmd5 786453 -rw-r--r--. 1 root root 16384 feb 1 23:37 Triggername This explains why repoquery can't read the rpm database inside the chroot, (group mock but no read permission in files) Testing in a different f20 machine, I'm getting the permissions right, with read permission for the mock user. reinstalling mock and running it as a different user doesn't help Considering its rawhide... it could might be just be a "bad day at rawhide" when the root + its cache was created. Mock reinstall wont fix that but this should give you a truly fresh starting point: 'mock --scrub=all -r fedora-rawhide-x86_64' Running as a different user wont help by default, you'd need to use --uniqueext switch and I dunno if even that'd help in case the root cache happens to be borken. F20 isn't rawhide and neither is F19. These problems are occurring on both and the --scrub-all option doesn't work as it is supposed to work. I've been through that several times with no change in behavior when trying to run mock while building packages. It is the same with a fresh, bare metal install. Tried that, too. (In reply to Panu Matilainen from comment #4) > Considering its rawhide... it could might be just be a "bad day at rawhide" > when the root + its cache was created. Mock reinstall wont fix that but this > should give you a truly fresh starting point: 'mock --scrub=all -r > fedora-rawhide-x86_64' > I'm running F20 and this does not fix my problem. All the buildroots are affected identically. > Running as a different user wont help by default, you'd need to use > --uniqueext switch and I dunno if even that'd help in case the root cache > happens to be borken. The problem is that mock writes the rpm database in the buildroot with permission 600 and owner root.mock When later during the build, mock tries to read the rpm database, it fails. The part of mock that reads the rpm database is a plugin called package_state It dumps the content of the database into result/installed_pkgs That's way running mock with --disable-plugin=package_state is a workaround, as it was mentioned on the comments of the cloned bug. I have checked in other machine with F20 and it works right. The files in the rpm database have permissions 644, owner root.mock So the question is why is mock/yum creating the database with wrong permissions. Created attachment 859824 [details]
Verbose output of mock
This is the output of
$ LANG=C mock -v -r fedora-rawhide-x86_64 --init
after running
$ mock --scrub=all -r fedora-rawhide-x86_64
Hmmm, mock doesn't really do anything but create the /var/lib/rpm directory in the chroot and then let's rpm populate it. Just for verification's sake I initialized an f20 chroot on my f19 laptop and had no issues. I'm doing the same on a lab system that was provisioned for f20 to see what happens (I expect to see a bunch of 600 mode files like what you guys are seeing). My suspicion is that something has changed in the rpm* packages.
I'll go see if we can elevate privs temporarily in the package_state plugin when querying the rpmdb, since you're probably supposed to be root anyway when hitting that database.
While I was writing this up, my init finished and this is what I have:
$ ls -ls /var/lib/mock/fedora-20-x86_64/root/var/lib/rpm
total 15660
788 -rw-r--r--. 1 root mock 806912 Feb 6 15:10 Basenames
8 -rw-r--r--. 1 root mock 8192 Feb 6 15:10 Conflictname
172 -rw-r--r--. 1 root mock 176128 Feb 6 15:10 Dirnames
8 -rw-r--r--. 1 root mock 8192 Feb 6 15:10 Group
12 -rw-r--r--. 1 root mock 12288 Feb 6 15:10 Installtid
16 -rw-r--r--. 1 root mock 16384 Feb 6 15:10 Name
8 -rw-r--r--. 1 root mock 8192 Feb 6 15:10 Obsoletename
14440 -rw-r--r--. 1 root mock 14786560 Feb 6 15:10 Packages
92 -rw-r--r--. 1 root mock 94208 Feb 6 15:10 Providename
68 -rw-r--r--. 1 root mock 69632 Feb 6 15:10 Requirename
24 -rw-r--r--. 1 root mock 24576 Feb 6 15:10 Sha1header
16 -rw-r--r--. 1 root mock 16384 Feb 6 15:10 Sigmd5
8 -rw-r--r--. 1 root mock 8192 Feb 6 15:10 Triggername
Sooo, I'm not sure what's going on here.
(In reply to Clark Williams from comment #8) > Hmmm, mock doesn't really do anything but create the /var/lib/rpm directory > in the chroot and then let's rpm populate it. Just for verification's sake I > initialized an f20 chroot on my f19 laptop and had no issues. I'm doing the > same on a lab system that was provisioned for f20 to see what happens (I > expect to see a bunch of 600 mode files like what you guys are seeing). My > suspicion is that something has changed in the rpm* packages. Well, I couldn't reproduce this problem in other machines with Fedora 20. So it only affects one machine (my main work machine, btw) > > Sooo, I'm not sure what's going on here. Clearly there is something in my machine that is affecting the effective permissions under mock is run. To see what I have modified from a stock install, I run rpm -qVa to see the configuration files I have modified. .M....G.. /var/log/gdm .M....... /run/svnserve falta /var/run/pluto S.5....T. c /etc/bacula/bacula-fd.conf .M....G.. /var/log/journal falta /var/run/wpa_supplicant .M....... /var/lib/nfs/rpc_pipefs S.5....T. c /etc/aliases S.5....T. c /etc/hosts.deny S.5....T. c /etc/printcap S.5....T. c /etc/services S.5....T. /usr/lib64/vlc/plugins/plugins.dat S.5....T. c /etc/mail/sendmail.cf S.5....T. c /etc/mail/sendmail.mc S.5....T. /usr/lib64/R/etc/Makeconf S.5....T. /usr/lib64/R/etc/ldpaths S.5....T. c /etc/selinux/targeted/contexts/files/file_contexts.local ....L.... c /etc/pam.d/fingerprint-auth ....L.... c /etc/pam.d/password-auth ....L.... c /etc/pam.d/postlogin ....L.... c /etc/pam.d/smartcard-auth falta /var/run/gluster .......T. c /etc/yum.repos.d/fedora-updates-testing.repo .......T. c /etc/yum.repos.d/fedora-updates.repo S.5....T. c /etc/my.cnf.d/server.cnf S.5....T. c /etc/qemu/target-x86_64.conf S.5....T. c /etc/ansible/hosts SM5....T. c /etc/snmp/snmpd.conf S.5....T. c /etc/plymouth/plymouthd.conf Can it be related with pam? I see mock has a pam file, although I haven't touched it Now I've updated to mock-1.1.36-1.fc20.noarch, I'm getting more errors
$ mock -r fedora-rawhide-x86_64 --scrube=all
$ mock -r fedora-rawhide-x86_64 --init
INFO: mock.py version 1.1.36 starting...
(skip, all this is normal)
INFO: enabled ccache
Start: device setup
Finish: device setup
Start: yum update
Start: Outputting list of available packages
WARNING: Forcibly unmounting '/var/lib/mock/fedora-rawhide-x86_64/root/proc/filesystems' from chroot.
WARNING: Forcibly unmounting '/var/lib/mock/fedora-rawhide-x86_64/root/tmp/ccache' from chroot.
WARNING: Forcibly unmounting '/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/yum' from chroot.
WARNING: Forcibly unmounting '/var/lib/mock/fedora-rawhide-x86_64/root/dev/pts' from chroot.
WARNING: Forcibly unmounting '/var/lib/mock/fedora-rawhide-x86_64/root/dev/shm' from chroot.
WARNING: Forcibly unmounting '/var/lib/mock/fedora-rawhide-x86_64/root/sys' from chroot.
WARNING: Forcibly unmounting '/var/lib/mock/fedora-rawhide-x86_64/root/proc' from chroot.
ERROR: Command failed. See logs for output.
# /usr/bin/repoquery --installroot=/var/lib/mock/fedora-rawhide-x86_64/root/ -c /var/lib/mock/fedora-rawhide-x86_64/root//etc/yum.conf -a --qf '%{nevra} %{buildtime} %{size} %{pkgid} %{repoid}' > /var/lib/mock/fedora-rawhide-x86_64/result/available_pkgs
WARNING: unable to delete selinux filesystems (/tmp/mock-selinux-plugin.YfKQcG): [Errno 1] Operación no permitida: '/tmp/mock-selinux-plugin.YfKQcG'
All the mentioned filesystems remain mounted after mock ends
So, whatever makes mock to write var/lib/rpm with wrong permissions is affecting also the unmounting of those filesystems
I have given up and reinstalled my system from DVD. Now mock works. I hope never find this problem again. |