Bug 510469 - rpm -i --root=/chroot', error: can't create transaction lock
rpm -i --root=/chroot', error: can't create transaction lock
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Panu Matilainen
BaseOS QE Security Team
:
Depends On:
Blocks: 500798 769266
  Show dependency treegraph
 
Reported: 2009-07-09 08:12 EDT by Petr Sklenar
Modified: 2012-10-31 05:27 EDT (History)
4 users (show)

See Also:
Fixed In Version: rpm-4.4.2.3-25.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-21 01:45:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Sklenar 2009-07-09 08:12:11 EDT
Description of problem:
'rpm -i --root=/chroot' complains that it needs creation of transaction lock  but rpm -U works well.

Version-Release number of selected component (if applicable):

RHEL54: rpm-4.4.2.3-9.el5.x86_64
and
RHEL53: rpm-4.4.2.3-16.el5.x86_64
maybe even older
upstream is fixed

How reproducible:
always

Steps to Reproduce:
0. # external folder is empty or doesn't exists : /tmp/zip2

1. # rpm -ivh /mnt/redhat/brewroot/packages/zip/2.31/2.el5/`uname -i`/zip-2* --root=/tmp/zip2--nodeps
error: can't create transaction lock on /tmp/zip2/var/lib/rpm/__db.000

2 # rpm -Uvh  /mnt/redhat/brewroot/packages/zip/2.31/2.el5/`uname -i`/zip-2* --root=/tmp/zip2--nodeps
Preparing...                ########################################### [100%]
   1:zip           

Actual results:
rpm -i --root=/external <pkgs> && can't create transaction

Expected results:
rpm -i --root=/external <pkgs>
# should install package

Additional info:
found during errata testing:
https://errata.devel.redhat.com/errata/show/8629#c72
Comment 1 Bruce Adams 2011-06-22 08:08:05 EDT
I have also observed this problem in the context of testing RPMs using a new RPM database. 
E.g.
script to reproduce:

WSDIR=/tmp/foobar
mkdir $WSDIR

mkdir "$WSDIR"/rpmdb
rpmdb --initdb --dbpath "$WSDIR"/rpmdb

cd $WSDIR

# Exercise (install RPM)
# we use --nopost so that we don't run the post install script which runs ldconfig.
rpm --dbpath "$WSDIR"/rpmdb --nopost --root `pwd` --relocate /opt=`pwd`/opt -ivh <something>.rpm --nodeps 

Actual results on stderr

"error: can't create transaction lock on /tmp/foobar/rpmdb/__db.000"

I believe this is the same problem as described here because rpm -U
installs the RPM successfully.

I have found that it is not a problem for all systems or all RPMs.

I have observed it fails on the following setup (for a particular RPM):

brucea@:main/test/systemtest>rpm --version
RPM version 4.4.2
brucea@:main/test/systemtest>lsb_release -a
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 5.2 (Tikanga)
Release: 5.2
Codename: Tikanga

I have observed it works on the following setup (for a particular RPM):

brucea@:depot/emma/main>rpm --version
RPM version 4.4.2.3
brucea@:depot/emma/main>lsb_release -a
LSB Version:    :core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: RedHatEnterpriseClient
Description:    Red Hat Enterprise Linux Client release 5.6 (Tikanga)
Release:        5.6
Codename:       Tikanga

I believe it also works on the following setup (for a different RPM):

[brucea@uktnswg-ams-test01 ~]$ rpm --version
RPM version 4.4.2.3
[brucea@uktnswg-ams-test01 ~]$ lsb_release -a
LSB Version:    :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Release:        5.3
Codename:       Tikanga

I cannot currently confirm whether updating rpm to version 4.4.2.3 on the failing machine is sufficient to solve this problem.
Comment 2 Bruce Adams 2011-06-22 09:24:25 EDT
I have made an odd observation with regard to this.
Given a test script as below the transaction lock either succeeds or fails on the basis of the INSTALLROOT dir chosen.
On the same machine I have one directory where the installation succeeds and all others where it does not. I am at a loss to explain this.

I have also observed that even when it does succeed here the exit status is non-zero.
The man-page for RPM is unusual in not describing the exit status
(or indeed the --fsmdebug & --rpmiodebug options I have seen mention elsewhere)

#!/bin/sh
#
# create RPM db & install AMS RPMs for this test dir
#

INSTALLROOT=`pwd`
RPMDIR=`pwd`/rpms

mkdir $INSTALLROOT
cp -r $RPMDIR $INSTALLROOT/rpms
cd $INSTALLROOT


cd $INSTALLROOT
rm -rf `pwd`/rpmdb

mkdir `pwd`/rpmdb
rpmdb --initdb --dbpath `pwd`/rpmdb

# copy system wide RPM database 
# (otherwise basic things like libc will be missing dependencies)
# cp /var/lib/rpm/* rpmdb/.

rpm --dbpath `pwd`/rpmdb --root `pwd` --force --relocate /=`pwd` -ivh $INSTALLROOT/rpms/*.rpm --nodeps
echo STATUS=$?
Comment 3 Bruce Adams 2011-06-22 09:26:02 EDT
BTW The latter observation was with rpm version 4.4.2.3 so I can confirm that this version does not solve this problem.
Comment 4 Panu Matilainen 2011-08-23 01:14:52 EDT
The difference between -i and -U comes from the fact that with -U, the rpmdb has already been opened (well, created) whereas with -i it's not. With -i, it also depends on whether the package is signed or not (or whether signature checking is disabled) - signature checking also opens (and creates in this case) the rpmdb early, creating the directory where the lock will be placed. The --initdb case is more straightforward: the directory is always missing, causing failure.

devel_ack, the fix is a trivial one-liner patch.
Comment 8 Karel Srot 2011-11-16 03:55:55 EST
I can reproduce the bug with the rpm -i case but I can't reproduce the rpmdb --initdb one. 

[root@nec-em13 xxx]# rpm -q rpm
rpm-4.4.2.3-22.el5
[root@nec-em13 xxx]# mkdir /tmp/rpmdb
[root@nec-em13 xxx]# rpmdb --initdb --dbpath /tmp/rpmdb
[root@nec-em13 xxx]# ls /tmp/rpmdb/
__db.000  __db.001  __db.002  __db.003  Packages

Am I doing something wrong? Or is it possible that the --initdb case had been already fixed?
Comment 9 Panu Matilainen 2011-11-16 06:14:32 EST
Leave out the preceding mkdir, that's what "fixes" the issue. Ie just

rpmdb --initdb --dbpath /no/such/directory
Comment 11 errata-xmlrpc 2012-02-21 01:45:32 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0283.html

Note You need to log in before you can comment on or make changes to this bug.