I'm emerging an entire gentoo system into a new root, and am running a command similar to: ROOT=/tmp/newroot emerge open-vm-tools But the ebuild is putting these files in /tmp/newroot/tmp/newroot/ /tmp/newroot/tmp/newroot/sbin/mount.vmhgfs /tmp/newroot/tmp/newroot/etc/vmware-tools/tools.conf /tmp/newroot/tmp/newroot/etc/vmware-tools/*-vm-default I'm no ebuild guru, but from looking at other ebuilds for reference, it looks like the *into functions implicitly respect $ROOT, which makes "into $ROOT" cause the behavior I am seeing. "into /" should be sufficient (and still respect $ROOT at the same time). Reproducible: Always Steps to Reproduce: 1. ROOT=/tmp/newroot emerge --nodeps --oneshot open-vm-tools Actual Results: Files are in /tmp/newroot/tmp/newroot/etc,sbin Expected Results: Files should be in /tmp/newroot/etc,sbin
Thanks very much for spotting that! I've corrected the version in the vmware overlay (which you can get using layman). Could you please check if that works? If so I'll push it into the main tree... 5:)
Fantastic! The -r1 ebuild fixed the issue in my environment. As an aside, when trying to emerge the new ebuild from the overlay I got a bunch of manifest errors like: !!! /usr/portage/local/layman/vmware/app-emulation/open-vm-tools/open-vm-tools-0.0.20071121.64693-r1.ebuild !!! Reason: Failed on RMD160 verification !!! Got: e8fe1222b5ec9ebd431c1e55adb7bc420e698dc7 !!! Expected: 34fb4665a7abceb563a72d849a9773455742f0e1 But since that's a metadata issue, I imagine it will magically fix itself when you push it to the main tree. Thanks for the fast turnaround Mike!
No problem Brandon, and actually I just screwed up and forgot to digest it the first time, I've fixed that up in the overlay too. It'll go in the tree next time I do a sync between the two. Thanks for testing it so quickly! 5:)
Nope, that doesn't cut it... dodir "${ROOT}${LIB}" dodir "${ROOT}etc/pam.d" Further... <snip> echo -e "auth\tsufficient\t${ROOT}${LIB}/security/pam_unix${PAM_VER}.so\tshadow\tnullok" >> "${PAMFILE}" echo -e "auth\trequired\t${ROOT}${LIB}/security/pam_unix_auth.so\tshadow\tnullok" >> "${PAMFILE}" echo -e "account\tsufficient\t${ROOT}${LIB}/security/pam_unix${PAM_VER}.so" >> "${PAMFILE}" echo -e "account\trequired\t${ROOT}${LIB}/security/pam_unix_acct.so" >> "${PAMFILE}" </snip> The above will get broken as soon as you've chrooted to ${ROOT}. To summarize, ${ROOT} should never be used in src_*
Thanks Jakub. 5;) All fixed up now hopefully. I'll leave the bug open for a bit to see if there's anything else not quite right... 5:)
(In reply to comment #5) Mkay, seems like I missed one... could you clarify what are you after here, please? <snip> if [[ -e "${ROOT}${LIB}/security/pam_unix2.so" ]]; then PAM_VER=2 fi </snip> If this compiles/links against PAM, it will always use the PAM stuff in /, not ${ROOT}, so that's be broken as well. Or, is this about something different?
Sorry about that, the pam code was provided by a contributor and looked OK when I first checked it. It looks to see if pam_unix2.so exists, in which case when it writes the pam file, it sticks a 2 in the pam_unix.so filename. It correctly checks ${ROOT} for the location it's being installed to, since if that location is ever chrooted to, it's that pam_unix2.so that'll get used. However, thinking about it, that's a pretty nasty method, and I don't think any of Gentoo's pams install a pam_unix2.so, so I'll probably replace all that with a permanently installed pam file copied from ${FILESDIR} and do away with the USE flag all together, when I get a bit more time. Thanks for the ebuild review Jakub, I'd probably never have spotted it. 5:)
(In reply to comment #7) > it writes the pam file, it sticks a 2 in the pam_unix.so filename. It > correctly checks ${ROOT} for the location it's being installed to, since if > that location is ever chrooted to, it's that pam_unix2.so that'll get used. Well, I didn't check the code, but it wouldn't work unless it actually gets compiled against it (and then pam_unix2 would have to be in / as well). > and I don't think any > of Gentoo's pams install a pam_unix2.so, so I'll probably replace all that with > a permanently installed pam file copied from ${FILESDIR} and do away with the > USE flag all together, when I get a bit more time. Well, we don't have pam_unix2 ebuild, only a request in Bug 97425 so this whole code it just irrelevant I'd say, yeah. The pam file still looks a bit weird to me, we don't ship pam_unix_acct.so either. Unless this bundles it's own pam, can you check whether the following works for you instead? Just inherit pam and replace the echo -e stuff with pamd_mimic_system ${PAMFILE} auth account (takes also password and session as arguments in case you'd need them).
Cool, I never knew about that function, thanks! I'll give it a go.
Just to prevent confusion, PAMFILE="vmware-guestd" (no path needed/wanted there)
Ok, hopefully the overlay's pam stuff is all fixed up now in the latest ebuild. Hopefully this will hit the tree soon. Thanks for your help Jakub! 5:)
The -r1 ebuild works great for me, any idea when it might hit the main trees?
It hit the main tree, but has been masked because I rolled in a couple of other patches for kernel build issues, and the 2.6.24 patch causes lots of soft lockups. The open-vm-tools team are investigating this now, so we're rather waiting on that I'm afraid...
I think this is now well and truly fixed. Do feel free to reopen this, if I've still missed something... 5:)
