Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Glibc segmentation fault
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo on AMD64
View previous topic :: View next topic  
Author Message
fargred
n00b
n00b


Joined: 19 Oct 2010
Posts: 40

PostPosted: Fri Apr 13, 2012 6:36 pm    Post subject: Glibc segmentation fault Reply with quote

Hi there!

After a full rebuildnig of the system, and if to be correct after
1. emerge -NuDbav @system
2. emerge -NuDebkav @world
it seems I have some problems with glibc. When some programs starting, they cause a segmentation fault in glibc that can be seen in dmesg.
For example:
Code:
[152238.045065] deluge[7371] general protection ip:7f72d0dc341f sp:7fff9976b9f8 error:0 in libc-2.13.so[7f72d0c90000+19c000]

That is not only deluge but a couple of gnome apps, that need gconfd-2 to be running, but it cannot giving the same string in dmesg, so I cannot use around a ten applications. I thought it could be a broken version of gconfd-2, libgnome, dmesg, tried previous versions and so on, but nothing helped me. I even tried unstable version of glibc but it did nothing (with some hack I returned stable version of glibc on my system)

Globally I use ‘amd64’ as a keyword. ‘~amd64’ is used for a bunch of packages only (such as mplayer and ffmpeg) that I know by sight.
As I remember, I had issues with glibc earlier. Segmentation faults were in 2.11 and 2.12 but never been a cause of such a disaster. (Yes, since I cannot use torrents it’s a disaster).

Here is emerge --info
And here is a list of all packages in my system and their versions.

Reading about android I’ve know that there is an alternative to glibc called uclibc. Can it be the solution in this case?

Sorry for my engrish and thanks in advance.
Back to top
View user's profile Send private message
skybon
n00b
n00b


Joined: 31 Mar 2011
Posts: 11
Location: Европа/Москва

PostPosted: Wed Apr 25, 2012 4:49 am    Post subject: Reply with quote

Are you still having the problem? If so, please make sure you have the latest stable glibc (2.14.1-r3). After that run revdep-rebuild.

P.S. Your paste is unavailable.
Back to top
View user's profile Send private message
fargred
n00b
n00b


Joined: 19 Oct 2010
Posts: 40

PostPosted: Thu May 10, 2012 10:10 pm    Post subject: Reply with quote

Yes, I still do have that problem even with glibc 2.14.1-r3. I’ve also tried to do revdep-rebuild, mask prelink, disable distcc and ccache and nothing helped.
Of course I rebuilt all my @system and @world every time after making changes to configuration.

// I checked my pastes and they’re ok.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 4105
Location: USA

PostPosted: Thu May 10, 2012 10:42 pm    Post subject: Reply with quote

Is your machine in good shape? Is it overheating? PSU working?

Are all the segfaults happening at the same address, random?
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
fargred
n00b
n00b


Joined: 19 Oct 2010
Posts: 40

PostPosted: Fri May 11, 2012 2:22 am    Post subject: Reply with quote

eccerr0r wrote:
Is your machine in good shape? Is it overheating? PSU working?

It is almost new top machine but I still use my old hard drive, it isn’t two years old yet and smartctl said there is no reallocated blocks, I also checked filesystems with fsck (ext3) and all seems to be ok.
eccerr0r wrote:
Are all the segfaults happening at the same address, random?

As of addresses, I did a test with deluge running it four times, the result you can see below
Code:
[364038.861166] deluge[17139] general protection ip:7f2c77c0fa5f sp:7fffd9448f18 error:0 in libc-2.14.1.so[7f2c77af4000+184000]
[364045.099559] deluge[17231] general protection ip:7fc77f686a5f sp:7fff5b15d4c8 error:0 in libc-2.14.1.so[7fc77f56b000+184000]
[364047.435585] deluge[17270] general protection ip:7fcca04c4a5f sp:7fff1efcebe8 error:0 in libc-2.14.1.so[7fcca03a9000+184000]
[364048.638552] deluge[17285] general protection ip:7f590ddcca5f sp:7fffed999fe8 error:0 in libc-2.14.1.so[7f590dcb1000+184000]

As far as I understand, instructions of each instance of the application were placed in memory one by one, but the offset in code in libc-2.14.1.so causing segfault is the same.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 4105
Location: USA

PostPosted: Fri May 11, 2012 4:33 am    Post subject: Reply with quote

You might want to pull glibc from tinderbox or livecd and use that to rule out libc build issues. Use the livecd to mess with it so you don't wreck your machine mid hack.

I still would have to lean towards faulty hardware at this point, I don't see way too many libc issues, then again I don't use deluge, and I've not seen that many libc segfaults on my x86_64 or any of my machines...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
fargred
n00b
n00b


Joined: 19 Oct 2010
Posts: 40

PostPosted: Fri May 11, 2012 5:53 am    Post subject: Reply with quote

eccerr0r wrote:
You might want to pull glibc from tinderbox or livecd and use that to rule out libc build issues. Use the livecd to mess with it so you don't wreck your machine mid hack.

Okay, let’s say I have livecd, how do I pull glibc from it properly? Or do you suggest to build glibc on livecd and place into chrooted filesystem? Wouldn’t be easier just save /etc/, /var/lib/portage/world and unpack fresh stage3 on cleaned partitions, then move /etc and /var/lib/portage/world to their places and make emerge -NuDave @world?
eccerr0r wrote:
I still would have to lean towards faulty hardware at this point, I don't see way too many libc issues, then again I don't use deluge, and I've not seen that many libc segfaults on my x86_64 or any of my machines...

As I wrote before it is not only deluge but a bunch of apps that cannot be run. The system feels stable except of glibc. I didn’t close Firefox with 80-90 tabs for about four days now since the last compilation and it is ok too. Dont know what else can be proof of stability if this isn’t.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 4105
Location: USA

PostPosted: Fri May 11, 2012 2:15 pm    Post subject: Reply with quote

fargred wrote:
Code:
CFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -msse4.1"


I just saw this calamity. Can you try building glibc (and possibly other applications) without this, say, just

CFLAGS="-O2 -pipe"

and then see if it will stop segfaulting?
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
fargred
n00b
n00b


Joined: 19 Oct 2010
Posts: 40

PostPosted: Mon May 14, 2012 4:32 am    Post subject: Reply with quote

Finally done, still the same.
Back to top
View user's profile Send private message
fargred
n00b
n00b


Joined: 19 Oct 2010
Posts: 40

PostPosted: Wed May 16, 2012 1:35 am    Post subject: Reply with quote

Yesterday I extracted a fresh stage3 image on cleaned partitions, compiled the world and the old problems were solved. But I got new bug in exchange. This time python-2.7 causes segfaults. That’s a plague, but it is deluge again. But not a client binary file like at first time.
Code:

[ 2305.359397] deluged[13989]: segfault at 1a356 ip 000000000001a356 sp 00007fff4a2ad078 error 14 in python2.7[400000+1000]
[ 2305.967214] deluged[14018]: segfault at 1a356 ip 000000000001a356 sp 00007fff44e7f828 error 14 in python2.7[400000+1000]
[ 2306.399082] deluged[14047]: segfault at 1a356 ip 000000000001a356 sp 00007fff3c9da3b8 error 14 in python2.7[400000+1000]
[ 2306.775395] deluged[14076]: segfault at 1a356 ip 000000000001a356 sp 00007ffffade7d98 error 14 in python2.7[400000+1000


I also found another strange thing — gconfd-2 ate around 700MiB of memory and stopped. Memory maps show that it is heap uses 700MiB. Output of strace done on gconfd-2:
Code:
Process 3977 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=19, events=POLLIN|POLLPRI}, {fd=20, events=POLLIN|POLLPRI}], 12, 29976) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=19, events=POLLIN|POLLPRI}, {fd=20, events=POLLIN|POLLPRI}], 12, 29987) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=19, events=POLLIN|POLLPRI}, {fd=20, events=POLLIN|POLLPRI}], 12, 29985) = 0 (Timeout)
Back to top
View user's profile Send private message
Arkhelion
Tux's lil' helper
Tux's lil' helper


Joined: 07 Sep 2010
Posts: 131
Location: France

PostPosted: Wed May 16, 2012 10:18 am    Post subject: Reply with quote

Check "eselect python list". IIRC deluge needs you to have python 2.7 as main.
_________________
Arkhelion
Back to top
View user's profile Send private message
fargred
n00b
n00b


Joined: 19 Oct 2010
Posts: 40

PostPosted: Wed May 16, 2012 1:46 pm    Post subject: Reply with quote

Arkhelion wrote:
Check "eselect python list". IIRC deluge needs you to have python 2.7 as main.

But it is clear from the output that deluged tries to use exactly 2.7 version. Though I choosed 2.7 as primary, but that didn′t the trick.
Another strange thing is gnome-screensaver fails at locking my screen.
Code:

$ gnome-screensaver
** (gnome-screensaver:3563): WARNING **: Couldn't get presence status: The name org.gnome.SessionManager was not provided by any .service files
$ gnome-screensaver-command -q
The screensaver is inactive
The screensaver is not inhibited
$ gnome-screensaver-command --lock

# The screen fades to black, and there is nothing, but mouse cursor become I-beam on right side of it. I cannot log in or kill that thing. In `ps aux` list there is no more gnome-screensaver.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 4105
Location: USA

PostPosted: Wed May 16, 2012 10:51 pm    Post subject: Reply with quote

Is this your only machine? What if you try the binaries on another machine?

Are you using basic CFLAGS now? That is, without -march, etc. ?

Do other Linux distributions exhibit similar issues?

Honestly I'm still thinking it's a hardware issue, my x64_64 machine does not segfault nearly as often. I think the only program that occasionally segfaults is mythtv but all of gnome is just fine.

I suspect that memtest86+ may not show anything though but it's worth to run.

CPU, M/B, and PSU are still potential suspects.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
fargred
n00b
n00b


Joined: 19 Oct 2010
Posts: 40

PostPosted: Thu May 17, 2012 9:43 am    Post subject: Reply with quote

eccerr0r wrote:
Is this your only machine?

Yes.
eccerr0r wrote:
What if you try the binaries on another machine?

Do you mean I should run precompiled binary built on problem machine on some other?

eccerr0r wrote:
Are you using basic CFLAGS now? That is, without -march, etc. ?

No. Lucky me remembered to return my CFLAGS back. If you have any doubts I can explain them with quotes from man gcc and tech specs from intel site.

eccerr0r wrote:
Do other Linux distributions exhibit similar issues?

I didn′t try any other, guess they should work [spoiler]until first update.[/spoiler]

eccerr0r wrote:
Honestly I'm still thinking it's a hardware issue, my x64_64 machine does not segfault nearly as often. I think the only program that occasionally segfaults is mythtv but all of gnome is just fine.

I′m so glad of you.

eccerr0r wrote:
I suspect that memtest86+ may not show anything though but it's worth to run.

Didn′t you think that if my memory was broken I should experienced SUDDENLY crashes and kernel panic?

eccerr0r wrote:
CPU, M/B, and PSU are still potential suspects.

And I susprect wrong USE flags for some packages… Could you please call for someone to check′em?
Back to top
View user's profile Send private message
toralf
Advocate
Advocate


Joined: 01 Feb 2004
Posts: 2742
Location: Hamburg/Germany

PostPosted: Thu May 17, 2012 10:12 am    Post subject: Reply with quote

Sometimes I've such segfaults too (with php, wireshark, libre office) - but it seems to be rather depends on a particular day than on glibc - meaning, after an reboot it vanished.
Back to top
View user's profile Send private message
Thistled
Guru
Guru


Joined: 06 Jan 2011
Posts: 482
Location: Scotland

PostPosted: Thu May 17, 2012 12:14 pm    Post subject: Reply with quote

Please ensure you have the following as CFLAGS
Code:
CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"

Also, remove all traces of distcc.
Perform a full re-build once you have done ths.
I ran into a similar problem with segfaults, and it all boiled down to the fact I had built my system using distcc.
It rendered Gnome-3.2 useless with a segfault appearing everytime in libmozjs.
See the following:
https://bugs.gentoo.org/show_bug.cgi?id=388521
_________________
Whatever you do, do it properly!
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 4105
Location: USA

PostPosted: Thu May 17, 2012 2:24 pm    Post subject: Reply with quote

Yes, make sure you remove all esoteric CFLAGS from building system libraries, just to make sure you're not exposing a gcc bug. This has shown up time and time again, and frustrated many Gentoo users over and over again. There is no other Linux distribution that allows these build flags, they all use conservative settings that have been tried and true - such that nobody will odd problems.

Thence I reiterate CFLAGS="-O2" and possibly "-pipe" is basically all you should use. -O2 has been well tested. Even -Os (to generate smaller, but possibly slower binaries) has been a bug point in the past. Using no optimization options (CFLAGS="") should work just fine too.

The reason why I keep on repeating that my machines do not have this problem indicates it's clearly a problem with specifically your installation. I do not have special CFLAGS specifically due to the fact Gentoo users have gotten funny things happening when building with them - this is actually one of the repeatable problems that will break many peoples' machines instead of one-off problems which point to hardware issues. (BTW, mythtv crashes mostly when I receive a broken ATSC signal off the air, so you get all this noise in the signal; I'm not sure how well mythtv should be handling very bad received/stored signal quality.)

When things work until an update, does it not sound like it was some setting you introduced if nobody else is having problems? The livecd/installer CD was built with conservative settings, as well as most other distributions.

Really, tailored CFLAGS should be only used on specific binaries, namely application binaries that should be using most of CPU time. Libc, kernel should use settings that are known to work for it, these, though important, should not be using much CPU time, and by Amdahl's law, clearly has diminishing returns when optimized. This is not to say you shouldn't at least try them, say, for Deluge or even Python... but all bets are off.

I also agree with thistled - I've had problems with distcc in the past as well. Most of the times it's due to my boxes having different versions of distcc but sometimes some of my less reliable machines miscompiles an object file and thus generates a broken binary making it very hard to debug the problem. So agreed, remove distcc to debug (though this is probably not the case as the OP indicates he only has one machine.)
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Mon May 28, 2012 9:49 pm    Post subject: Reply with quote

(NB: Not using a core2 cpu, rather an amd athlon X2; still x86_64, though.)

This has been working for me without CFLAGS-related problems since I installed
Gentoo:

CFLAGS="-march=native -O2 -fno-strict-aliasing -pipe -Wall"
CXXFLAGS="-march=native -O2 -fno-strict-aliasing -fpermissive -Wall"

I let the current gcc code decide what cpu-specific compiler options are most
useful on average on the current cpu.

("-fno-strict-aliasing" relates to optimizations that are only safe if the code
is structured without some C/C++ variable references that are entirely legal
according to the language standards but that make those optimizations
unsafe to use. "-fno-strict-aliasing" tells gcc not to bother with those optimizations
at all, instead of optimizing the memory references in that code and issuing a
warning.

"-fpermissive" allows some C++ usages to compile that only triggered warnings
before the 1998 C++ standard but were defined as errors after that and would
prevent the compiler from compiling the package. My feeling is that the need
for "-fpermissive" is an implicit FIX ME, and developers and maintainers will
get around to those chunks of code that need it eventually, so that the program
or library compiles without "-fpemissive" in CXXFLAGS.)

What is with "-fomit-frame-pointer"? It made sense when I was running linux on
a 486, and everything was slow. Saving the cycles and icache used by a frame
pointer was a definite win. On today's cpus, having the frame pointer available
to stack tracers seems like a bigger win to me than saving a few cpu cycles or
having a few less instructions in icache for an executable. (Not running a data
center or hpc system, after all. I can afford a little runtime performance to find
out what went wrong faster when things break.) Is there some feature of today's
gcc code and stack tracers that makes the frame pointer irrelevant for back traces?
_________________
TIA
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Mon May 28, 2012 10:06 pm    Post subject: Reply with quote

PS:

My first thought for the OP's problem was ram. If the problem was power supply,
it seems like the memory addresses where the problem shows up would change
more randomly. It could be mis-compilation, but a stuck bit that does not change
on a write is always in the same place in the same dram chip. Reinstalling/recompiling
significant parts of the system commonly changes where things are loaded into
memory, but the error will still consistently show up at a particular address after that.

A compiler bug can do that, but failed memory chips do it more often in my experience.
_________________
TIA
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 4105
Location: USA

PostPosted: Mon May 28, 2012 11:35 pm    Post subject: Reply with quote

I'm just playing devil's advocate here:

Well, we do have one limited commodity on even modern machines: cache. The more that can be fit in the cache the faster the machine will run.

However, for the most part, yes I'd rather have them compiled in except for embedded machines in which space comes at a premium. However I think this one of the "safe" options that should not cause machines to crash...

I do have to make one observation recently: one of my x86 (32-bit) machines was perfectly stable but after getting a kernel upgrade it's randomly crashing left and right. Swapping back to the old kernel/installation and the crashes disappear. Still trying to figure out what's going wrong here...clearly a software issue it seems so far...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
Thistled
Guru
Guru


Joined: 06 Jan 2011
Posts: 482
Location: Scotland

PostPosted: Tue May 29, 2012 4:34 pm    Post subject: Reply with quote

Same happened to me, as soon as I started using anything above 3.2.12 series of kernel, I started to experience segfaults with apps.
Nautilus, nvidia-settings, and evolution.
So I am back to stable gentoo-sources-3.2.12 for the time being.
_________________
Whatever you do, do it properly!
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Wed May 30, 2012 6:58 am    Post subject: Reply with quote

I do not think -fomit-frame-pointer causes crashes, unless one is compiling
with some bleeding edge gcc version that has a bug somewhere related
to that option. I simply tend to want the best back trace possible when
things do crash that have been compiled with a stable gcc version. If that
requires some sacrifice of best possible performance and code size, then
some deployments can afford it without noticeable loss of efficiency
(where the cpu is doing nothing most of the time anyway while the
user edits something, reads text, the system waits on i/o, and so on),
while for others eliminating the extra instructions in production code
is worth more than faster debug.
_________________
TIA
Back to top
View user's profile Send private message
gasparov
Tux's lil' helper
Tux's lil' helper


Joined: 13 Apr 2006
Posts: 105

PostPosted: Thu Jul 05, 2012 10:11 am    Post subject: Reply with quote

same here, gnome doesn't work anymore, gconfd reaches 100% and start to eat resources , up to 3GB rams, I have also the general protection errors

Code:
gconfd-2[3292] general protection ip:7f8f7e5ce5b1 sp:7fff15c12568 error:0 in libc-2.14.1.so[7f8f7e54e000+184000]


this problem happened to me also after emerge -e system followed by world, I have never downgraded glibc, i simply reinstalled the same glibc i had.

emerge --info :http://pastebin.com/pNT7jaY0

I have installed crossdev and i have some reference to /usr/arm... in emeerge --info, could it be the problem? wild guess here
Back to top
View user's profile Send private message
Arrta
Tux's lil' helper
Tux's lil' helper


Joined: 09 Nov 2003
Posts: 103

PostPosted: Sun Jul 08, 2012 1:29 am    Post subject: Reply with quote

I doubt it has anything to do with crossdev as I just rebuilt both of my systems from scratch, and I don't use crossdev, and I ran into issues with segfaults compiling glibc as well.

Here is my situation:
Boot from minimal USB
chroot into HDD
run bootstrap (no segfault on glibc build)
run emerge -e system (no segfault on glibc build)
compile kernel
reboot from HDD
restore world file from previous system
run emerge -e world (yes I know its overkill, glibc segfaults on install step? Attempts to run emerge --resume causes glibc to segfault during compile phase.)
reboot from HDD (emerge --resume again segfaults on install step of glibc)
reboot from minimal USB, chroot into HDD (emerge --resume compiles glibc successfully)
reboot from HDD and resume emerge after glibc without any other issues.

My other system on the other hand is netbooted from the first machine.
Because it would take too long to build the system from the netbooted machine, I chroot into the netboot folder and build on my server.
run bootstrap (no segfault on glibc build)
run emerge -e system (glibc segfaults on install step? Attempts to run emerge --resume causes glibc to segfault during compile phase.)
reboot from HDD (emerge --resume again segfaults on install step of glibc)
reboot from minimal USB, chroot into netboot folder (emerge --resume compiles glibc successfully)

for some reason glibc does not like to be recompiled from my hdd, but works fine when running from a minimal USB/DVD, and possibly a liveUSB/DVD.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 4105
Location: USA

PostPosted: Sun Jul 08, 2012 7:20 am    Post subject: Reply with quote

This seems to imply that the kernel on the hard drive is not good for your machine somehow.. What happens if you just copy/use the livecd/liveusb kernel as your hdd's kernel (remember to copy any initrd's, /lib/modules/, etc.) or use the .config of the livecd/liveusb kernel to build your hdd kernel...

I suppose it's ok to muck with the hdd drivers, etc. to make sure it will boot your particular machine without using initrd if you don't want one, but don't touch the CPU config (including memory options even if it will not let you detect all of your memory -- but this shouldn't be an issue for x86_64) or any of the optimization options.

As for the original poster, he should try this too, just to see if there are any similarities (try to build your glibc with a chroot from the livecd/liveusb).

The livecd/liveusb installer kernel tends to be built very conservatively, and allows for any hardware to run properly...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on AMD64 All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum