Bug 215321

Summary: Fails bootstrapping when _rpmlock_path's dir doesn't exist
Product: [Retired] Fedora Hosted Projects Reporter: Loïc Minier <lool>
Component: mockAssignee: Clark Williams <williams>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dcantrell, extras-qa, mikeb
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=665
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-06 04:32:17 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:
Attachments:
Description Flags
Log of a failed mock (0.6.8) run with a fedora devel target
none
Patch to add _rpmlock_path to internal mock macros
none
Log of a failed mock (0.6.8) run with a fedora devel target, with rpmmacros patch applied
none
corrected patch to add _rpmlock_path to macros
none
143847: Log of a failed mock (0.6.8) run with a fedora devel target, with fixed rpmmacros patch applied none

Description Loïc Minier 2006-11-13 14:46:50 UTC 
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,
Comment 1 Loïc Minier 2006-11-13 14:48:01 UTC 
Created attachment 141050 [details]
Log of a failed mock (0.6.8) run with a fedora devel target
Comment 2 Clark Williams 2006-12-15 23:04:36 UTC 
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
Comment 3 Clark Williams 2006-12-15 23:06:52 UTC 
Created attachment 143831 [details]
Patch to add _rpmlock_path to internal mock macros

Test patch to check behavior in absence of /var/lib/rpm
Comment 4 Loïc Minier 2006-12-16 11:02:46 UTC 
Created attachment 143847 [details]
Log of a failed mock (0.6.8) run with a fedora devel target, with rpmmacros patch applied
Comment 5 Loïc Minier 2006-12-16 11:12:48 UTC 
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.
Comment 6 Clark Williams 2006-12-19 17:04:23 UTC 
Well, I'm clueless. I've sent an email to Seth on fedora-buildsys-list. Maybe we
can hash it out there.
Comment 7 Mike Bonnet 2006-12-19 17:24:30 UTC 
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.
Comment 8 Seth Vidal 2006-12-19 17:29:35 UTC 
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.
Comment 9 Clark Williams 2006-12-19 19:59:12 UTC 
Created attachment 144038 [details]
corrected patch to add _rpmlock_path to macros

Fixed incorrect use of '%' characters in original patch
Comment 10 Clark Williams 2006-12-19 20:18:43 UTC 
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
Comment 11 Loïc Minier 2006-12-20 08:01:40 UTC 
@Mike: RPM is 4.4.2 from download.fedora.redhat.com.
Comment 12 Loïc Minier 2006-12-20 09:00:38 UTC 
Created attachment 144078 [details]
 143847: Log of a failed mock (0.6.8) run with a fedora devel target, with fixed rpmmacros patch applied
Comment 13 Loïc Minier 2006-12-20 09:01:27 UTC 
I'm afraid it still fails (reopening as FAILS_QA).
Comment 14 Michael E Brown 2007-11-15 20:02:18 UTC 
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.
Comment 15 Loïc Minier 2008-02-12 19:01:59 UTC 
We're at 4.4.2, what version is Fedora 8 at?
Comment 16 Clark Williams 2008-02-29 22:07:44 UTC 
looks like 4.4.2.2
Comment 17 Clark Williams 2008-12-18 23:23:04 UTC 
any word on whether this is resolved?
Comment 18 Loïc Minier 2008-12-19 04:42:55 UTC 
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.