[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mandriva 2009 (spring) failure to boot

From: Bob Proulx
Subject: Re: Mandriva 2009 (spring) failure to boot
Date: Sat, 21 Nov 2009 22:08:29 -0700
User-agent: Mutt/1.5.18 (2008-05-17)

Loron Woods wrote:
> Mandriva Version: Updated Mandriva 2009 Spring
> I don't know whether this is a bug, my harddrive, or what the problem is
> as I'm a novice in Linux.

It reads to me that you are having a hardware problem with your
machine.  The symptoms could match a number of different hardware
problems such as failed ram, failed motherboard, failed cpu.  This
reads to me as most likely to be failed ram but that is only a wild

Unfortunately you have reach the GNU Coreutils mailing list.  The GNU
Coreutils are the basic file, shell and text manipulation utilities of
the GNU Operating System.  You can learn more about GNU Coreutils


The GNU Coreutils are part of the GNU Operating System.  You can learn
more about the GNU Project here:


But you are asking about a Mandriva problem.  Actually I think you are
having a hardware failure.  But we are not a hardware nor Mandriva
support forum and the discussion is off topic here in the GNU
Coreutils mailing list.  Since you are using Mandriva a better place
to get software help on your distribution would be your distribution
mailing lists.


However even though this is off topic for this mailing list I can't
resist suggesting a few things for you to try anyway.

The first thing I would do is to examine your system log and look for
any errors.  Hopefully something will be logged there.  This file is
usually /var/log/syslog or /var/log/messages or some other similarly
named file in /var/log.

The next thing I would do is to run 'smartctl' on the disk drive and
check if the drive is logging any errors.  Run both short and long
self tests and see if the drive is failing.

  sudo smartctl -H /dev/sda
  sudo smartctl --log=error /dev/sda
  sudo smartctl -t short /dev/sda
  sudo smartctl --log=selftest /dev/sda

The next thing I would try would be to run a memory test on the
machine.  I use memtest86+.  Your problem really reads as if there is
a failed RAM chip.  RAM failures can be frustratingly difficult to
debug because they tend to be intermittent.  Hopefully running
memtest86+ overnight will identify a ram problem.  If so then this is
easily corrected by replacing the bad ram.  I am always filled with
joy when a flakey system has an identifiable bad ram because that
marks the end of the frustrating flakeyness.

  http://www.memtest.org/  memtest86+ site
  http://en.wikipedia.org/wiki/Memtest86  wikipedia article

The next thing I would do would be to download a KNOPPIX live cdrom
image and test the system using it.  This would avoid your hard drive
and eliminate it from the problem.  It is a generally useful thing to
have available as well.


The next thing I would do would be to unplug every connector on the
system and then assemble it with just the bare minimum of components.
If you are lucky the problem is a peripheral that could simply be
replaced.  Sometimes just the act of disassembly and reassembly can
cure the problem because it may be that a connection has oxidized and
needs to be scrubbed.  However you said that you were a novice and may
not feel comfortable debugging the hardware.  Perhaps you have a
friend who is more hardware knowledgeable who could help you?

By the way...  The fsck issues you are experiencing are due to the
crash of the host system leaving the filesystem in an unclean state.
Upon boot it detects this and cleans up.  This isn't the root cause of
the problem but just a symptom cascading from the crash.  It is a
normal result and recovery after having had a system crash.  Some
systems allow you to specify the 'fsck -f' option automatically at
boot time.  This will avoid it asking you to fix each inconsistency
manually.  Specifying -f automatically is a controversial topic and
different people believe the default should be different values.

Good luck!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]