Hardware config for SpinRite to recognize drives above 2.2GB

[brado2049]

I’ve been a licensed user of SpinRite since v6.0. The reason I acquired it was primarily to address 3TB and 4TB SATA drives used in my direct-attached and NAS drive arrays. My bad on v6.0, there were drive size limitations. But with v6.1, I have never been able to get SpinRite to recognize a drive above the 2.2GB limit, it seems no matter what I’ve tried.

I can get FreeDOS to boot and SpinRite to run, as I have tried on several different machines with CSM BIOS support and able to boot off USB. I have tried directly attaching to the motherboard on a desktop, and also connecting SATA drives externally via USB. I have bought and tried 6-7 different adapters and hard drive cradles which purport to support larger hard drive geometry. All show my drives at 2.2TB, even though if I boot into Windows they all show 4TB.

I’ve tried everything I know to do, with desktops, laptops, different external hard drive cradles and SATA adapters, and I have never been able to use SpinRite on my hard drives, as they are all above this 2.2TB limit, and no combination I’ve tried will do it in SpinRite, even though the hardware and normal OS detects it fine. It seems that we are being progressively caught in a bit of tech-evolution no-man’s land with an awesome tool (SpinRite) which is pinned to legacy BIOS and legacy OS and hardware to run it, but trying to address current hard drive geometry. I understand why, and the eventual best solution will arrive in v7.0. But for now, I’d like to figure out a solution, and so I am requesting help, which might take one of the following forms (or all):

- If there is something simple I have somehow missed in process or configuration, let me know. I am always a fan of the “I’m an idiot” solution — it resolves things quickly!
- Unless this has been published somewhere and I’ve missed it (and if so, so have all the public AI models — we need to get those trained), what we need is a published machine spec for running SpinRite v6.1 so that it boots to SpinRite and recognizes large hard drive geometry properly. I’m not talking about just a list of standards that needs to be supported, I’m talking about specific brand and model of either laptop or motherboard, any required components, and specific configuration required on that build — a “SpinRite Utility System” you might say. If I can get that, I’ll buy the components and build it. No more weeks and months of testing or acquiring old or new hardware uncertain that it will do the job. This would solve the problem for me, and I imagine many others, until SpinRite v7.0 emerges.
- Some other option I am not aware of.

I anyone can give me a hand / point me in the right direction, I'd greatly appreciate it. I've owned SpinRite for years but have never been able to use it on a whole box of SATA drives for my drive arrays. Thanks so much for your help!

Brad

 

[PHolder]

The issue you're encountering is that the machines you've tried are likely all old enough to not have a modern BIOS that is capable of 48-bit LBA addressing. All older machines only did 32-bit LBA addressing and 2^32 x 512 bytes = 2,199,023,255,552 bytes (which is your 2.2TB limit.) For completeness, 2^48 x 512 bytes = 144,115,188,075,855,872 bytes, or 144,115 TBs. I have newer AMD machines that are able to Legacy Boot, but also support 48 bit LBAs and I have successfully used 3TB drives with SpinRite during development testing of version 6.1.

48bit LBA addressing was "invented" around 2003. Perhaps you could supply information about the machines you've tried (including BIOS supplier and version) and someone else here will know info about them and can confirm what I've suggested.

Another possibility is that DOS is picking up on the NAS specific format of the drives, and the NAS is using MBR which is also limited to 32 bit LBA addressing. GPT (GUID Partition Table) supports 64-bit LBAs. If you can blank one of the drives, then you could put a GPT partition on it and see if anything changes.

 

[brado2049]

The issue you're encountering is that the machines you've tried are likely all old enough to not have a modern BIOS that is capable of 48-bit LBA addressing. All older machines only did 32-bit LBA addressing and 2^32 x 512 bytes = 2,199,023,255,552 bytes (which is your 2.2TB limit.) For completeness, 2^48 x 512 bytes = 144,115,188,075,855,872 bytes, or 144,115 TBs. I have newer AMD machines that are able to Legacy Boot, but also support 48 bit LBAs and I have successfully used 3TB drives with SpinRite during development testing of version 6.1.

Perhaps you could supply information about the machines you've tried (including BIOS supplier and version) and someone else here will know info about them and can confirm what I've suggested.

Thanks for the reply. I’ve tested a few semi-recent Lenovo laptops (2018, 2019) which had no problems CSM booting and running SpinRite but couldn’t recognize drive size about 2.2TB. It sounds like you’ve gotten past it. What I want to do is stop randomly testing hardware, and build a small rig with hardware that is known to work. Do you (or does anyone) know a hardware configuration I could buy off of Amazon right now (either pre-built or I’ll assemble it) which is known to work? How about Raspberry Pi -type stuff — anything in the mini / micro computer / board config which might work?

Thanks in advance!
Brad

 

[PHolder]

Okay, well if your machines are that new, then I guess it must be your drive. It appears you replied while I was still editing my reply above, so give the final version another reading and see if you're willing to make a test of repartitioning the drive.

Once we know if that's the catch, you might decide to try using the ZimaBoard that Steve himself actually used for his development. There is more details around it elsewhere on this site, including a recommendation for a more powerful power supply to power spinning drives. One word of warning, it appears that there is a newer model (ZimaBoard 2) that is as yet unknown if it supports Legacy Booting. I have a support query into them, but have not heard back yet. It appears supply of the original might be dwindling, as they might be intending to replace it with the new one.

 

[brado2049]

I’ll try to repartition the drive, and I’ll post the results back here. Thanks so much for your help. Stay tuned…

 

[ColbyBouma]

How did you create your SpinRite 6.1 boot drive? I don't think it should matter as long as it's DOS or FreeDOS, but something isn't quite right in your setup. 6.1 absolutely supports drives larger than 2.2 TB, it's one of the main reasons Steve created 6.1.
Would you be willing to share your log files? They are in the SRLOGS folder on your SpinRite boot drive. I recommend putting them in a ZIP file before uploading them here.

 

[peterblaise]

Mount each drive internally as SATA, one at a
time, as the only drive in a computer, boot
from a FreeDOS USB, with no CONFIG.SYS if
necessary ( or ONLY BUFFERS=98 ), and try:

SPINRITE NORAMTEST SKIPVERIFY

Also, @Paul F created and kindly 'donated' a
utility that empowers SpinRite 6.1 to run on
MS-DOS, so if FreeDOS still does not pass
access to the full drive, let us know and we'll
help you try MS-DOS and SpinRite 6.1.

 

[DanR]

I can get FreeDOS to boot and SpinRite to run, as I have tried on several different machines with CSM BIOS support and able to boot off USB. I have tried directly attaching to the motherboard on a desktop, and also connecting SATA drives externally via USB. I have bought and tried 6-7 different adapters and hard drive cradles which purport to support larger hard drive geometry. All show my drives at 2.2TB, even though if I boot into Windows they all show 4TB.

Some general information . . .

Any external drive, be it USB, ESATA, any cradle/adapter will be accessible ONLY thru the BIOS and hence subject to BIOS limitations, including 2.2 TB capacity.

SpinRite 6.1 is not hardware NAS compatible.

Drives connected internally to the motherboard should be accessible via SpinRite 6.1's native drivers and thus not subject to any BIOS limitations.

What do you see on the "System's Mass Storage Devices Discovered" screen for internally connected drives? Specifically in the Type column???
For a drive connected directly to a SATA controller on the motherboard, the Type column should show AHCI or ATA or IDE.
IF all you see in the Type column is BIOS then (a) the drives may not be connected properly or (b) a BIOS setting may be overriding and forcing BIOS access.

Last but not least . . . when SpinRite 6.1 is able to use its native drivers to access an internal drive then partitioning is totally irrelevant and BIOS limitations do NOT apply.

Hope something here helps . . .

 

[peterblaise]

@DanR wrote "... SpinRite 6.1 ... access an internal drive ... partitioning ​

is totally irrelevant ..."​

Maybe unrelated, but, depending on the contents of track 0, especially
being blank or unpartitioned, and having run System RAM Test, SpinRite
6.1 Release 4 may show a 'ghost', a second copy of a drive that is
inaccessible, see
https://gitlab.grc.com/Steve/spinrite-v6.1/-/issues/686 if and when
@Steve brings the SpinRite 6.1 development archive back online:

No problem, just access the first instance of that drive, or run:

SPINRITE NORAMTEST

@Steve promises an eventual Release 5 to address that and any other
subsequent discoveries and quirks we may find.

 

[brado2049]

Thank you everyone for all your responses. You’ve given me a couple things to try.

• Because the current hardware I have are laptops (two Lenovo and a Razer), all which can boot CSM / SpinRite but cannot see above the 2.2TB limit, I think I have been running into the MBR limit, so GPT partitioning is the first thing to try.
• I’d like to have an optimal rig which avoids the issues with USB cradles — direct-connect SATA and native SpinRite drivers (which I never understood before). I have heard Steve mention the Zima boards several times over the last year on podcast episodes, and one of you mentioned it above, but I wasn’t completely sure of the use-case. Is my situation a proper use case for the Zima hardware? If this *is* the use-case, if anyone can link to a good resource on this forum for Zima hardware / configuration (I’ll search myself too, but I don’t want to inadvertently miss the good posts).

If / when I get things to a happy place — especially if I can build a tiny / compact rig for this, I’ll post the details here.

Final note — I’m a career software developer / security guy that’s done some OS filesystem / driver development in the past — kind of makes me wonder if it might be worth developing a virtualization layer for SpinRite — it would be really cool if (just using this as a use-case example disregard the specific Docker reference) you could just gun up SpinRite using something like Docker on any newer hardware and it would run bypasing lower-level hardware issues. Hmmm…..

 

[ColbyBouma]

I think I have been running into the MBR limit

SpinRite 6.1 doesn't care about MBR vs GPT. Please post your log files.

 

[peterblaise]

Are you attaching the drive INTERNALLY as SATA to the laptop, even
with adapter cables if the drive is 3 1/2" and the internal bay is 2 1/2"?

Or are you attaching the drive via a USB-to-SATA adapter?

A USB adapter will be subject to the CMOS BIOS restrictions, and
USB was a mess of non-standard misbehavior.

Hence the call to install the drive internally as SATA - and have it be
the ONLY drive, in order to simplify things,

- - - - -

Regarding 'bring your own OS and drivers' to bypass CMOS BIOS, see:

https://forums.grc.com/threads/how-to-run-spinrite-on-a-uefi-only-machine-part-1-of-5.1613/

... and equivalent 'spinrite vm virtual machine' search results at forums.grc.com

... and:

https://www.grc.com/x/news.exe?cmd=article&group=grc.spinrite.dev&item=56492&utag=

Subject: Re: CSMWrap - Boot Legacy from a UEFI machine​

Date: Mon, 23 Jun 2025 21:19:16 +0200​

From: millQ <myf@kemail.com>​

solved..​

The trick was to compile the CPU VGA rom module from Intel(easy to ​

extract in Linux) into the CSMWrap SeaBIOS(in my case I tested a ​

pre-compiled file for Haswell)​

I got Spinrite running in UEFI mode on real hardware!(CMS is totally ​

disabled) ​

...and as you can see the speed on my 128GB nvme drive is now 300 MB/S ​

instead of 60MB/S (using normal CMS module in DOS).​

The next step is to see if I can get my HP laptop (uses sandy bridge) ​

working using CSMWrap(then it will bypass the HP's USB BIOS bug, ​

(SeaBIOS does not have it))​

That's a 128GB nVME under SpinRite 6.1.

=8^o

 

[jlee]

Final note — I’m a career software developer / security guy that’s done some OS filesystem / driver development in the past — kind of makes me wonder if it might be worth developing a virtualization layer for SpinRite — it would be really cool if (just using this as a use-case example disregard the specific Docker reference) you could just gun up SpinRite using something like Docker on any newer hardware and it would run bypasing lower-level hardware issues. Hmmm…..

Peter gave a link to what is essentially a virtualization layer using a full-blown VM. I don't know if something like Docker will work with code that's running in 16-bit real mode and uses the BIOS, which SpinRite 6.1 still does. Right now Steve has no plans to further develop the 16-bit real mode SpinRite. His goal with SpinRite 7 is to move the code to Win32 which will run under Windows as well as a separate embedded OS that supports Win32 that he has purchased the rights to.

 

[brado2049]

Wow -- thanks everyone for the great responses! Forgive the slight delay in response, I'm so delighted at the knowledge and help, I wanted to make sure to have good information to provide in a reply. I was in the middle of an office move, and had some of my gear packed, so I had to set it up again. Ok, hopefully I'll have the info needed to completely diagnose this issue in this post, but if there's anything missing, I'll be happy to get it with your guidance. So without further qualification, here we go with my setup:

• Lenovo ThinkPad laptop, Model 20QQS6CN00. Product page / manual - https://pcsupport.lenovo.com/us/en/...-20qn-20qq/20qq/20qqs6cn00/document-userguide
• BIOS version/date: LENOVO N2NET61W (1.46 ), 7/23/2024
• USB dock: StarTech.com Standalone Hard Drive Duplicator, External Dual Bay HDD/SSD Cloner/Copier, USB to SATA III Docking Station - https://www.amazon.com/dp/B019Y4JE22?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_1&th=1
• Hard drive: Toshiba MDO4ACA400 4TB

As requested, I have attached my SpinRite logs from a past run, in which you can see that the 4TB drive is only being recognized as 2.2TB. I have also attached a screenshot of this drive in Windows Disk Management which shows the drive being recognized properly.

Ok....SpinRite superheros unite! I'm ready to follow whatever guidance you have, anything I need to try, etc. Thank you so much for your help so far, and any help you give from this point forward. It is greatly appreciated!

NOTE: this is the hardware I have accessible at the moment, so I'd love to get this working properly with this computer if possible.

 

[ColbyBouma]

As requested, I have attached my SpinRite logs from a past run

Thank you! Do you have any logs from when you tried connecting this drive to a desktop via a SATA port?

I have also attached a screenshot

Unfortunately, that didn't come through. This forum has a hidden size limit of 500 kB, so you'll have to resize the image.

You're running into a 2.2 TB limit on your laptop because SpinRite only knows how to access USB drives through the BIOS. Windows has its own USB drivers, so it's able to access the full size of the drive. I think the only way you're going to get SpinRite to see the full size is to use SATA. A few options include:

• Borrow an old desktop from a friend. 6th-generation Intel and older (or AMD equivalent) work best. SpinRite does not need a powerful CPU.
• Buy an old desktop from a thrift store, eBay, FB Marketplace, etc.
• Buy a Zimaboard, if they're still available. https://shop.zimaspace.com/collections/zima-products-family/products/zimaboard-single-board-server
• Buy an adapter for your laptop, such as the one that Peter mentioned, or something like this (plus an external power supply): https://www.amazon.com/Adapter-SATA3-0-NO-Riad-Desktop-Support/dp/B0B5RJHYFD

 

[brado2049]

@ColbyBouma, thanks for the reply. Responses:

Do you have any logs from when you tried connecting this drive to a desktop via a SATA port?

Unfortunately, not at the moment.

Quick clarification:

You're running into a 2.2 TB limit on your laptop because SpinRite only knows how to access USB drives through the BIOS.

I was under the impression that there was a way for SpinRite to work with drives connected via USB. Can it be said definitively that the only way SpinRite will recognize drives above the 2.2TB limit is with direct SATA connection to the motherboard, and connecting via USB will not work in any configuration?

Buy a Zimaboard, if they're still available.

Do you (or anyone) happen to know if the Zimaboard2 supports CSM / legacy booting? I think those are still available...

I tried attaching that screenshot again, hopefully it took this time. Thx again for your help.

 

[DanR]

Quick clarification:
I was under the impression that there was a way for SpinRite to work with drives connected via USB.

In most cases, Nope. Please see https://forums.grc.com/threads/usb-support-in-spinrite-6-1.1479/ for more information.

SpinRite 6.1 (like its venerable predecessor SpinRite 6.0) can only access external drives (USB, etc.) via the BIOS, subject to all the limitations of the BIOS.

Can it be said definitively that the only way SpinRite will recognize drives above the 2.2TB limit is with direct SATA connection to the motherboard, and connecting via USB will not work in any configuration?

In almost all cases: Yes The rare exception would be a system with a more modern BIOS that can address space beyond the 2.2 TB limit.

With a direct connection to a SATA controller on the motherboard, SpinRite 6.1 will be able to use its native drivers, thus eliminating the BIOS and its limitations entirely.

Regarding the screenshot: SpinRite 6.1 is partition agnostic. SR 6.1 will treat a drive (0, 1, or 2) as a single raw data drive entity when using it's native drivers.
The BIOS, however, would see each partition as an individual BIOS drive entity.

 

[brado2049]

Happy Saturday! I chased down a little further, reading various doc and a little ChatGPT research help. Forgive me if I may be repeating certain things some of you have said above in this conversation. Some of my research has been to understand that, and also to reconcile it with what I'm seeing. Here are some things I have dug up:

*** The 2.2 TB Limit on legacy BIOS

• The legacy BIOS boot process uses the Master Boot Record (MBR) partitioning scheme.
• MBR uses a 32-bit field to store the maximum number of sectors.
• Assuming 512-byte sectors:
  • Max sectors = 2^32 = 4,294,967,296
  • Max size = 4,294,967,296 × 512 bytes ≈ 2.2 TB
• So with MBR, legacy BIOS cannot boot from partitions that extend beyond this size because it cannot address beyond the 2^32 sector boundary.

*** How disks >2.2 TB are recognized on legacy BIOS systems

As data disks (not boot disks)

• The OS can use disks larger than 2.2 TB for data only by initializing them as GPT (GUID Partition Table).
• The BIOS doesn’t interact with GPT directly — the OS’s drivers do once loaded.
• So you can attach a 4 TB drive on an old BIOS machine, format it GPT, and it will work as a non-boot data drive in Windows, Linux, etc.

Using 4K native sectors

• Some drives (like Western Digital’s Advanced Format 4Kn disks) use 4096-byte native sectors.
• This effectively allows the 32-bit sector field to address up to:
  • 2^32 × 4096 bytes = 16 TiB
• However, these drives must be paired with BIOS or OS drivers that support 4K native. Many legacy BIOS implementations still fail here.

Ok so I have gone the route of #1 above -- I have a USB thumb drive that is a SpinRite boot drive created with the SpinRite utility for doing so. It boots legacy BIOS just fine, and I can run SpinRIte. I also have a hard drive initialized as GPT, which in Windows is recognized as its full 4TB capacity, which verifies another aspect of the setup, which I also researched separately, which is that my StarTech USB cradle's USB-SATA bridge inside supports 48-bit LBA, so it can see up to 6TB of disk space (my drive is only 4TB).

According to all the research I've done, and whatever pseudo-reasoning AI can stumble through, my configuration should work. Here is the conclusion statement from the ChatGPT research I did:

*** Will it [my configuration] work?
Yes.

• Legacy BIOS only cares about the drive you’re booting from (your small USB drive).
• Your OS (Windows, Linux, etc) handles GPT for data disks just fine.
• So your 4TB drive, even connected by USB, will be fully accessible with a GPT partition table.

That brings me back to the question of why this isn't working -- and bear with me, I'm just trying to understand why, because solutions stand on the shoulders of understanding the why of things. I read the forum thread just posted above:

In most cases, Nope. Please see https://forums.grc.com/threads/usb-support-in-spinrite-6-1.1479/ for more information.

That talks a lot about BIOS, but according to the research I did (and I probably am just not fully understanding it), the BIOS primarily governs the boot drive, not the data drive. As a result, I didn't fully understand the referenced post, and in particular this statement:

Accessible BIOS drives will typically be limited to just the first 2.2 TB of capacity, with the exception of the rare BIOS that is able to access additional capacity.

...my research seemed to indicate that It is not the BIOS, but the OS support for GPT that determines whether the full capacity of a non-boot data drive is accessible. So I guess that is the clarification I am asking now -- is the problem ultimately one that SpinRite does not fully support GPT?

Again, forgive me -- despite having worked on OS file systems in the past, I'm not the expert on these specific driver issues. I'm just trying to understand very specifically what is causing the problem. It might lead to other ideas for solutions, and likewise, rule out trying things that would not work, saving time. Likewise, knowing the specific problem will help answer the next obvious question of why direct-connect SATA would work while USB-SATA bridge would not in this case, which I would like to understand before dropping $300 on a ZimaBoard2 -- which I'll do when I understand why that works and this does not. I think I'm close, but there's still a missing piece of the puzzle in the explanation. Thanks again so much for your help and guidance.

 

[DanR]

...my research seemed to indicate that It is the OS support for GPT that determines whether the full capacity of the drive is accessible. So I guess that is the clarification I am asking now -- is the problem ultimately one that SpinRite does not fully support GPT?

Both SpinRite 6.0 and 6.1 are:
- OS agnostic
- File system agnostic

SpinRite 6.1 is also:
- Partition agnostic (Thus SpinRite 6.1 does NOT care about GPT)

SpinRite 6.0 is, however, partition aware, but is not NOT compatible with GPT partitioning.

If SpinRite 6.1 can use it's native (built in) drivers to access an internal drive connected to a controller on the motherboard, then the above applies to SpinRite 6.1. SpinRite 6.1 then will have NO limitations re OS, file system, data, partitioning, drive capacity - all will be completely irrelevant to SpinRite 6.1

However, if SpinRite 6.1 must use the BIOS to access a drive, then BIOS limitations (including capacity) will apply. But each BIOS drive will simply be a single raw data entity with OS, file system, data, partitioning all irrelevant to SpinRite 6.1.

 

[peterblaise]

@DanR wrote "... SpinRite 6.0 [ is ] OS agnostic ..."​

ONLY via the FORCE command line option:

SPINRITE FORCE

Otherwise, SpinRite 6.0 will try to recognize drive
data operating system contents, and update them
with anything newly found regarding bad sectors.

- - - - -

SpinRite 6.1 is contents agnostic, EXCEPT for
unpartioned drives, where they may show up as
a second ghost drive after running the System
RAM Test. It's not a danger, just confusing.
Solution: the NORAMTEST command line option:

SPINRITE NORAMTEST