Red Hat Bugzilla – Bug 503195
double prefixing of installroot
Last modified: 2014-01-21 18:09:46 EST
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.
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
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
Can you reproduce this without using mock? As I can't see how this can happen.
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.
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.
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)
so Transaction Start (transStart) when the callback is called - is that inside or outside the chroot?
All of the RPMCALLBACK_TRANS_* callbacks occur inside chroot (when one is used).
Here's a patch: http://skvidal.fedorapeople.org/misc/double-prefix-bug.patch I've tested it - could someone else, too?
patch has been tested offline and will be committed upstream as soon as I get an ack from another dev.
this patch is in 3.2.23-16 in rawhide now.
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.
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?