OT: Linux challenge

• You sure cannot READ. If the drive is not seen/recognized, that IS NOT POSSIBLE. Idiot.

• You are the one that cannot READ. If the drive is not seen/recognized, that IS NOT POSSIBLE. Idiot.

If some other KNOWN GOOD drive can be "seen by the BIOS", then the PATA interface on the motherboard works.

Boot a FOSS (BSD/Linux) from a working drive, live CD or NetBoot. The driver probe *will* see your "funky" drive -- unless your drive is BROKEN (or you've got it configured incorrectly -- two masters, no master, bad cable, etc.)

I repeat my initial statement, the BSD's don't rely on the BIOS to talk to the drive.

There is hdparm which can be used to read all kinds of information on the condition of the hard drive but if a hard drive senses a very critical failure (like the platters not spinning) it may decide not to respond to the PC.

Umm folks, if you stick something oin a USB port for example, just what do you think recognizes it first and tells the OS it is there ?

Hint ; The Basic Input Output System.

B.I.O.S.

It does not simply disappear when the OS is loaded.

On Sun, 28 Jun 2015 01:44:12 -0700, Robert Baer Gave us:

Hardly.

Apparently not.

MS has nothing to do with anything here.

You don't know what you are doing. SATA IS IDE, dope. And "I" is capitalized, lazy f*ck.

On Sun, 28 Jun 2015 01:54:26 -0700, Robert Baer Gave us:

Sounds to me like your SORRY ass does not know how to notice a failed drive when you encounter one.

Nothing will "bring it up", idiot.

On Sun, 28 Jun 2015 01:59:56 -0700, Robert Baer Gave us:

Forensically speaking... you are a true idiot.

On Sun, 28 Jun 2015 02:00:43 -0700, Robert Baer Gave us:

No.. It indicates your inability to iterate your circumstance and propensity to blame the OS. Operator error in the first degree.

You don't even do backups of anything, do you chump?

The very definition of abysmal, though in your case it is stupidity not ignorance.

On Sun, 28 Jun 2015 02:06:37 -0700, Robert Baer Gave us:

You are ass backwards as usual. If the machine *can* boot from a USB device, NOTHING the BIOS "sees" matters.

On Sun, 28 Jun 2015 06:49:12 -0700 (PDT), snipped-for-privacy@gmail.com Gave us:

Wrong. USB attached drives do NOT get scanned by the motherboard BIOS. They are accessed by the onboard "BIOS" in the USB interface and are seen as "mass storage volumes". No CHS involved at that point. No "BIOS level" reads or writes either.

Nice try though.

snipped-for-privacy@gmail.com schreef op 06/28/2015 om 03:49 PM:

The USB driver of the OS...

Yes it does. Linux never ever used the BIOS to access hardware! The only thing the BIOS does for Linux is load the master boot sector which then loads the bootloader from the hard drive. Windows NT and later also don't depend on the BIOS. The main reason is that the BIOS is old 16 bit code with a legacy dating back to over 30 years.

On Sun, 28 Jun 2015 23:55:32 +0200, "N. Coesel" Gave us:

TADA!

We have a winner!

the USB driver!

N O P E !

yeah, but it does get ignored.

plug a USB3.0 card into a 90's PC and see how much help the BIOS is.

On 29 Jun 2015 07:15:46 GMT, Jasen Betts Gave us:

Show me a "USB 3.0 card" that has even a PCI interface.

A "USB 3.0 device" will fall back and work in a USB 2 (or 1) port.

But a "USB 3.0 card" has to be made on an interface that can handle the data rate.

meh, whatever.

Actually, no. It is *often* done this way, but it's not by any means necessary for drives to be used on Linux.

On one my systems, the only device which is recognized by the system BIOS is the (small) IDE flash disk that the system boots from. The two SATA drives are plugged into an add-on SATA controller card which has its own BIOS... and I have specifically disabled that BIOS. The BIOS-level drive enumeration process never "sees" these drives at all.

Once Linux boots from the flash disk, the Linux kernel goes through its own controller and drive-enumeration process. This doesn't depend on the BIOS on the motherboard *or* the SATA controller card. The Linux drivers recognize the SATA card's SATA chip based on the PCI ID, and send commands directly to the chip hardware. The Linux driver and kernel enumerate the SATA bus structure via direct access to the hardware, "see" the drive, and use LBA mapping of the drive "automagically".

I've done similar tricks with SCSI drives, using SCSI controllers that have no on-board BIOS at all (and on systems where the motherboard BIOS doesn't recognize the SCSI controller). The boot-time BIOS scan simply has no idea at all that the drives are present... but once Linux boots (from a different drive) the drives are correctly identified and work just fine.

Now... if the host BIOS (and/or the BIOS on a plug-in controller card) don't "see" the drive, and if the Linux kernel doesn't "see" the drive when it re-enumerates the bus by accessing the controller hardware directly... then it's a pretty good indication that the drive or cable is bad. Linux, Windows, *BSD, whatever, is irrelevant at this point... if the host hardware can't see the drive well enough to identify it, then the host operating system isn't going to be able to use it.

No. I can erase the portions of the BIOS "ROM" that deal with disk geometries, etc. and *still* run an OS on that PC that *can* access the disk correctly.

To prove this, build a kernel with the associated disk drivers elided. I.e., the BIOS will be present in the "PC" but not in the OS. The OS will NOT be able to use the drive -- even though the BIOS "recognizes" it!

Similarly, netboot a kernel after setting the BIOS to "NONE" for each of every disk in the machine. The kernel will gladly start talking to the drives even though the BIOS has been told they "don't exist".

The *only* time the BIOS is important to a disk is for booting from that disk (it is required to locate the MBR and initial "loader" code from the medium) AND *ancient* OS's. I don't even think MS requires in on their OS's nowadays!

If you can't read your disk, you've got a bad disk.

Drag out a copy of DEBUG and talk to the controller directly. See what

Netboot the machine; the BIOS wouldn't even be required for the "(small) IDE flash disk"

Yes. I.e., using a "PC/x86" SCSI HBA on a *SPARC* system! I.e., the "code" in any "BIOS ROM" is absolute jibberish on a SPARC!

Exactly. Said another way, if a KNOWN GOOD drive works with the exact same controller, cable, etc. then a drive that does NOT has a problem with it's interface (broken pin, blown electronics, spindle motor, configuration error, etc.)

There are machines that don't even have the equivalent of the PC BIOS. My rPi will talk to drives and I'm pretty sure it doesn't see the drive in any way until after it boots.