From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Red Hat/1.0.1-1.4.3 Description of problem: When run as a regular user, the following command: rpm --root /var/ccm-devel/dev/mbooth/aplaws-build/root --initdb Gives the error: error: can't create transaction lock The last two relevant lines from strace -eopen are: open("/var/lock/rpm/transaction", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied) open("/var/lock/rpm/transaction", O_RDONLY|O_LARGEFILE) = 3 Other rpm commands give the same error. Version-Release number of selected component (if applicable): rpm-4.3.3-7_nonptl How reproducible: Always Steps to Reproduce: 1. Run rpm --root <directory> --initdb as a regular user Actual Results: rpm tries to get a lock on /var/lock/rpm/transaction Expected Results: rpm should try to get a lock on a different file, eg <new root>/var/lock/rpm/transaction Additional info:
All depends on whether the lock scoping is desired to be global (as implemented) or per-chroot. The path has been made configurable, and changed to be per-root in rpm-4.4.1: # # Default path to the file used for transaction fcmtl lock. # # The previous, FHS clompliant, name was /var/lock/run/transaction, # but the transaction lock needs to be per-database, not global, for # some rpmdb operations. # # XXX Note: the file name is chosesn as __db.000 to expedite # support issues, many users are doing "rm -f /var/lib/rpm/__db*" # these days. %_rpmlock_path %{_dbpath}/__db.000
perhaps it needs to be per-database 'If and only' if the EUID can write locks, and simply ignored if it is not possible for the EUID to open the DB +w ? For a non-+w user, a process local copy of the rpmdb would permit simultaneous build processes (for example, in some work I an doing), living somewhere in probably the %_builddir tree seems to be a comprehensive if perhaps overly cautious solution.
The path has been made configurable in rpm-4.4.1, however it still does not work as expected. The path of the lock does not take into account the --root. To fix this issue in lib/rpmlock.c function: rpmlock_new - char * t = rpmExpand(rpmlock_path_default, NULL); + char * t = rpmGenPath(rootdir, rpmlock_path_default, NULL); function: rpmtsAcquireLock - if (!rootDir) + if (!rootDir || rpmtsChrootDone(ts)) (The above changes are made in the MontaVista version of rpm to address this issue.)
Paul, if these changes look good to you I will apply to head. Cheers...james
Just an FYI. These changes are still required for RPM 4.4.2.
Added to rpm cvs, should be in rpm-4.4.4-0.6 when built.
Reopening to get fixed in RHEL4 proper.
Created attachment 123780 [details] rpm-transaction-lock-in-root.patch Example patch for RHEL4. This would use a transaction lock in the root specified.
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
I believe I correctly applied this patch and --initdb still looks in the wrong spot for the transaction lock. $ rpm --root /export/test --initdb error: can't create transaction lock strace snip: open("/var/lock/rpm/transaction", O_RDONLY) = 3 write(2, "error: ", 7error: ) = 7 my patch line from my spec %patch9 -p1 as defined by: Patch9: rpm-transaction-lock-in-root.patch If my patch is suspect and you can provide me with a build "rpm" command binary or binary package, I'll give it a try as well... I must be missing something.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0440.html
Not sure where the problem lies, but I can confirm Jerry's problem (comment #35) with fix/patch as-is doesn't work. Just upgraded a box to centos-4.4, and rpm --root no longer works (which makes my mock builds hosted here fail miserably) $ rpm -q rpm rpm-4.3.3-18_nonptl $ rpm --root /tmp/foo --initdb error: can't create transaction lock on /tmp/foo/var/lock/rpm/transaction
the errata https://rhn.redhat.com/errata/RHBA-2006-0440.html says: Transaction lock issues using RPM with --root and --dbpath have been fixed. Note, to use --dbpath as non root, customers will need to define the %_rpmlock_path macro to a location that can be written to; future versions of RPM use '%{_dbpath}/__db.000'. Appears to work for us, even if cumbersome.
Rex, mock will need to create ROOT/var/lock/rpm or you'd need to mkdir -p /tmp/foo/var/lock/rpm as before it was locking outside the chroot which is incorrect, now it's locking in the chroot and probably that path does not exist. Else defining _rpmlock_path in ~/.rpmmacros to somewhere within %_dbpath which dir structure is created by rpmdb operations.
Thanks Paul, looks like mock needs some patching to ensure creation of ROOT/var/lock/rpm too.