[SOLVED] Failure to boot -- RAM was found to be faulty

[peter_pclos]

This is a revised version of a now-deleted post.

I had a booting problem with PCLinuxOS 2012.02 on a month-old desktop PC a couple of days ago, brief details of which are set out below, but which I now suspect aren't particularly relevant.  I have subsequently tried booting from two different live versions of PCLinuxOS, and in each case the PC fails to boot, reporting segmentation errors.  Since both these live versions have worked perfectly on this PC over the last month, my assumption would be that there is a problem either in the RAM or in the motherboard/CPU (or both!?) leading to the faulty segmentation.  Although I'm not a system specialist I would normally investigate this myself inside the box, but this time I didn't self-build and I'd be glad to receive any feedback from those wiser than I am before I invoke the warranty from the supplier (who isn't Linux aware).


Can anybody help me get my desktop PC  back?

Background to the problem:

The sequence of events began when I attempted to use q4wine on the PC, and immediately encountered the problem with the missing sudo facility.  A thread elsewhere in the forum indicated that the entry for sudo in the q4wine wizard could be copied and pasted from another field, so I tried this, and got to the end of the installation process.  Then I tried to use the Help tab on the q4wine window, and immediately got a stack of 8 or 10 local information messages on the screen, by which time the whole thing had locked solid and could not be dealt with by Alt/Prt Screen/S,U,B (so I couldn't even read the messages).  Eventually, after several attempted but abortive re-boots, I managed to log on long enough to completely remove q4wine with Synaptic, and trusted that this would solve the problem.  It didn't.  Eventually I managed to get as far as the following Kernel Panic message:

ACPI Aborted because junk in compressed archive
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Pid : 1 comm: swapper Not tainted 2.6.38.8-pclos3 .bfs #1

This was followed by a Call trace with the following entries.  I obviously couldn't cut and paste these, but I made a note of the sequence of calls:

panic+0x66/0x161
mount_block_root
create_dev.clone.0
initrd_load
ind_run_setup
prepare_namespace
sys_access
kernel_init
kernel_init  {yes, this is a repeat}
kernel_thread_helper
_

At this point everything froze, with two of the LED's on the keyboard flashing in unison.

The only other non-routine thing I had done recently was to try out a live DVD image of the TOR-based Tails Linux, which seemed to run perfectly well.

[pmpatrick]

Since this worked fine in the past and now will no longer run even the livecd version, the most likely suspects would be either the ram or the power supply(psu). Could you post the make and model of the PC if it came from a manufacturer like Dell or HP. Also, open up the case and see if you can determine the make and model of the psu. Some bargain basement manufacturers like emachines are notorious for using cheap Bestec psus with high failure rates. You may be able to check your voltages in the bios setup if that feature is available. Even if they check out OK there, the psu could still be a problem as cheap ones can go out of spec under load and booting is a high load time for a psu. Ram can be tested with memtest86+:

http://www.memtest.org/

Let it run for several hours and see if any errors are reported.

[Just17]

in each case the PC fails to boot, reporting segmentation errors.

When do you get this error ......  a more detailed explanation of the process is required to get some idea at what stage the error happened.

Do you get to the Grub boot screen?

Do you see details of the boot process up to the error?

Have you tried the alternate boot options?

It may also be a HDD problem ....  so more info is needed.

[peter_pclos]

Thanks for the replies so far.

pmpatrick:  Starting the PC from the hard disk (i.e. no live linux disk in the DVD drive) and running memtest from the grub menu gave a rapidly scrolling list of entries in the lower part of the screen, on a bright red background.  This was accompanied by a mounting tally of errors in the top part of the screen, running into the tens of thousands (before I hit <ESC> to go back into the booting process).  So it looks to me as though the problem lies with the RAM  -- is that a fair assumption, or am I over-simplifying? 

The build spec of the PC is:

RAM:  2x4GB Corsair PC12800 1600 MHz DDR3. 
PSU:  Quiet Xilence 600W  (which should be enough?)

I have no reason to believe that the hardware supplied is not according to spec, but as I indicated in my first post, I'm hesitant to delve inside the box in case this causes problems in relation to the warranty.

just18:

The error listed in my original post occurred immediately after selecting the main GRUB entry for PCLinuxOS, but the actual initial error message is not consistent across subsequent repeats, and sometimes (for example after I hit <ESC> to get out of memtest) a re-boot doesn't go anywhere, but the monitor remains totally black with no activity from the PC.

Can you see anything wrong with my present assumption that the problem is with the RAM?

[Old-Polack]

Thanks for the replies so far.

pmpatrick:  Starting the PC from the hard disk (i.e. no live linux disk in the DVD drive) and running memtest from the grub menu gave a rapidly scrolling list of entries in the lower part of the screen, on a bright red background.  This was accompanied by a mounting tally of errors in the top part of the screen, running into the tens of thousands (before I hit <ESC> to go back into the booting process).  So it looks to me as though the problem lies with the RAM  -- is that a fair assumption, or am I over-simplifying? 

The build spec of the PC is:

RAM:  2x4GB Corsair PC12800 1600 MHz DDR3. 
PSU:  Quiet Xilence 600W  (which should be enough?)

I have no reason to believe that the hardware supplied is not according to spec, but as I indicated in my first post, I'm hesitant to delve inside the box in case this causes problems in relation to the warranty.

just18:

The error listed in my original post occurred immediately after selecting the main GRUB entry for PCLinuxOS, but the actual initial error message is not consistent across subsequent repeats, and sometimes (for example after I hit <ESC> to get out of memtest) a re-boot doesn't go anywhere, but the monitor remains totally black with no activity from the PC.

Can you see anything wrong with my present assumption that the problem is with the RAM?

Pretty safe bet there. Try testing each stick separately, being sure to seat each solidly, ie, remove, then reinsert, first one then the other, but only one installed for each test. That way you know if only one needs replacing, or both, or if they just weren't installed properly at the factory. If both show no errors when tested singly, re install both, being sure each is fully seated and locked, and test again.

[peter_pclos]

Thanks for that reassurance, Old Polack.

I've subsequently done a little Googling and find a number of results reporting problems, either with the specific Corsair RAM units I have, or with DDR3 RAM more generally, so it looks as though there may well be an issue there. 

As I've said, the PC was built by a specialist company, rather than being self-built.   The component choices were all within the range of options the builders offered for the type of build I selected, so if it's a RAM failure I feel that it's their problem to sort out under warranty.  However, as I've also said, they don't have in-house Linux expertise, so I need to safeguard against a response along the lines of 'well, it's probably something to do with Linux', and would be very interested to know if you think that anything in my use of q4wine or the live DVD of the TOR-based Tails Linux, as described in my initial post in this thread, is likely to have caused the sort of catastrophe to the RAM which the memtest results seem to indicate.  I wouldn't have thought so, because Wine was downloaded from the pclos repositories and the Tails Linux live disk ran perfectly normally (if a little slowly, but that was not unexpected because of the TOR re-routing).

As before, all help and advice gratefully appreciated.

[Old-Polack]

Thanks for that reassurance, Old Polack.

I've subsequently done a little Googling and find a number of results reporting problems, either with the specific Corsair RAM units I have, or with DDR3 RAM more generally, so it looks as though there may well be an issue there. 

As I've said, the PC was built by a specialist company, rather than being self-built.   The component choices were all within the range of options the builders offered for the type of build I selected, so if it's a RAM failure I feel that it's their problem to sort out under warranty.  However, as I've also said, they don't have in-house Linux expertise, so I need to safeguard against a response along the lines of 'well, it's probably something to do with Linux', and would be very interested to know if you think that anything in my use of q4wine or the live DVD of the TOR-based Tails Linux, as described in my initial post in this thread, is likely to have caused the sort of catastrophe to the RAM which the memtest results seem to indicate.  I wouldn't have thought so, because Wine was downloaded from the pclos repositories and the Tails Linux live disk ran perfectly normally (if a little slowly, but that was not unexpected because of the TOR re-routing).

As before, all help and advice gratefully appreciated.

I build all my own computers so the warrantee buck stops here, in my case. Your hardware fails on its own, because of manufacturing defects or improper installation, not because of the OS or applications it runs. Loose connections can make good hardware appear bad, which is why I emphasize making sure the RAM sticks are removed first, then reseated and fully locked in place. If the contacts are properly made, and the RAM still shows errors, it's time to request replacements. I doubt that any reputable custom builder would try to pull the "wrong OS is causing the problem" trick. Most quality RAM these days comes with a lifetime warrantee, so it costs the builder nothing to replace any that shows defects. It will be replaced for free from his own parts supplier.

[djohnston]

As far as whether or not running Linux could have caused a RAM failure, that's a definite NO. Don't let anyone convince you otherwise.

[wedgetail]

What about using a standalone Memtest86+ which as I understand anybody can run independent of installed OS. I was actually thinking of the old DOS version I knew many years ago. The one on this website I am not sure what starts it.

From pmpatric post:
http://www.memtest.org/

A little bit more detail somewhere on that site
http://www.memtest86.com/#philo

....................
Since Memtest86 is a standalone program it does not require any operating system support for execution. It can be used with any PC regardless of what operating system, if any, is installed. The test image may be loaded from a floppy disk, CD or USB drive. Any Unix, Windows or DOS system may be used to create a boot floppy or bootable CD-ROM.

Yep, that looks good to me.  Would be hard for anybody to argue against OS causing trouble if this testing programs shows up problems.  If you use a copy from here as 'evidence' you do not need to mention pclinuxos. (The one one pclinuxos uses I assume is the same anyway)

(I am just testing a new KDE install [success too] when I happened on the topic)  

[djohnston]

wedgetail,

If you install memtest86 from the repository, a GRUB boot menu entry will be added which looks like this:

title memtest-4.20
kernel (hd0,1)/memtest-4.20 BOOT_IMAGE=memtest-4.20

[wedgetail]

djohnston
Ah, that is why I saw one of my test systems with that boot menu.  My suggestion of the above 'outsider version' was that if I was to tell my supplier I had 'proved' RAM problems by using the memtest+ (volunteer the url  ) and printed test result this would be evidence that neither Win 7 or Linux xyz distro was involved in testing.

Of course the supplier could deny recognition but if so the company would have lost one customer.