Bug 503195 - double prefixing of installroot
double prefixing of installroot
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-29 11:08 EDT by Charles Lopes
Modified: 2014-01-21 18:09 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-03 11:32:32 EDT
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 Charles Lopes 2009-05-29 11:08:50 EDT
yum prefixes the path passed by installroot twice for the transaction-all file. When using mock, I end up with such files in the chroot:
/var/lib/mock/fedora-10-i386/root/var/lib/yum/transaction-all.2009-05-29.11:38.31

Both yum-3.2.21-2.fc10 and yum-3.2.22-4.fc11 exhibit the same behaviour.
Comment 1 seth vidal 2009-05-29 11:14:03 EDT
where is the double prefix?

/var/lib/mock/fedora-10-i386/root is the mock dir
/var/lib/yum/transaction-all.2009-05-29.11:38.31 is the yum persistent info dir
Comment 2 Charles Lopes 2009-05-29 11:23:27 EDT
Oops. I copied the path from the chroot. Here's the full path:

/var/lib/mock/fedora-11-i386/root/var/lib/mock/fedora-11-i386/root/var/lib/yum/transaction-all.2009-05-29.11:38.31
Comment 3 James Antill 2009-06-04 12:37:23 EDT
Can you reproduce this without using mock? As I can't see how this can happen.
Comment 4 seth vidal 2009-06-04 14:47:41 EDT
I'm pretty sure this is related to the outer-yum, inner config file + yum.installroot being set on the command line. 

it'll be a little while b/c tracing it out will be time consuming.
Comment 5 seth vidal 2009-07-15 17:32:27 EDT
So it seems like if you install into a chroot and you have a transaction callback writing out to a file you open FROM the transaction callback that the file is also put inside the chroot. My questions are:

 is this intended? ie: once you start the transaction are all additional process actions INSIDE the chroot?


if it is intended, that's fine, I just need to know it. It also makes logging from inside the rpm transaction a bit tricky but again, I just need to know this is the case.
Comment 6 Panu Matilainen 2009-07-16 03:09:02 EDT
Rpm flip-flops in and out of chroot during the transaction run, roughly:
- "preparing..." stage runs inside the chroot
- the actual install/erase stage goes in and out of chroot for every package (package files are opened outside chroot, laying down files and running scripts runs inside it)
Comment 7 seth vidal 2009-07-17 11:08:05 EDT
so Transaction Start (transStart) when the callback is called - is that inside or outside the chroot?
Comment 8 Panu Matilainen 2009-08-13 08:56:32 EDT
All of the RPMCALLBACK_TRANS_* callbacks occur inside chroot (when one is used).
Comment 9 seth vidal 2009-09-01 13:01:54 EDT
Here's a patch:

http://skvidal.fedorapeople.org/misc/double-prefix-bug.patch

I've tested it - could someone else, too?
Comment 10 seth vidal 2009-09-01 15:05:32 EDT
patch has been tested offline and will be committed upstream as soon as I get an ack from another dev.
Comment 11 seth vidal 2009-09-03 11:32:32 EDT
this patch is in 3.2.23-16 in rawhide now.
Comment 12 seth vidal 2009-09-14 16:28:18 EDT
new patch ontop of the old patch

http://lists.baseurl.org/pipermail/yum-devel/2009-September/005855.html

OR

just take any trailing '/' off of the installroot path.
Comment 13 seth vidal 2009-09-14 16:41:21 EDT
 So - this bug confuses me - essentially when we opened a file with a filename of:

/var/lib/yum/transaction-all and we were using an installroot then the file would open up the file inside the installroot at the path. Since rpm had already chroot()ed that makes sense

But if the filename was: var/lib/yum/transaction-all and we were using an installroot then the file would be opened outside of the chroot. despite that rpm had already chroot()ed.

Is there something obvious I'm missing on how chroot() functions?

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