Fedora 10 won't boot after installing 4Gb of system memory

Thetargos · #1 9th May 2009, 06:35 PM

I have been using for over a year now, my 64-bit computer first with Fedora 8 and now with Fedora 10 with 2Gb of RAM just fine. Today I purchased an extra 2Gb for the system and upon installation from the GRUB screen Fedora 10 simply won't boot. It does boot with 3Gb, and it doesn't matter which stick I use for the 3Gb configuration, or what slot do I put the sticks into the motherboard, however if I place the four sticks, F10 simply won't boot. Should I pass a command line argument tot he kernel? If so, which?

TIA!

notageek · #2 9th May 2009, 06:39 PM

Hi

What do you mean by it won't boot? Does it beep? Do you get video? Do you get past the grub? Does it POST? etc

Thetargos · #3 9th May 2009, 07:00 PM

I thought it should have been obvious what I meant. May be I have to be more clear. Sorry.

Yes, I get POST, yes I get to GRUB, yes I can edit the boot parameters in GRUB, F10 won't boot. After grub only a black screen is shown and nothing more, it doesn't matter if I remove the "quiet" kernel command-line argument. It won't boot.

shess01 · #4 9th May 2009, 07:13 PM

Just so everyone knows out there that an x64 architecture does not necessarily mean a x64 OS...

Post the output of "uname -r"

ps. I know you do ;-)

notageek · #5 9th May 2009, 07:28 PM

I'm sorry if it was obvious, but I like being explicitly told what is happening. I therefore assume it'll not boot to single user mode too.

It appears with your issue, only someone with similar experience can help.

Edit: Does taking out rhgb change anything?

Thetargos · #6 9th May 2009, 07:45 PM

Quote:

Originally Posted by shess01

Just so everyone knows out there that an x64 architecture does not necessarily mean a x64 OS...

Post the output of "uname -r"

ps. I know you do ;-)

uname -r
2.6.27.21-170.2.56.fc10.x86_64

And notageek, nope, it does not help at all. Only taking one stick out would help. This is really, really, really weird... Oh, and by the way, Ubuntu, Mint and other LiveCD distros do boot, even F11 (when on the CD) with the 4 Gb (and they are all arch x86_64), however F11 when installed onto a LiveUSB stick, does not... How weird is that? Currently in the process of downloading an F10 Live image, we'll see if that boots.

notageek · #7 9th May 2009, 07:52 PM

I suspect (and purely suspect) it does boot to the kernel. With the new graphical boot in F10, one cannot view the "Uncompressing Linux..." message before the graphical boot takes over (or can you?).

Therefore the graphical boot could be an issue (not 100% sure).

marko · #8 9th May 2009, 07:55 PM

boot the install dvd to rescue mode and run memtest for a while

Like notageek says, append a 1 and remove the rhgb quiet from the grub line and retry booting.
This may help show if it's a video driver problem. Maybe your bios doesn't work right with
mapping the video card if the RAM is > 3GB

YeOK · #9 9th May 2009, 09:17 PM

I'd also suggest checking for a BIOS update.

Thetargos · #10 9th May 2009, 11:55 PM

Thanks for the comments, Markio, notageek and YeOK.

In order:

No, removing rghb and trying to get to a single-user prompt (append 1 after the kernel command-line boot argument) works, the system does not even print any messages about the kernel image being uncompressed. However I got to the root of the problems (see bellow).
Both running memtest and upgrading the BIOS (in that order, actually) yielded what I feared: A bad memory block. First I should have suspected something was amiss when the new memory couldn't handle dual-link DDR with the new modules (system freeze), which lead me to run memtest (for quite a while until it got to the faulty memory stick which true to Murphy's law, was the last, and the fautly bits were the very last of the stick So it it took memtest a while to get there and hard-freeze the computer. Then the BIOS update did detect the faulty memory block and even prevented the machine to boot (with a series of one long beep and two short beeps)

So in the end it apparently boils down to a a faulty memory bock which when the kernel finishes uncompressing, or GRUB passes onto it the amount of memory detected by the BIOS and it tries to map it (which apparently happens before any messages are printed to std-out) the machine simply locks. The problem is that the vendor I got the memory from will open until monday, so until then I'm stuck with 2Gb of dual-link 128-bit DDR2 or 3Gb of single-link 64-bit DDR2 RAM, I guess the answer to the dilemma is kind of obvious (I'll stick with my tried and true 2Gigs of RAM until monday)