Bug 503195 - double prefixing of installroot
Summary: double prefixing of installroot
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 10
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-29 15:08 UTC by Charles Lopes
Modified: 2014-01-21 23:09 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-09-03 15:32:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Charles Lopes 2009-05-29 15:08:50 UTC
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 15:14:03 UTC
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 15:23:27 UTC
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 16:37:23 UTC
Can you reproduce this without using mock? As I can't see how this can happen.

Comment 4 seth vidal 2009-06-04 18:47:41 UTC
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 21:32:27 UTC
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 07:09:02 UTC
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 15:08:05 UTC
so Transaction Start (transStart) when the callback is called - is that inside or outside the chroot?

Comment 8 Panu Matilainen 2009-08-13 12:56:32 UTC
All of the RPMCALLBACK_TRANS_* callbacks occur inside chroot (when one is used).

Comment 9 seth vidal 2009-09-01 17:01:54 UTC
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 19:05:32 UTC
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 15:32:32 UTC
this patch is in 3.2.23-16 in rawhide now.

Comment 12 seth vidal 2009-09-14 20:28:18 UTC
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 20:41:21 UTC
 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.