"volume corrupt while scanning the…" Software RAID

[Darcy Taranto]

Hi everyone / Roderick,

Thanks again for the wonderful rEFInd.

I’m having an issue that only brings up two google results, neither really helping me completely.

My system when working:
I’m running rEFInd off of a NVME startup drive, it correctly detects Mac OS, Ubuntu and Windows across that drive and another NVME drive on the motherboard.
I also have four other SATA drives connected that are just storage.

The issue:
2 of the 4 SATA drives are a recent edition, they’re 6TB IronWolfs that I’m running in RAID0 via the Mac app SoftRaid.
The BIOS is all set to usual SATA mode, no IntelRaid stuff. (Because I’m running a Hackintosh and there’s no drivers for it)

Since setting up the RAID, I’m now getting a list of of errors that all start with "volume corrupt while scanning the…" listing the root, and other places I guess rEFInd auto scans.
I’ve narrowed down the problem to the SATA drives in the RAID0 — when they are connected on startup, I get the errors. When they aren't, I don’t.

This wouldn’t be such a big deal, if it weren’t for the fact that when I “Hit any key to continue…”, I don’t get the graphic rEFInd menu — just a blank screen which times out to my default boot option.

I’ve tried adding both drive’s EFI partition UUID to the don’t_scan_volumes option, but I’ve also read online that rEFind maybe can’t get this UUIDs anyway?

Any help would be much appreciated!
Thanks!

[Darcy Taranto]

Anyone have any suggestions on this?

[joevt]

The refind.conf file says the following about the dont_scan_volumes option:

It's also possible to identify a partition by its
# unique GUID (aka its "PARTUUID" in Linux parlance). (Note that this is
# NOT the partition TYPE CODE GUID.) This identifier can be obtained via
# "blkid" in Linux or "diskutil info {partition-id}" in macOS.

Do the SoftRaid disks have partitions with UUIDs?
You can use diskutil info -all to get info for all disks.

If UUID can't work, then: try turning off automatic scanning and use manual stanzas for everything?

Probably rEFInd needs a code change to handle SoftRaid disks?

Try the RefindPlus project. It has a log file in the debug version that might be informative. You can just replace the refind.efi file with the Refindplus.efi file (it might be called bootx64.efi - change the name to match - compare file size to make sure you are replacing refind and not something else)
https://github.com/dakanji/RefindPlus

If you are running a Hackintosh, then why are you using rEFInd instead of Clover or OpenCore?

[Darcy Taranto]

Hi Joevt,

Thanks for your thoughtful and detailed reponse.

I am running OpenCore, however I built my setup before OpenCore implemented it's graphical switcher OpenCanopy and fixed some things to allow clean Windows booting from that menu, and althought I've updated it since and have started using the graphic switcher for the Mac OS partitions and tools, I'd prefer to keep rEFInd for a couple reasons:

Firstly I want to keep everything as separate as possible, so once I've chosen Mac OS from rEFInd, I've essentially chosen OpenCore, and I get just that relevant stuff etc.

Secondly, I've used rEFInd and rEFIt before it for a long time and I love the flexability and customisation.

In terms of the UUIDs, I was grabbing them as I and you suggested, from that terminal command, however I was just listing the EFI partition UUIDs that existed on the two drives that make up the RAID. I've now gone and written down every UUID of every volume/partition on those two drives as well as the virtual RAID volume. I've also put down the name for good measure.

The error has changed now to be more precise. It now just says it can't read the EFI directory, presumably, still the one or ones relating to the RAID volume.
The issue is, I can't use the device labels, because they change randomly on every boot it seems (diskx to disky, etc.).

I also don't want to just block 'EFI' volumes, as I want rEFInd to be able to see EFI partitions when they're plugged in for external booting.
For that same reason, I don't want to turn off auto scanning and use manual paths for everything. It's not a completely closed system.

I will look into rEFIndPlus and report back.

[dakanji]

"rEFIndPlus" ... another one for the collection!

It is "RefindPlus"

[Darcy Taranto]

So I tried RefindPlus in debug mode and straight off the bat, it worked perfectly.
Checking the log shows this:

1:468 0:102 Seek Bootloaders...
1:470 0:002 Scan Internal:
1:474 0:004 ** WARN: Volume Corrupt while scanning the EFI directory on HFS+ volume
1:495 0:021 - Found 'EFI\refind\refind_x64.efi' on 'EFI'
1:513 0:017 - Found 'Microsoft EFI boot' on 'EFI system partition'
1:520 0:007 - Found 'EFI\ubuntu\grubx64.efi' on 'EFI system partition'
1:550 0:029 Scan External:
1:551 0:001 Scan Optical:
1:553 0:001 Scan Manual:
1:570 0:017 - Found 'MacOS' on 'EFI'

So it blasted past the error that standard rEFInd got stuck on, which is great.
The log was very interesting, and it's leading me now to look into why my Windows Recovery partition is not being found.

Thank you so much for the RefindPlus suggestion!

[joevt]

Would be interesting to find out why it thinks the volume is corrupt.
Maybe there's a GPT partition with the HFS+ UUID which is not actually HFS+.
Probably need that log, plus the result of the following commands from EFI Shell (First, use FS0: to select a file system that has read/write access, such as an EFI or FAT partition)
map > map.txt
dh -d -v > dh_d_v.txt

and the following from macOS:
diskutil list
diskutil info -all
sudo gpt -r show /dev/disk0
sudo gpt -r show -l /dev/disk0