Duncan wrote: > Branko Badrljica <bran...@avtomatika.com> posted > 494f1518.2020...@avtomatika.com, excerpted below, on Mon, 22 Dec 2008 > 05:18:32 +0100: > > >> Maybe I should have filed this as a bug, but don't have a clue to which >> package should I assign it, if any. >> > > FWIW, this would have been a perfect question for the gentoo-desktop > list, but doesn't really belong on the -dev list. There's also the > gentoo-user list, altho that one has very heavy volume so you might not > wish to subscribe there.
Well, regarding the actual error, i think it might interest someone here, also. Although I mentioned just baselayout and openrc, I did check ( end reemerged etc) hal also, and it indeed emerged _without_ /etc/init.d/hald. I tracked it down to root cause: Although I don't use it, I have compiled-in selinux support ( and selinux=0 as kernel start parameter). When I was makeconfiging my kernel, I saw also SMACK support, read info and thought "what the heck, it can't hurt me, but I might want to play with it", so I compiled-in that, too. Then after some time I realised that I never got to actually used all that and changed my config file by cutting out that all that security stuff. And recompiled all my kernels accordingly. Around that time I saw people recommending using tmpfs for /var/tmp as this would speed-up emerges etc, so I did that. I didn't know that while I was on SMACK (pun intended) , machine would add extended attr to every file machine would write. ( It was SMACK64 in security domain ). After cleaning my system, even though those attributes were still on all files, everything was fine until I actually tried to copy something from that FS to some other FS. /bin/cp would realise that there are extra security attrs on a file and would try to duplicate them on a copy. And since new kernel was without SMACK support, it would fail. When emerging stuff with /var/tmp on tmpfs, /bin/cp seems to get rarely used in such way when copying stuff into /var/tmp or maybe it was because distfiles were without SMACK attrs- so most ebuilds would seemingly sucseed. Most errors seem tho have been made when ebuild needed some local data, usually in /etc that had SMACK64 attr. If /bin/cp was used to get that data, it would fail, but this would not stop the ebuild. It would usually finished its work just as if nothing happened. Once I unmounted /var/tmp, ebuild could finish normally. Also, after removing security attr from all files, ebuild has started working normally from tmpfs partition again. It is also interesting that on 2.6.27* kernel ebuild fails sometimes and when it fails, it does so silently most of the time. With newest 2.6.28-rc9 i couldn't emerge a thing... Since I might not be the only tinkerer on Gentoo to try stuff like that and since it took me a day to find this, maybe it wouldn't hurt to check for this kind of thing in portage ? At the very least failed cp should stop emerge...