From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LF3r5-00087h-DP for garchives@archives.gentoo.org; Tue, 23 Dec 2008 09:47:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 38113E0759; Tue, 23 Dec 2008 09:47:10 +0000 (UTC) Received: from smtp12.hushmail.com (smtp12.hushmail.com [65.39.178.135]) by pigeon.gentoo.org (Postfix) with ESMTP id 0490AE0759 for ; Tue, 23 Dec 2008 09:47:10 +0000 (UTC) Received: from smtp12.hushmail.com (localhost.localdomain [127.0.0.1]) by smtp12.hushmail.com (Postfix) with SMTP id 19C6D70256 for ; Tue, 23 Dec 2008 09:47:09 +0000 (UTC) Received: from smtp.hushmail.com (app1.hushmail.com [65.39.178.74]) by smtp12.hushmail.com (Postfix) with ESMTP for ; Tue, 23 Dec 2008 09:47:08 +0000 (UTC) From: "Robert R. Russell" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ? Date: Tue, 23 Dec 2008 03:47:06 -0600 User-Agent: KMail/1.9.9 In-Reply-To: <495079D0.5060704@avtomatika.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: X-Archives-Salt: 1607fbd8-828e-44d4-b82f-62f9f88ebd05 X-Archives-Hash: 51b0f2d2bbf2e269977747606f42aff4 On Monday 22 December 2008 11:40:32 pm Branko Badrljica wrote: > Duncan wrote: > > Branko Badrljica 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.