Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

["Robert R. Russell" <nahoy_kbiki@hushmail.com>]

On Monday 22 December 2008 11:40:32 pm Branko Badrljica wrote:
> Duncan wrote:
> > Branko Badrljica <brankob@avtomatika.com> posted
> > 494F1518.2020109@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...

Very nice edge case and great work tracking down the cause.