Volume Hash Mismatch Hash mismatch detected on volume disk1s5

[LockDown]

0xFEF

And yours @makk?

 

Funny thing is, most of the users who encountered this issue have bluetooth. Unless you can point one that does not have.

Edited February 14, 2022 by LockDown

[makk]

17 hours ago, LockDown said:

0xFEF

And yours @makk?

 

Funny thing is, most of the users who encountered this issue have bluetooth. Unless you can point one that does not have.

 

I have SIP Enabled.

 

csrutil status

System Integrity Protection status: enabled.  

config.plist>csr-active-config Data <00000000>

 

I found that in Monterey change is similar to Big Sur where I did have SIP disabled and <67080000>

I also tried these values as well <67000000> <030A00000><26070000>

 

I am trying to find an doc. that is well documented instead of like reading a Technical Spec Book, more layman's terminology. 

 

After my machine went to sleep the mismatch occurred.  

Before that no mismatch.  So I collected a kernel log

 

At the moment Running Monterey 12.2 

Less occurrence on 12.2.  Great occurrence on 12.2.1

 

I found that from reading up on a website, Apple has changed in  Monterey the Bluetooth design in the configuration.  It seems they are doing a complete work over.

 

I read it on the BlueToolFixup.kext Bug Tracking page. 

https://github.com/acidanthera/bugtracker/issues/1821

 

 have a look a the text attached to see if yours has the same output, 

 

log show --debug --last boot --predicate 'process == "kernel"' 

 

Actually I would like to narrow the search to finding just what I am looking for instead of running the whole kernel.

 

 

 

Data_Mismatch_Disk1s6.zip

[makk]

I switched loading AirportIltwm.kext to iltwm.kext for wifi  ( Intel AC 3160 )

I'm still loading BlueToolFixup.kext, IntelbluetoothFirmware.kext,

set SIP Enabled

set sleep parameters > pmset -g to check status and pmset -a to change each one

also added this to the Properties for XHCI USB.

acpi-wake-type Data <01>   (Wake Reasons on Dortania Trouble shooting page)

built-in Number 1  ( a good measure when reading IOREG to show as built-in)

 

put the machine to sleep overnight and so far no mismatch.

 

I had 5  mismatch yesterday. 

 

What I did yesterday after the mismatch, Turned off Bluetooth in the Desktop mode and then turned it back on.  

Then, 2 mismatch occurred after a few hours.  Total of 5 mismatch or DHM.

 

Today no mismatch for the time being.

 

Originally,

I thought that SIP being disabled was the reason.  Being that the partition being accessed is rooted and protected. (log showed broken xid for the disk)

So I reinstalled a second time Monterey And Big Sur with SIP Enabled at least so I thought, but my NVRAM showed otherwise

after installing.  <7f080000>  SIP Disabled. Frak! 

Cleared the SIP to Enabled. Let the machine sleep.

 

Then I  thought might be the AirportIltwm.kext. disabled it and loading iltwm.kext, along with BlueToolFixup.kext, IntelbluetoothFirmware.kext.

checked the pmset -g for sleep and other parameters.  Set them accordingly.  Might be proximitywake, tcpkeealive, standby, sleepimage(found no sleep image in Monterey or Big Sur at /private/var/vm and /var/vm/) so did not need to delete it.) might be WOL, WOU, WOMP, turned these to 0.

So I set the pmset -a and only displaysledp, sleep, disksleep to 999999 > SSD drive no spinning.  Sleep to 20, powernap 1, 

 

Hit the sleep button and woke it up. No data hash mismatch.  Checked the kernel log.  Found disk1s6 authenticating normally with no mismatch.

 

At the very top is what I have set now

 

 

 

 

Edited February 15, 2022 by makk

[makk]

As for what Kexts and versions I am using.

 

I have from Acidanthera Lilu and Friends.

So I update the kexts.

 

1 BlueToolFixup.kext is now version 2.6.2 

2 IntelbluetoothFirmware.kext version 2.1.0 and IntelBluetoothInjector.kext is 2.1.0

3 AirportIltwm.kext version 2.2.0

4 iltwm.kext version is 2.2.0  

 

In the config.plist disabled ExtendedBT which didn't work any way in Big Sur. lol (does work sometimes so consistency is a no go)

 

Since I am running both Big Sur and Monterey

 

I did the following for AirportIltwm.kext in config.plist to load just the specific ones for each OS. (changed the outlying kext name only, not the one for ExecutablePath)

1 for Monterey AirportIltwm.kext > Set MinKernel to 21.00.0 so it will only load in Monterey.

2 for Big Sur AirportIltwmb.kext> Set the MaxKernel to 20.99.9

 

Since as of Monterey according to the Dortania concerning these kexts, only loading IntelBluetoothFirmware.kext and not IntelBluetoothInjector.kext. 

Set the MaxKernel for IntelBluetoothInjector.kext to 20.99.9 so it will only load in Big Sur

 

I didn't think changing the name would work but it did.  Wella! Bingo... lol

But as of now it seems that AirportIltwm.kext for Monterey is causing my issue. Unfortunate because Airplay does not work without this kext.

 

Hope this helps in your search for the reasons for the data hash mismatch.

 

 

 

 

Edited February 15, 2022 by makk

[makk]

Turns out that the culprit on my machine for Monterey 12.2 is AirportIltwm.kext ( Monterey version 2.1.0 and 2.2.0 ) it seems like from the kernel log a authentication  issue.  As for what type of authentication I am inclined to not knowing which one.  

 

Bluetooth is up and running. 

[LockDown]

4 hours ago, makk said:

Turns out that the culprit on my machine for Monterey 12.2 is AirportIltwm.kext

I dont use that kext as I dont have intel BT. Mine is broadcom

[makk]

On 2/16/2022 at 7:48 PM, LockDown said:

I dont use that kext as I dont have intel BT. Mine is broadcom

 

Thanks Lock,

 

on the Intel Mini PCI-e combo is a Broadcom Bluetooth according to the specs.

looks like you need about 4 kexts for bluetooth.  Data, Repo, Injector, RAM.

BrcmPATCHRAM group

Edited February 18, 2022 by makk

[makk]

I wasn't satisfied with the previous fresh install.  had to tinker with config.plist a bit, plus kexts.

 

On fresh install the Airportiltwm.kext finally loads as ether2 instead of wifi, though wifi logo is present but the interface designation is ether2 in System Preferences Pane > Network.  Normally wifi interfaces are tagged wifi.

What I gather that was happening with Airportiltwm.kext it was loading as a wifi interface instead of ethernet interface. WLAN vs LAN interface.

 

So the fresh install with SIP Enabled along with the Airportiltwm.kext loading as ether2 seems to have fixed the data hash mismatch.

 

 

Hope this remains.

[makk]

Well didn't last long, after rebooting, the data hash mismatch came back. So reinstalled Big Sur and updated to 11.6.4. ( security patches otherwise I would stick with 11.6.0 due to it being faster )  Monterey runs faster I think than Big Sur at least 12.2 does on my machine.  No Monterey on SSD Drive.  Causing issues which is being looked into on my end.

 

What I did find interesting is  I upgraded my Mojave to Monterey, on an old Hitachi 320gb spin drive a few weeks ago just for kicks and grins.   I never had single issue of data hash mismatch. Never even heard of if. So I am running that right now and after overnight still no data hash mismatch.

For wifi have running at the moment  iltwm.kext instead of AirportIltwm.kext.  I initially had an Atheros wifi 9240 that had no bluetooth. I seen Intel W/BT's successes on multiple Hacks.  So I swapped out the Atheros and put in the original Intel AC 3160 W/BT in and tested on the Mojave drive.  Then I upgraded to Monterey to test out the  Wifi.

 

The Monterey on Hitachi:

1 OC 7.7

2 FeatureUnlock.kext

3 itlwm.kext

4. BlueTool.kext

5. IntelBluetoothFirmware.kext

6. USBPorts.kext (hackintool)

 

I'm running that right now with Bluetooth up and running. Just cannot connect to my iPhone which is weird. 

All devices paired with initial connect.

 

Previously the data hash mismatch appeared right after updating a kext, a configuration.

 

NOTE: So the issue with this data hash mismatch, could be a combination of things. Starting with an SSD drive that is not compatible.

It seems the Samsung EVO 750 is not compatible due to the trim approach Samsung takes.  turning this feature off might solve the problem. and runs a little bit slower.  But faster than a spin drive.

 

NOTE: USB Ports, since Bluetooth uses is allocated USB ports, must have to know which USB ports the bluetooth uses. This can be a rough one.  I was using Hackintool to discover the ports. I used USBMap to discover the ports.  

It can be the fact that I'm on a spin drive and no trim enabled.

 

Will keep testing to find if it is a few things other than a Bluetooth and wifi.

These are hypothetical of course until the real problem is found.

 

configuration for this is below in the kexts

 

 

 

 

Edited February 22, 2022 by makk
EDITED

[makk]

Lockdown, gujiangjiang

 

#1

New Find as of  2/18

With this find no Data Hash Mismatch.  I'm wondering if OC 0.7.7 has anything to do with it? is anyone else running 0.7.7 or below?  not 0.7.8 or 0.7.9

 

Running Monterey 12.2 on Hitachi Spin Drive 5400RPM laptop series. [ transferred this EFI to SSD Drive running Monterey and made some config changes to accommodate ]

Below are the specs:

Opencore 0.7.7

Kexts: 

1 itlwm.kext 2.2.0 <> AirportItlwm.kext on SSD Drive

2 BlueTool.kext 2.6.1 

3 IntelBluetoothFirmware.kext 2.1.0

4 FeatureUnlock.kext <> works AirPlay Receiver in Share, Screen Mirroring shows the Roku Express.

5 CPUFriend with CPUFriendDataProvider.kext with ssd_data.aml in place of SSDT-PLUG.aml.

SSDT's:

1 USB-reset.aml

2 ssd_data.aml

3 SSDT-EC-LAPTOP.aml

4 SSDT-HPET.aml

and local ones

 

Config.plist:

1 Advise Features enabled in NVRAM Generic

2 took out the Extended Features and Features in Platform NVRAM did not help one bit in OC on 0.7.8.

3 ActivateHPETsupport enabled in Quirks UEFI.

 

Installed are all the necessary Lilu.kext and plugins.

USBPorts.kext from Hackintool <> although not sure if taken enough steps.

USBMap.kext on SSD Drive

 

NOTE:  On SSD Drive have trim enabled.  Debugging off in config.plist and debugging off for Lilu and plugins.  With Monterey this is a new animal and Apple has made significant changes internally. From reading up on the Net it seems Apple is geared to Apple approved Wifi Bluetooth, and other significant Internet accessing devices.  Thus said, probably until OC crew and kext patch makers get up to this new standard, may have to turn off some features as well as use less devices.  So, what I suggest is using older version of OC and possibly that may have a temporary bandage. Try older versions of Opencore if you are using Opencore.

If Clover, possibly older versions that ran Big Sur and Catalina that do not have the new additions in the manicure of the app.

To be precise, have to block and mute certain aspects but allow what is necessary to run your devices. 

 

#2

With the Bluetooth enabled, the log messages on boot up flash tons of 1442000 IOUSB port which is Bluetooth on this machine.

With the Bluetooth disabled, no log messages flash and grace the screen with millions of messages.

Alerts of it timing out from waking or attaching?  So the remedy is to have this sleep and not try to attach while booting up. Keep it's wheels in check so it can go out the gate.  Says gated timeout 500 ms, then 1000ms, then back to 500ms.

--logging and debugging are turned off or disabled. Not running Debug versions of kexts or Opencore--

 

What variable in config.plist would turn off these messages that are annoying? it fills the kernel log.

Edited February 22, 2022 by makk

[gujiangjiang]

Today my XPS15-9550 with DW1830（BCM94360CD）show this Volume Hash Mismatch.

So it maybe have no relationship with Intel BlueTooth?

[makk]

24 minutes ago, gujiangjiang said:

Today my XPS15-9550 with DW1830（BCM94360CD）show this Volume Hash Mismatch.

So it maybe have no relationship with Intel BlueTooth?

@gujiangjiang

 

Do you have FeatureUnlock.kext?

Do you have FileVault enabled?

 

I had one yesterday after a long period.  Could be just a random Bluetooth mishap.

 

 

Just now, makk said:

@gujiangjiang

 

Do you have FeatureUnlock.kext?

Do you have FileVault enabled?

 

I had one yesterday after a long period.  Could be just a random Bluetooth mishap.

 

Just now, makk said:

Also the USB Mapping.  Check the ports.

 

 

Lockdown do you know what MacProfiles don't have this issue?

 

 

[gujiangjiang]

7 minutes ago, makk said:

@gujiangjiang

 

Do you have FeatureUnlock.kext?

Do you have FileVault enabled?

 

I had one yesterday after a long period.  Could be just a random Bluetooth mishap.

 

 

 

 

Lockdown do you know what MacProfiles don't have this issue?

 

 

I have FeatureUnlock.kext

I don't have FileVault enabled

 

I think it was related with buletooth but have no evidence.

[makk]

On 3/12/2022 at 10:39 PM, gujiangjiang said:

I have FeatureUnlock.kext

I don't have FileVault enabled

 

I think it was related with buletooth but have no evidence.

UEFI -> ProtocolOverrides

 

HashServices set to YES for Broadwell and older(this includes X99), this is needed for systems with broken SHA-1 hashing

 

Try turning this on in your Bootloader if Opencore ^UP^

and in Clover there should be a hashxxx.efi  place that in drivers where BIO or UEFI

 

 

[makk]

Tell me your mac model and what kexts and bootloader you are using.

 

I had to do some backwater configuring myself

 

what is your boot method? BIOS or UEFI?

 

 

Edited March 17, 2022 by makk

[gujiangjiang]

On 3/17/2022 at 12:12 PM, makk said:

Tell me your mac model and what kexts and bootloader you are using.

 

I had to do some backwater configuring myself

 

what is your boot method? BIOS or UEFI?

 

 

MacBook10,1

Intel CoreM 5Y10c

UEFI

OpenCore and Clover

[makk]

1 hour ago, gujiangjiang said:

MacBook10,1

Intel CoreM 5Y10c

UEFI

OpenCore and Clover

 

Ok so what kexts are you booting with?

 

[makk]

upgrade to Monterey 12.3

 

use the app.

 

ANYMACOS do a search on duckduckgo

download the app and then download full installer for Monterey 12.3

wipe drive start over  suggest is to do a secure wipe slide security over a few notches wipe it good

back up your EFI to USB

Edited March 19, 2022 by makk

[Ethan Jarvis]

Well, it’s not clear yet what actually causes the hash mismatch error in macOS, as users have reported it randomly appearing, or after a significant system crash or kernel panic. However, whenever user experience this error message, it’s a good idea to immediately backup all data on the Mac with Time Machine or any other backup method of choice.

 

Further, user can also try the below troubleshooting methods to fix the issue:

 

1. Reset SMC
2. Reset PRAM/NVRAM
3. Reinstall macOS

 

Hope this will help!

  

[makk]

On 4/8/2022 at 1:23 AM, Ethan Jarvis said:

Well, it’s not clear yet what actually causes the hash mismatch error in macOS, as users have reported it randomly appearing, or after a significant system crash or kernel panic. However, whenever user experience this error message, it’s a good idea to immediately backup all data on the Mac with Time Machine or any other backup method of choice.

 

Further, user can also try the below troubleshooting methods to fix the issue:

 

1. Reset SMC
2. Reset PRAM/NVRAM
3. Reinstall macOS

 

Hope this will help!

  

@Ethan Jarvis

 

Hi Ethan, we're on HackOS's not the real thing.

 

Seems to be an issue with not having an appropriate Apple only supported --> Wifi/BT cards. Fenvi, Broadcom

On hackos 

Bluetooth problem

 

thanks for looking out!

 

Edited April 14, 2022 by makk

[Slice]

10 hours ago, makk said:

@Ethan Jarvis

 

Hi Ethan, we're on HackOS's not the real thing.

 

Seems to be an issue with not having an appropriate Apple only supported --> Wifi/BT cards. Fenvi, Broadcom

On hackos 

Bluetooth problem

 

thanks for looking out!

 

Don't speak with him. He is a spammer.

[MacKonsti]

Hello everyone, hope you are all well. The thread has been silent--is it abandoned? I've been meaning to post in the last days...

Has anyone figured out how to solve this Volume Hash Mismatch error?

I am running latest Monterey with a PNY XLR8 NVMe (Model CS3030) that seemingly has a Phison E12 controller...

 

1. I tried to make a checklist to exclude factors, perhaps one can help enhance it ?

 

NVMeFix.kext is not used/loaded ✅
FeatureUnlock.kext is not used/loaded ✅
Using an Intel Wi-Fi/BTLE combo (embedded in my NUC) module ✅
Using a carefully crafted USBPorts.kext with mapped USB ports ✅
Samsung NVMe disks (e.g. 970 EVO) is not installed or used as primary OS drive ✅

 

2. The USBPorts.kext has the correct internal port for BTLE set as 255 ; I also tried later to set another internal port (some Internal USB-C alias) as 255 but to no avail.

 

3. I had stopped using the suspected BlueToolFixup.kext but I had the error eventually. Obviously, BTLE stopped working.

 

4. The error popped up yesterday when I plugged my iPhone on the front USB port of the Intel NUC that I have. For almost a month (including latest Monterey updates) it did not appear ALTHOUGH I have not been using BTLE or Wi-FI.

 

5. Any idea what the setting in OpenCore should be under UEFI → ProtocolOverrides → HashServices eventually? FALSE or TRUE ? I am confused, to be honest. I am not using FileVault2 (according to the OpenCore manual PDF) but my CPU is "Haswell or newer", could this be eventually affecting this error ?

 

6. Any other possible reason? Some NVME value... or kext?

 

I have compiled this check-list in my repo, thanks in advance for your help!

Edited April 24, 2023 by MacKonsti