I know that vanilla-sources is unsupported, but given the fact that kernel crowd is saying thet everything is working beautifully and that tis is last release candidate, I thought bug of such kind is worth reporting. With vanilla-sources-2.6.27-10 everything seems to be fine, but latest 2.6.28-rc has some problems. It booted more or less fine, but /etc/init.d/bootmisc failed with segment exception, so I tried to reemerge openrc ( I had baselayout 2.0 with openrc 2.5 ), but every time I tried to emerge anything, emerge failed with segment exception. So I thought maybe soemone else could try before official 2.6.28 comes out. I have: Phenom 9950 Foxconn A7DA-S 8GB DDR-II ( 4x 2GB stick) nvidia 8800GT with latest cuda-beta nvidia driver 180.06 ( earlier 177.82 won't compile with 2.6.28 kernel) Reproducible: Always
Created attachment 176009 [details] output of emerge --info
You need to actually show us an error. What happens?
Created attachment 176013 [details] logfile from "emerge baselayout"
Created attachment 176014 [details] environment from "emerge baselayout"
Created attachment 176015 [details] /etc/fstab Since there seem to be a problem with tmpfs I reckon it wouldn't hurt to include this as well...
Created attachment 176024 [details] config file from kernel compile...
I am sure there is relevant dmesg output accompanying the segfault notifications.
(In reply to comment #7) > I am sure there is relevant dmesg output accompanying the segfault > notifications. > Not a thing IIRC- I checked. But this is irrelevant, I solved the problem. It wasn't about kernel. Since it was relevant some other problems I had ( not all files from package were copied from WORKDIR to ROOT when /var/tmp was on tmpfs ), I'm copy&pasting solution I posted on gentoo-dev@lists.gentoo.org. It works now, I'm changing status of this bug as "invalid". ********************* 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...
