Hi, This was originally filed as a bug against Yum, https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=665. Mach and Mock both fail bootstrapping a root when /var/lib/rpm does not exist on the host. This seems to be due to the %_rpmlock_path macro which defaults to %{_dbpath}/__db.000. When /var/lib/rpm does not exist, Yum fails locking over this file, but Yum should not try using this file when passed an installroot, it should try using $installroot/var/lib/rpm (which happens to exist and would be usable). Yum's upstream commented that this doesn't seem to be a Yum bug, and that I should preferably file a bug against Mock. See Yum bug #665 for details. Some relevants logs for this bug: Success run: bee% mock -r fedora-devel-i386-core init init clean prep This may take a while ending done Finished initializing root Failing run: bee% mock -r fedora-devel-i386-core init init clean prep This may take a while Could not find useradd in chroot, maybe the install failed? ending done I'll attach the resulting root.log which fails during: Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root install buildsys-build [...] Transaction Summary ============================================================================= Install 98 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 100 M warning: unzip-5.52-2.2.1: Header V3 DSA signature: NOKEY, key ID 897da07a warning: rpmdevtools-5.3-1.fc6: Header V3 DSA signature: NOKEY, key ID 1ac70ce6 error: can't create transaction lock on /var/lib/rpm/__db.000 Bye,
Created attachment 141050 [details] Log of a failed mock (0.6.8) run with a fedora devel target
Loïc, Would you try the attached patch? I've smoke-tested it on a fedora-development system and will try it on a scratch system (one where I don't care if I screw up the RPM database) on Monday. It at least doesn't break mock on fedora, but I can't test it on a system that doesn't have /var/lib/rpm/* tonight. Clark
Created attachment 143831 [details] Patch to add _rpmlock_path to internal mock macros Test patch to check behavior in absence of /var/lib/rpm
Created attachment 143847 [details] Log of a failed mock (0.6.8) run with a fedora devel target, with rpmmacros patch applied
Fails in the same way. The proposed patch seems to define the interesting macro, but I'm not sure how the host's yum is supposed to use the macros. I'm reopening as "FAILS_QA" because this is the closest to "REOPENED" I could find.
Well, I'm clueless. I've sent an email to Seth on fedora-buildsys-list. Maybe we can hash it out there.
What version of rpm is installed on the machine where the failure is being observed? There was a bug in older versions of rpm that caused locking to occur outside the chroot, regardless of the --root argument passed to it.
It seems like this can be solved by an rpm macro specifying where the lock file is to go. That's what fixed it for people on rhel4 4.4 or higher, iirc.
Created attachment 144038 [details] corrected patch to add _rpmlock_path to macros Fixed incorrect use of '%' characters in original patch
Loïc, Sigh. Seems I got a little carried away with the percent signs in my previous patch. What I wanted was to put a line in config['macros'] that looked like this %_rpmlock_path /var/lib/mock/fedora-6-i386-core/root/var/lib/rpm Instead I got this: %_rpmlock_path %/var/lib/mock/fedora-6-i386-core/root/var/lib/rpm Which I'm sure doesn't work. Would you please try the New-and-Improved patch? Clark
@Mike: RPM is 4.4.2 from download.fedora.redhat.com.
Created attachment 144078 [details] 143847: Log of a failed mock (0.6.8) run with a fedora devel target, with fixed rpmmacros patch applied
I'm afraid it still fails (reopening as FAILS_QA).
The version of RPM that is currently in Fedora 8 appears to have fixed this bug. Probably need to upgrade the version of rpm in debian to something similar.
We're at 4.4.2, what version is Fedora 8 at?
looks like 4.4.2.2
any word on whether this is resolved?
This was resolved in two ways: - Debian's rpm used to not have a /var/lib/rpm dir to avoid people running rpm on Debian systems to install .rpms; this was changed with a patch failing installation instead of failing db creation - rpm 4.4.2.2 now properly uses rootdir when expanding the db path: - char * t = rpmExpand(rpmlock_path_default, NULL); + char * t = rpmGenPath(rootdir, rpmlock_path_default, NULL); So yeah, this is fixed; thanks.