[conspire] 3rd Master Hard Disk Error

Rick Moen rick at linuxmafia.com
Sun Nov 18 17:16:33 PST 2018


Quoting Paul Zander (paulz at ieee.org):

> I have taken the precaution to make copies of important data on
> different physical drives.

Absolutely the right first step.

> What next?

I don't know what to make of your quoting the BIOS info screen as saying
'3rd Master Hard Disk Error, press F1 to continue', but then also
observing that computers with only 1 drive generate the same message.
That contradiction seems a bit mystifying.

However, one can always fall back on good ol' logic.  I infer from this
machine having three physical hard drives that it's not a laptop, which
is good news because it means you can easily open up the case and do
hardware work.  Now that you've secured backups, you could proceed like
this:

1.  Disconnect your computer from power.  Bring the system unit to
workspace with generous room and decent lighting.  Bring out some
ramekins or small bowls to hold screws.  Unscrew the case cover.
Perhaps with the aid of a flashlight, take a good long look at how the
motherboard and the three drives are connected.

Newer PCs will cross-connect to the motherboard's host bus adapter (HBA)
circuitry using SATA cabling.  Older PCs will instead use PATA ribbon
cabling, popularly but vaguely called 'IDE'.

Typical SATA cable:
https://cs-electronics.com/product/sata-cable-7-pin-sata-connector-both-ends/

Typical PATA cable:
https://commons.wikimedia.org/wiki/File:PATA-cable.jpg

The power connections I'm used to seeing are separate from the data
cables (mentioned above) and use the familiar 4-pin Molex plugs.
However, my understanding is that same SATA drives now have a newfangled
15-pin SATA-specific power attachment, and naturally there are converter
cables, e.g., picture here:
https://www.newegg.com/Product/Product.aspx?Item=N82E16812200061&Description=sata%20power%20cable&cm_re=sata_power_cable-_-12-200-061-_-Product

2.  Maybe you should use a small flashlight to see any labelling on the
motherboard where the data cable from each hard drive connects.  You
might see wording like 'Primary' / 'Secondary' in the case of PATA, or
'SATA1', 'SATA2', etc. in the case of SATA.  Feel encouraged to take
notes about what's connected to what.

The basic scheme for SATA's a lot simpler than for PATA, reflecting
having learned from certain dismal aspects of PATA and happily leaving
them behind.  A SATA connector goes from the HBA circuitry directly to
one (1) physical drive, period.  Each connector w/cable drives (at most)
one SATA device.  By contrast, PATA was designed to let the HBA
connector w/cable drive either one or two PATA physical drives (or, of
course, none).  Thus, most PATA ribbon cables have -three- connectors,
so as to accommodate two drive devices on the 'PATA chain'.  To make
this functionality work and the HBA circuitry be able to communicate
distinctly with the (up to) two remote drive devices, the drives had to
be physically configured to assert either that they were the 'master' or
'slave' device on the chain or were the only device, as appropriate.
This was usually done by setting a jumper on each drive, though
alternatively it could be done using a horror called 'cable select':
https://en.wikipedia.org/wiki/Parallel_ATA#Cable_select

If this is PATA, you'll need to understand the basics of the above,
because the next thing we're going to do is selectively disconnect
drives.  OTOH, if it's SATA, you've lucked out, as then whole areas
of complication go away.

By the way, this would also be an excellent time to visit the BIOS Setup
screens and take down a note or two about whatever it says concerning
the hard drives.  It's incredibly rare in modern motherboards for these
to matter a lot, but it couldn't hurt.  At worst, this is precaution
against burning your bridges.  At best, you might see something worth
pondering and investigating.  (obviously, you'll need system power again
to look there.  When you're done, disconnect the system unit from AC
power, again.)

3.  Now that you've studied your system and taken some notes about the
three drives and their connection, it's time to figure out which one is 
squawking.  Disconnect from the backs of two of the hard drives their
power connectors.  For this purpose, there's no need to disconnect the
data cables.  (Therefore, don't do that, at this time, on KISS grounds.)

Which drive should remain connected to a power feed?  It doesn't much
matter, but one might indulge a small burst of OCD and let it be
whatever's the 'first', drive, which is to say the drive on the SATA1 
connector for SATA, or the 'master' drive on the 'primary' chain for
PATA.

As usual, PATA intoduces a pain-in-the-ass complication, here:  If the
drive still connected to power has been part of a two-drive PATA chain,
then it was probably jumpered for that role (unless cable select was 
employed, which please see).  Thus, you'll probably need to rejumper it
for the single-drive role it's about to assume for testing purposes.
Do so.

No need to close up the case, but you can now reconnect power and go
through Power-On Self-Test (POST) again.  Still see '[something] Hard Disk
Error, press F1 to continue'?  Then, that's your problem drive.  If not,
yank system power and try each of the other two drives as the sole drive
receiving power, the same way, to test them, until you find it.  (It
doesn't matter whether anything can boot, because you're using POST
diagnostics.

And, of course, when you're done, but jumpers and power connectors back.

Also, it really couldn't hurt to gently reconnect and refasten all PATA
or SATA data connectors.  Those coming loose could cause bewildering and
sometimes intermittent problems.


You know, by the way, Linux may have been muttering about read/write
problems in the system log files (usu. /var/log/messages), including
very specfic /dev/sdX citations.  You could look.  Small amount of stuff
about that here:  https://www.suse.com/support/kb/doc/?id=7006510

(SCSI notation is used even for non-SCSI mass storage because all the
relevant drivers now leverage the SCSI layer.  That's why you don't see
/dev/hdX device nodes any more, only /dev/sdX.)






More information about the conspire mailing list