How To: Run SpinRite on a UEFI-only machine (Part 1 of 5)

[Scott]

Introduction​

As has been noted previously, the FreeDOS OS on which SpinRite runs can't boot on a PC with UEFI firmware that does not have a CSM (aka Legacy) mode. This includes newer Intel Macs, as well as most PCs from around 2019 and newer.

These machines CAN run SpinRite, though, but it takes some effort to make it work. Essentially, one must:

1. Create a bootable external USB drive from which a UEFI-compatible OS can boot
2. Boot the target PC from that drive
3. Install VirtualBox on that drive
4. Create a FreeDOS Virtual Machine within VirtualBox in which to run SpinRite, and install SpinRite to that VM
5. Ensure that the internal drives of the host machine are UNMOUNTED, so that the actual OS does not interfere with SpinRite operations
6. Map the actual physical drives of the target PC to virtual drives in VirtualBox
7. Mount those virtual drives in your VM to either the IDE or AHCI controller
8. Run SpinRite, which should now see those drives as attached the PC within the FreeDOS VM

These techniques have been around the Internet for a while, but never documented here on the GRC Forum. For example, here's an article from 2017:

https://techniklman.github.io/2017-09-26-spinrite-in-a-vm/​

There are currently 3 tested "Host OS" environments that can be setup within which one can run VirtualBox:

1. Windows 11, setup in a "Windows to Go" configuration
2. Kubuntu 24.04 LTS, setup in a "Live CD" configuration on a USB with Persistence
3. MacOS, setup on an external drive

Which of the 3 "Host OSes" should I use?​

The Windows 11 and Kubuntu setups can be used to boot any UEFI system, whether PC or Intel Mac, AND SECURE BOOT CAN STAY ON!! The MacOS setup can only be used to boot a Mac.

There hasn't been enough testing to know if either Windows or Kubuntu makes for a "better" VirtualBox host, so for now the advice is to use whichever environment you're more comfortable with. Kubuntu is definitely faster and less laggy.

If you have a Mac, you should be able to boot any of the 3, but you should probably use MacOS as your host OS.

(And I did say Intel Macs; there is no current solution for Apple Silicon, and it's unlikely there will be)

What kind of drives can SpinRite in VirtualBox "see"?​

The physical drives are virtualized and accessed through the VirtualBox drive controllers and/or "BIOS"; any drive that the Host OS can see can be mapped to a .VMDK file, mounted in VirtualBox, and then addressed by SpinRite.

• When drives are attached to the virtual IDE controller, SpinRite accesses them through it's native IDE driver
• When drives are attached to the virtual AHCI controller, SpinRite accesses them through the virtual BIOS

In either case, SpinRite can access drives larger than 2.2 TB. Drives connected to the IDE controller will be processed faster than those attached to the AHCI controller.

I've tried multiple drive and attachment types and all have been accessible as AHCI or IDE attached drives:

• SATA-attached
• NVMe SSDs
• USB-attached
• eMMC SSD

USB drives must be physically attached (and the OS-specific unmount commands run) before creating the .VMDK files and attaching to the VM. There is no need for the USB mapping capability within VirtualBox when using the standard VBoxManage createmedium disk command.

Prerequisites​

There are certain items you need in order to make this work:

• Prep PC
  • You need a PC running Windows 10 or Windows 11 for certain prep steps (running Rufus to create the Kubuntu or Windows to Go drive), unless you are using MacOS as your host OS.
• Target PC (non Mac)
  • Must boot with UEFI firmware (or in UEFI mode if it can switch between UEFI and BIOS mode)
    • But if you can boot in BIOS/Legacy mode, maybe run SpinRite natively!
  • It must support Virtualization and have that feature turned ON in it's firmware settings:
    • Else you may get an error in VirtualBox. More info here:
      • https://helpdeskgeek.com/virtualiza...vailable-verr_vmx-no-vmx-error-in-virtualbox/
    • How to check if Virtualization is on?
      • If you're using the Win to Go drive to run VirtualBox, run the GRC utility Securable from the Win to Go drive:
        • https://www.grc.com/securable.htm
• Target PC (Mac)
  • Must be able to boot in UEFI mode (Intel Mac from about 2012 onwards)
• One USB flash drive for temporary storage of the GRC executable(s) to transfer to the new host drive
• One USB drive to run the "host OS" and VirtualBox. This could be a fast USB flash drive, but it's HIGHLY RECOMMENDED that you use an external USB SSD drive. Flash drives will quickly wear out and and slow down.
  • Capacity
    • For Linux setup, that should be at least 32 GB
    • For Windows or MacOS setup, that should be at least 64 GB
  • Speed - how do you know if a USB drive is fast enough?
    • Run the GRC utility ValiDrive on the USB drive. If it finishes in less than 10 seconds, that's fast enough.
• And most importantly, these "items":
  • A SAFETY FIRST ATTITUDE!!
    • Before working on your target system, back it up!! Just like running SpinRite natively against a system, virtualized SpinRite will rewrite data, so backup your data, just in case!
    • If running against an encrypted drive (with BitLocker on Windows, or FileVault on MacOS), print out your recovery key and store it safely!!
      • And if possible, temporarily turn off the encryption before running SpinRite against the drive
  • KNOWLEDGE!! You must be comfortable with Administration commands in both the Host OS of choice, as well as DOS and the VirtualBox application. You should NOT blindly follow this guide; you need to understand what the commands are; there is an assumption that you know your way around a PC. YOU ARE DOING THIS AT YOUR OWN RISK, AS IT IS AN UNSUPPORTED METHOD TO RUN SPINRITE. WHILE THE INSTRUCTIONS SHOULD ENSURE THAT THE DRIVES ARE UNDER EXCLUSIVE SPINRITE CONTROL, TESTING HAS NOT BEEN EXTENSIVE. DATA LOSS IS A POSSIBILITY!

Other notes:​

• Booting from external drives seems to throw off the clock on many target systems. Before starting work, double check that the time zone and time are correct. When booting back to the native OS, do the same
• The Windows and MacOS boot media seemed to shutdown cleanly; the Linux boot drive may hang during shutdown, requiring a physical push of the Off button. This did not seem to corrupt the Linux boot drive in anyway.

Choose your own adventure!!​

Due to length limitations in the forum, I can't include all the instructions for all of the variations in one article. I will therefore write up the following articles from which you can choose your path. Each topic is also split into multiple parts as needed:

1. Introduction (this article)
2. Using Windows to Go as the base OS for your bootable VirtualBox system:
   • Part 2A - Setting up the Windows to Go drive, Installing VirtualBox
   • Part 2B - Creating a SpinRite Virtual Machine, Mapping the Host drives to the SR Virtual Machine, Steps to take when moving your Windows to Go drive to a new Target Machine
   • Part 2C - Updating the Windows to Go drive to include Mac "BootCamp" drivers (optional, and obviously only for those planning to run the Windows to Go drive against a target Mac)
3. Using Kubuntu Linux as the base OS for your bootable VirtualBox system
   • Part 3A - Setting up the Linux drive, Installing VirtualBox
   • Part 3B - Creating a SpinRite Virtual Machine, Mapping the Host drives to the SR Virtual Machine, Steps to take when moving your Linux drive to a new Target Machine
4. Using MacOS as the base OS for your bootable VirtualBox system
   1. Part 4A - Setting up the MacOS drive, Installing VirtualBox, Running VirtualBox as "root"
   2. Part 4B - Creating a SpinRite Virtual Machine, Mapping the Host drives to the SR Virtual Machine, Steps to take when using your MacOS drive on a new Target Machine
5. Downloading or Creating your VM and moving files in and out of the virtual drive
   1. Part 5A - Download a pre-built Virtual Machine instead of creating your own
   2. Part 5B - Creating your own Virtual Machine
   3. Part 5C - Copying files to and from the VM hard drive

 

[leonfeng]

Just a friendly reminder to anyone following this guide that Steve advised against running SpinRite 6.1 in virtual machines on Security Now #956 (pages 11-12 of the show notes).

SpinRite 6.1 really is NOT [a well-behaved “generic” DOS application]. It… briefly switch[es] the processor into protected mode, then directly alters its memory management segmentation registers to remove real mode’s traditional 64K segment limitations. […] So it’s very safe to say that SpinRite v6.1 and an emulated environment are not going to be seeing eye to eye.

With that in mind, I'm currently doing a Level 3 on my 4TB external HDD and so far so good. (Also, I followed a previous version of the guide and set up SR 6.1 on Kubuntu 22.04.)

---

Update: operation complete. Disk I/O feels noticeably snappier with no apparent side effects.

More importantly, SpinRite was able to bypass the 2.2 TB BIOS limit.

Accessible BIOS drives will be limited to just the first 2.2 TB of capacity

With the added bonus of being able to save the VM state and resume at any time, running SpinRite 6.1r3 in VirtualBox could be more beneficial than on bare metal.

 

[Scott]

Just a friendly reminder to anyone following this guide that Steve advised against running SpinRite 6.1 in virtual machines on Security Now #956 (pages 11-12 of the show notes).

This is an unsupported method, but that’s an odd comment from Steve considering he did most of his initial development against a virtual machine in VirtualBox.

 

[DanR]

More importantly, SpinRite was able to bypass the 2.2 TB BIOS limit.

DanR said:
Accessible BIOS drives will be limited to just the first 2.2 TB of capacity

My complete quote:

Accessible BIOS drives will 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

 

[Scott]

More importantly, SpinRite was able to bypass the 2.2 TB BIOS limit.

DanR said:
Accessible BIOS drives will be limited to just the first 2.2 TB of capacity

My complete quote:

Accessible BIOS drives will 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

To the best of my knowledge, SpinRite has no problems with drives larger than 2.2 TB when run in VirtualBox. VirtualBox provides its own BIOS in software, which is apparently well written and presents drives in their full size to SpinRite. The VirtualBox "BIOS" relies on the drivers of the host OS (Windows, MacOS, or Linux) to talk to the drive, so the BIOS or firmware of the host machine is not brought into play. I've tested this on a 4 TB drive, which showed its size correctly during drive discovery and which SpinRite acted upon across its full capacity.

 

[DanR]

To the best of my knowledge, SpinRite has no problems with drives larger than 2.2 TB when run in VirtualBox. VirtualBox provides its own BIOS in software, which is apparently well written and presents drives in their full size to SpinRite. The VirtualBox "BIOS" relies on the drivers of the host OS (Windows, MacOS, or Linux) to talk to the drive, so the BIOS or firmware of the host machine is not brought into play. I've tested this on a 4 TB drive, which showed its size correctly during drive discovery and which SpinRite acted upon across its full capacity.

Good to know! Thanks, Scott. I have edited my post to reference your post just above.

 

[juztsteve]

Hello everyone. I am new here and I apologize ahead of time if this has been addressed elsewhere or before but here goes. In my limited experience (have had SpinRite 6.1 for only a month) I have been able to run the app on any SATA SSD attached in an external USB enclosure with complete success. My main PCs are UEFI only but I happen to have an older laptop the has the CSM option and is what I use to test all my drives. My next step is to try the same with a USB NVMe external enclosure for this type drives. On a separate note, just for dibs and giggles I tried running the program on a flash drive and, to my surprise, it runs faster now! Who knew... Regards.