Volume Hash Mismatch with EFI 4.2, 4.1 about optihack

[zearp]

I've not come across this myself. It may have to do with new options to OpenCore, a few new ones got added. Seems to be filesystem related to me. Any config differences between a version where the message shows and not shows might help. More unlikely is that a newer version of some kexts triggers this.

Other mentions of this message are not really helpful. Some people experience this on 12.2.1 and others report it was fixed on 12.2 for them.

To rule out a filesystem issue you could make a fresh clone then format the internal disk and restore the clone to it. Some people reported they could trigger the message by running some extended disk tests with Black Magic disk benchmark.

I OTA updated my main machine from the betas to the latest release without getting this message and haven't run into it myself on any other machine as well but I will try some tests this weekend and see if I can get it to trigger. A reproducible method to trigger it would be nice but seems many people who experienced this had different solutions. From bad ram to a fresh install.

[mgrimace]

. Any config differences between a version where the message shows and not shows might help. More unlikely is that a newer version of some kexts triggers this.

Ok, I ran a diff command between the not-working config and working config:

277,278d276
< 				<key>rps-control</key>
< 				<data>AQAAAA==</data>
415,432d412
< 				<key>BundlePath</key>
< 				<string>FeatureUnlock.kext</string>
< 				<key>Comment</key>
< 				<string>FeatureUnlock.kext</string>
< 				<key>Enabled</key>
< 				<true/>
< 				<key>ExecutablePath</key>
< 				<string>Contents/MacOS/FeatureUnlock</string>
< 				<key>Arch</key>
< 				<string>Any</string>
< 				<key>MaxKernel</key>
< 				<string></string>
< 				<key>MinKernel</key>
< 				<string></string>
< 				<key>PlistPath</key>
< 				<string>Contents/Info.plist</string>
< 			</dict>
< 			<dict>
570,571d549
< 			<key>LogModules</key>
< 			<string>*</string>
647,651d624
< 			<key>4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102</key>
< 			<dict>
< 				<key>rtc-blacklist</key>
< 				<data></data>
< 			</dict>
673,676d645
< 			<key>4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102</key>
< 			<array>
< 				<string>rtc-blacklist</string>
< 			</array>
784,789d752
< 			<key>PointerPollMask</key>
< 			<integer>-1</integer>
< 			<key>PointerPollMax</key>
< 			<integer>80</integer>
< 			<key>PointerPollMin</key>
< 			<integer>10</integer>
807,814c770,771
< 			<key>MaximumGain</key>
< 			<integer>-15</integer>
< 			<key>MinimumAssistGain</key>
< 			<integer>-30</integer>
< 			<key>MinimumAudibleGain</key>
< 			<integer>-55</integer>
< 			<key>SetupDelay</key>
< 			<integer>0</integer>
---
> 			<key>MinimumVolume</key>
> 			<integer>25</integer>
818a776,779
> 			<key>SetupDelay</key>
> 			<integer>0</integer>
> 			<key>VolumeAmplifier</key>
> 			<integer>0</integer>

I'll also attach an anonymized working + not-working version in case above isn't useful. I've renamed the files .zip since .plist isn't an allowed upload here. They're not actually zipped though. Serials removed.
mismatch config.zip
working config.zip

I OTA updated my main machine from the betas to the latest release without getting this message and haven't run into it myself on any other machine as well but I will try some tests this weekend and see if I can get it to trigger.

Same, I haven't had any issues updating the machine, and I un-enrolled from the beta and I'm on the current 12.2.1 stable version. Basically, whenever I see a new EFI release here, I just go through and update the EFI, but the last two result in this error.

To create the error I use EFI agent to mount the system EFI (disk0s1), delete the EFI folder in there, and replace it with EFI 4.2 (with my serials, USBkext, and tweaked displaypreferences). Then, reboot, and after booting up the error appears. To fix the error, I remount the EFI folder, delete EFI 4.2, and copy in my backup EFI (I think around 4.0). Reboot, no error.

I'll double check if it's the usbkext, since I've been carrying that forward for a few EFI release versions now. But otherwise nothing different in my EFI update process. Thanks for looking and I'll try some other things and see what happens!

[zearp]

I'm not sure what in the config changes could trigger such a warning. Apple's documentation is very bad, can't find much on what causes a hash mismatch. Also interesting the mismatch gets resolved when using another EFI version. That would indicate it's caused by some combination of maybe config changes and newer kexts. This could be one of those weird Apple bugs that only pops up under certain circumstances and not anywhere else.

https://osxdaily.com/2021/11/10/volume-hash-mismatch-error-in-macos-monterey/

I wonder if this happens if you make a fresh backup then format the internal disk and do a clean install using the latest EFI and after install use the migration tool to copy all your files, data and settings from the backup.

In a way it reminds me of these issues one can get when changing hardware which changes the unique hardware identifier some operating systems/apps use. It's sometimes used as copyright protection, I think windows activation also uses this. If you replace certain hardware Windows deactivates itself.

It may not be relevant to this though, just got reminded of it. Maybe between the EFI versions the hardware identifier or something like that changes which triggers the warning. It would be nice if Apple had better documentation on their filesystem and what exactly triggers this message.

I've done a clean install of 12.3 on my test machine but didn't run into it. Another option is that there's some beta leftovers messing things up very unlikely but possible since your machine was upgraded a few times. Luckily with macOS it is easy to do a clean install without losing any settings or data.

[mgrimace]

In a way it reminds me of these issues one can get when changing hardware which changes the unique hardware identifier some operating systems/apps use. It's sometimes used as copyright protection, I think windows activation also uses this. If you replace certain hardware Windows deactivates itself.

Thanks for the thoughts and suggestions! After quite a bit of investigation I believe I have the culprit and a reliable method to trigger the hash sum mismatch issue: I have a Fenvi HB1200 bluetooth/wifi module installed, and as a result changed my ubsports.kext port map so HS09 is set as internal. Specifically, I routed the hardware usb connector for the USB card to an external USB port (HS09) and in the usbports.kext, changed usbconnector for HS09 from 3 to 255 to set it as an internal USB port so bluetooth would work as expected.

It looks like this change triggers the hardware mismatch issue.
Trigger the issue: designate a HS09 (or presumably any USB port) in usbports.kext as internal (set usbconnect number as 255).
Fix the issue: use default usbports.kext, or downgrade to previous EFI/OC version.

I'm not sure how necessary it is to have that port set as internal, so I'll test out some of the features (e.g., handoff, Apple Watch unlock, etc.) and see if they still work when the port is set as external. No idea for a long-term fix for folks who have/need to customize their USB ports but this seems to be the culprit.

[mgrimace]

Update: I may have spoken too soon, been working away here with USBports.kext reset to default and the error just re-appeared (thought much later, where before it would happen instantly). I still think it is something to do with Bluetooth hardware though so I'm going to continue testing here with bluetooth disabled.

Re. internal vs., external port, it does seem like the handoff features are not working with the port external (which is expected behaviour and why I set it to internal previously).

[zearp]

I'm trying hard to find a connection between newer OC versions and usb. I didn't read the changeless very deeply but don't think there were any changes in usb.

I use an Apple Airport card in my test machine and I also have to set the usb to 255 otherwise weird things happen with sleep and bluetooth connections dropping out a lot.

I went for Apple cards cuz they're so cheap. Fenvi uses the same chipsets at a premium price. I recently upgraded some machines here, got a nice deal for BCM94360CS2 cards. They don't do 1300mbit AC, "only" 800mbit but for the price it's so hard to beat. I paid about $5 per card when I bought 5 of them on eBay.

Either way, the connection between usb and pci-e cards and somehow a filesystem hash not matching anymore is super weird to me. I really wish Apple would document how this error is triggered and what it all means. Maybe I'm not looking in the right places but I can't find anything technical on it.