Very large disk on Very old BIOS

[Pilotman23]

I am seeing the following error when trying to scan some 6, 8 and 10TB WesternDigital disks that I have "shucked" from USB enclosures being scanned from a Dell PowerEdge R515

"Invalid BIOS Access
Although this systems BIOS lists this drive as available it failed SpinRite's validation attempts. This can occur when a very large drive is attached to a machine with a very old BIOS. Therefore, SpinRite will be unable to work with this drive on this machine. To use SpinRite with this drive, please try with another computer."

I was able to use this system with ShredOS USB key and wipe each of these disks, why can't SpinRite scan each sector if each sector and be wiped with ShredOS?

 

[ColbyBouma]

What does SpinRite show in the Type field for the drives? You can find that field in the table at the top of each log file (SRLOGS folder on your SpinRite boot drive). SpinRite works best when the Type is AHCI or ATA. If they're showing as BIOS, then you may be able to change the settings of your storage controller in the BIOS. If not, then you'll have to scan these drives from a different computer.

 

[peterblaise]

My guess is that your case as presented is edge enough
for programmer Steve Gibson to consider it NOT the
target for SpinRite 6.1, but perhaps included in any
upcoming SpinRite 7+, or ignored altogether
considering the ready availability of alternative
computer chassis that do NOT present the challenge
you observed.

That being said, ShredOS appears to be a small Linux
distribution designed for secure data erasure, and
includes its own SATA drivers, but it's important to note
that it's a minimal system that is focused on that
specific task, built for securely wiping the contents of
hard drives and SSDs using the nwipe program ( and
. . . ShredOS creates a virtual disk in memory that
contains drivers and software, requiring a minimum
of 2GB of memory, but that probably does not matter )
<-- this is general research, NOT my personal experience.

SpinRite is dependent on a computer system's BIOS and
FreeDOS, but includes it's own drivers for many IDE, ATA,
and AHCI drives, otherwise, it depends on the BIOS to
communicate with any attached drives, we can try each
driver by a variety of means:

changing the drive attachment setting in the CMOS​

BIOS - IDE, ATA, AHCI, RAID, and any available​

options within each available choice​

​

running SpinRite 6.1 with the command line option​

FORCEBIOS to turn off SpinRite's own IDE, ATA, or​

AHCI drivers and use BIOS access only:​

​

SPINRITE NORAMTEST FORCEBIOS SKIPVERIFY​

​

Yeah, the SKIPVERIFY command line option may allow​

recovery and maintenance in spite of incompatibility​

in any initial enumeration and verification.​

NORAMTEST just keeps the SpinRite session clean and​

single-purpose.​

But if the drives are ONLY presented with BIOS access,
then there is no way to 'turn on' SpinRite 6.1's IDE, ATA,
or AHCI drivers.

So, maybe Steve Gibson can cobble together a 'patch'
for an upcoming SpinRite 6.1 Release 5 or later of
SpinRite 6.1 Release version - it's not impossible, it just
that as far as I can remember, this situation was not
presented during development, hence the need for
exhaustive participation from all of us end users with
all our ersatz gear.

Tell us more, and let us know what you do.

 

[peterblaise]

Update to the current SpinRite 6.1 Release 4, see

https://www.grc.com/upgrade.htm

And update the Dell BIOS,
and use new and or different SATA cables,
and move around the different SATA sockets,
and attach only one drive at a time for each test,
and clean the internal contacts between the drive card
and the drive ( yeah, all three might be grungy ).

Try MS-DOS instead of FreeDOS, but that would require
running @Paul F's clever SETOEMFD.COM 'patch' to
convince SpinRite 6.1 that it's really on FreeDOS - is
that still available by any means?

 

[PHolder]

why can't SpinRite scan each sector if each sector and be wiped with ShredOS?

BIOS is not an operating system, and doesn't have extensible drivers. I don't know ShredOS, but it's called "OS" so I presume it does have loadable drivers, and someone has supplied them into it for talking to the hardware in a way your BIOS does not. (Windows and Linux, as two examples, do NOT use the BIOS any more for anything once they boot... which is how they can continue to evolve while your BIOS generally does not.)

SpinRite 6.1 added some of it's own drivers for some PATA and SATA devices but it is not equivalent to support for everything out there. (Windows and Linux have the benefit of many specialists from many manufactures supplying driver code for all the hardware... and while Steve did his best to get testers to work with his code on a variety of hardware, he did not test anywhere near to the level that OS providers have.)

 

[AlanD]

It appears that there is a fairly recent BIOS update for this machine ( 2018) at https://www.dell.com/support/home/en-uk/drivers/driversdetails?driverid=9kkcd. You could try updating to that as it should be new enough to handle large drives.

 

[Pilotman23]

It appears that there is a fairly recent BIOS update for this machine ( 2018) at https://www.dell.com/support/home/en-uk/drivers/driversdetails?driverid=9kkcd. You could try updating to that as it should be new enough to handle large drives.

@AlanD Yeah that was the 1st thing I tired when the error said "old BIOS", sadly even with the latest firmware update this "very large drive .... very old BIOS" error is still happening.

SpinRite is dependent on a computer system's BIOS and
FreeDOS, but includes it's own drivers for many IDE, ATA,
and AHCI drives, otherwise, it depends on the BIOS to
communicate with any attached drives, we can try each
driver by a variety of means:

changing the drive attachment setting in the CMOS​

BIOS - IDE, ATA, AHCI, RAID, and any available​

options within each available choice​

​

running SpinRite 6.1 with the command line option​

FORCEBIOS to turn off SpinRite's own IDE, ATA, or​

AHCI drivers and use BIOS access only:​

​

SPINRITE NORAMTEST FORCEBIOS SKIPVERIFY​

​

Yeah, the SKIPVERIFY command line option may allow​

recovery and maintenance in spite of incompatibility​

in any initial enumeration and verification.​

NORAMTEST just keeps the SpinRite session clean and​

single-purpose.​

@peterblaise your command worked!

I tried the command removing the 'SKIPVERIFY' but it produced the same errors, thank you for your assistance!

 

[peterblaise]

BTDTGTTS been there, done that, got the T-shirt!

Glad SOMETHING got you in.

Now, let us know how the drive (mis)behaves!