Jump to content

Volume Hash Mismatch Hash mismatch detected on volume disk1s5


gujiangjiang
 Share

47 posts in this topic

Recommended Posts

Quote

 

Volume Hash Mismatch

Hash mismatch detected on volume disk1s5. 

 

 

When i update to Monterey the notification appears shortly after i log into my mac book. Any idea on how to solve it?

 

0fa4dbfb-d8f2-43c3-888d-feda6bcebeb8.png.84bd2628a35ef50e58cca33af4ce37ec.png.36d49288efa59eaac2a85670c34fd27e.png

 

I have tried Clover and OpenCore and both of them have same problem in my laptop.

Edited by gujiangjiang
Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...
On 1/3/2022 at 12:16 PM, Slice said:

Make sure ExtendedFirmwareFeatures has 35bit set.

 

 I have this issue today after booting and a few minutes in Desktop mode.

 

Which one is the ExtendedFirmwareFeatures you are referring to? 

Link to comment
Share on other sites

41 minutes ago, LockDown said:

It does not help setting it to 35

 

@makk @gujiangjiang do you happen to have a bluetooth device?

 

My observation:

Im only getting this error/warning randomly if i enable and use BluetoolFixup.

 

My observation is Monterey has issues with these cards.

As far as I have read the OC people are working out the bugs.  This is a bug.

 

Have bluetooth wifi combo mini pci-e onboard the Laptop some version of Intel, not sure what model as the letters are smaller than

ant turds.  That came with this Laptop.  

 

I have IntelBluetoothFirmware.kext, IntelBluetoothInjector.kext and BluetoothFixup.kext enabled and up.

I had this issue once when I changed profiles from MacBook Pro12,1 to MacAir Pro 7,2. This was the only time that the

message popped up.  When I reverted bak to MacBook Pro 12,1 no more.  

I switch between Big Sur and Monterey on the same drive.  Was seeing if FeatureUnlock.kext unlocked AirPlay in MacAir Pro, but did not work. 

 

For Monterey cannot have the IntelBluetoothInjector.kext loading, causes an issue with Bluetooth not loading right and wangs out.  CPU at 99%.  in verbose mode the itlwm.kext messages added to que flashes. then in Desktop mode have problems with it.

But, for Big Sur need all three. So for the IntelBluetoothInjector.kext set the MaxKernel to 20.99.9 in config.plist. then it works

 

One last thing in config.plist in the Kernel>Quirk>ExtendBTFeatureFlag to True or Enabled -- on

 

 

Edited by makk
Link to comment
Share on other sites

9 hours ago, gujiangjiang said:

Clover dont have this Quirk.🥲

 

Right you can download the kext right here

 

This file Rehabman had in his project originally for HP Probooks with a Clover version 4071r which Rehabman modified

which I am using and modified for OS above High Sierra.  So i took the kexts that work in and for Mojave, Catalina, Big Sur, Monterey.

Testing each one.  I am on Opencore now.  For some reason I cannot get Clover to boot anymore

 

It's better to use config patches that you manually have to write in yourself and also the kexts that have been made to patch then rely on a tick of the checklisted on a config.plist when it comes to certain aspects.

 

 Kexts and manual patches that someone actually took the time to 'Test' have better results most of the time.

 

 

BT4LEContinuityFixup-1.1.4-2020-05-28 00.18.02.zip

Link to comment
Share on other sites

On 2/8/2022 at 7:56 PM, LockDown said:

According to dortania guide, this only works for 10.8-11

 

Yes, having both 11 and 12 on the same drive sharing the same OC config.

 

BT4LEContinuityFixup.kext for just Big Sur

So for this kext, set the MaxKernel to just Big Sur. 20.99.9

 

I know these are not kept up to current. But they do 'load' and you can stat with:  kextstat.  OC for the most part as I have noticed

does not load a kext that conflicts. ExtendedBTFeatures will not enable even if you have it enabled in the Quirk for certain OS.

 

add in the config.plist as MinKernel 21.00.0 for BlueToolFixup.kext

 

Wifi N and bluetooh 4.0 are required for most OC kexts for certain OS.

Link to comment
Share on other sites

15 hours ago, makk said:

 

Right you can download the kext right here

 

This file Rehabman had in his project originally for HP Probooks with a Clover version 4071r which Rehabman modified

which I am using and modified for OS above High Sierra.  So i took the kexts that work in and for Mojave, Catalina, Big Sur, Monterey.

Testing each one.  I am on Opencore now.  For some reason I cannot get Clover to boot anymore

 

It's better to use config patches that you manually have to write in yourself and also the kexts that have been made to patch then rely on a tick of the checklisted on a config.plist when it comes to certain aspects.

 

 Kexts and manual patches that someone actually took the time to 'Test' have better results most of the time.

 

 

BT4LEContinuityFixup-1.1.4-2020-05-28 00.18.02.zip 8.31 kB · 1 download

 

I tested BT4LEContinuityFixup with CloverBootLoader but with no use. It still show Volume Hash Mismatch.

Link to comment
Share on other sites

3 hours ago, gujiangjiang said:

 

I tested BT4LEContinuityFixup with CloverBootLoader but with no use. It still show Volume Hash Mismatch.

the hash mismatch isn't related to BT4LE.

 

It is related to as Slice wrote up top.

 

ExtendedFirmwareFeature have bit 35 set.  

 

I'm on Opencore and have to look in the config.plist.  Platform.

 

So have to find this bit in the EFF.  

On 1/3/2022 at 12:16 PM, Slice said:

Make sure ExtendedFirmwareFeatures has 35bit set.

 

Slice can you be more specific?  ExtendedFirmwareFeature 

Link to comment
Share on other sites

As far as Clover you can use Clover Configurator, Open up without config.plist, select your model

and view ExtendedFirmwareFeatures, ExtendedFirmwareFeaturesMask, grab those values

and paste them into SMBIOS.


Here's a screenshot:

 

In Opencore there is no pre-configured sample for these. So have to edit them in.

 

Try it out and see what happens.

Screen Shot 2022-02-10 at 1.38.21 PM.png

Link to comment
Share on other sites

9 hours ago, makk said:

the hash mismatch isn't related to BT4LE.

 

It is related to as Slice wrote up top.

 

ExtendedFirmwareFeature have bit 35 set.  

 

I'm on Opencore and have to look in the config.plist.  Platform.

 

So have to find this bit in the EFF.  

 

Slice can you be more specific?  ExtendedFirmwareFeature 

 

With no use I tested many times

Link to comment
Share on other sites

On 2/8/2022 at 7:56 PM, LockDown said:

According to dortania guide, this only works for 10.8-11

 

Hey do you read peoples SIGNATURE?

 

I have 2 OS 11 and 12

 

5 hours ago, LockDown said:

☝️Does not help either

 

LockDown, do you have anything  else to test this out on?

 

Besides guessing?

 

Setting the bits did not work in OC.

 

On bootup disk1s5 has issue with seal, integrity protection.

 

Try, SIP with <> csrutil disable  & csrutil authenticated-root disable

aslo Gatekeeper <>  spctl --master-disable

set <> csr-active-config <67080000> in your Opencore 

set <> in clover 0x867?  don't recall

 

these are the SIP settings, I will.

 

What I have done so far is, in Recovery ran First Aid on all volumes individually.

 

It's a bug definitely.  So hope they correct this very soon. Reinstalling may or may not work.

Most likely it seems to be leaning toward Disk Integrity Protect, sealing being broken.

 

I read that once you break the seal >> SIP disabled that, you have to reinstall to get a clean slate.

In that once you set csrutil authenticated-root disable and SIP to some other than enabled, have to keep these

settings.  May be a truth to this.

 

Next have to test with fsck in Recovery with switches.

 

But we do not have real Macs.  Some firmware thing?

I think for this rig in hypotectically speaking has to do with certain kexts.

BluetoothFixup.kext needs to be working and IntelBluetoothFirmware.kext 2.2.0, IntelBluetoothInjector.kext 2.2.0.

 

Since last night have the lates AirportIltwm.kext 2.20, latest BluetoothFixup.kext 2.6.2, from repo. Lilu and Friends every few weeks get updated kexts.

 

iltwm.kext no Airplay, and no Screen mirroring.  

FeatureUnlock.kext unlocks other features.  

 

Give these a shot. Try it out

 

 

 

 

 

Edited by makk
  • Like 1
Link to comment
Share on other sites

33 minutes ago, makk said:

 

Hey do you read peoples SIGNATURE?

 

I have 2 OS 11 and 12

 

 

LockDown, do you have anything  else to test this out on?

 

Besides guessing?

 

 

 

 

Hey @makk

i am reffering to my issue. Not yours nor someone else 😆

Edited by LockDown
  • Like 1
Link to comment
Share on other sites

I'm having trouble following some of what you guys are saying here. I have the same "Hash mismatch" error, and it has been around since previous versions of Monterey. The first few times I came across it, it was with the dreaded performance hit, well tbh it would be more accurately described as the machine dying entirely - eventually only the mouse cursor would move. Fortunately, I can just ignore the message.

However, I will say that I don't think my build is 100% - I have a very long boot time (even longer since 12.2), longer than Big Sur even, so it is very likely to be a misconfiguration on my part. I did it manually, I think part of the issue preventing me understanding is some of you guys have used automatic tools? I realise people feel strongly about auto/manual builds, but tbh, I'd use anything that gets the job done most effectively. 

I just had a thought - I should boot up in safe mode and see if the error appears. It's fairly reliably appearing after login at the moment, so who knows. I'll report back. 

  • Like 1
Link to comment
Share on other sites

On 2/12/2022 at 8:53 AM, inequals said:

I'm having trouble following some of what you guys are saying here. I have the same "Hash mismatch" error, and it has been around since previous versions of Monterey. The first few times I came across it, it was with the dreaded performance hit, well tbh it would be more accurately described as the machine dying entirely - eventually only the mouse cursor would move. Fortunately, I can just ignore the message.

However, I will say that I don't think my build is 100% - I have a very long boot time (even longer since 12.2), longer than Big Sur even, so it is very likely to be a misconfiguration on my part. I did it manually, I think part of the issue preventing me understanding is some of you guys have used automatic tools? I realise people feel strongly about auto/manual builds, but tbh, I'd use anything that gets the job done most effectively. 

I just had a thought - I should boot up in safe mode and see if the error appears. It's fairly reliably appearing after login at the moment, so who knows. I'll report back. 

 

It can be anything that causes the issue

 

Run this script in Terminal. search for the specific diskxxx that is the affected.

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

>> log show --debug --last boot --predicate 'process == "kernel"' > log.txt <> to dump to text file. Usually in the Home folder unless you have it set to another folder.

 

once you find the error, try to find what is the process that is causing the affect.  The culprit.

 

 

Link to comment
Share on other sites

Lockdown

 

I don't think it is specifically BlueToolFixup.kext.

 

I reinstalled Monterey fresh wipe drive new.

After updating to 12.2.1 is when the Volume Hash Mismatch appeared on new fresh install:  disk1s6

 

Had BlueToolFixup.kext loaded and running prior to the update.  Then after the updated checked the kernel logs and found

disk1s6 mismatch after the popup appeared overnight while sleeping.  

 

disk1s6 is the Snapshot 

disk1s6s1 is the other 

these above are rooted sections of the Container Volume for Monterey. These are mounted during boot and then unmounted after boot.

 

These are the steps I took to try and find the culprit: Yet not found

 

1 disabled BlueToolFixup.kext

2 disabled IntelBluetoothFirmware.kext

3 enabled SIP fully

4 enabled SIP root fully

5 Ran Diskutility FirstAid

6 booted

 

This did not workout so well.

 

These are the steps taken after the above:

 

1 in config.plst set car-active-config to 67000000

2 booted to Recovery ( as this is the only place to set SIP) 

3 set SIP to disabled

4 set SIP Root to disabled

5 Ran First Aid in Diskutility

6 Boot up.

7 Keep the Time Machine Backup Disk Online.

 

After reading and researching on the Net:

Found that in Monterey 12.2  Disk Utility has the ability now to shows APFS Snapshots from Time Machine. Also shows snapshot for the machine to boot from. Now this gets confusing .  Time Machine Snapshots are different from Bootup Snapshots. Two are not the same just to make this clear.

So if you initiated a Time Machine Backup, may need to have the Time Machine drive you backup to online --just a theory so far not proven yet.

 

What I read so far on the Net is, once a Time Machine Backup is taken, every time a file is opened, the system takes snapshots of the file, I haven't the full up to date but someone on the Net has this probably a guru of MacOS.  Time Machine Option must be set to Backup Automatically.

I do not have this option turned on at the moment. I just have the USB drive online.

 

So Right now the Time Machine Backup Disk is online but not set to automatically backup on a schedule.  This is turned off.

 

I gets complicated and to narrow down the issue have to take steps that are found to resolve the issue.

 

As of the boot have not had one issue yet.

 

 

 

 

 

Edited by makk
Link to comment
Share on other sites

A few theories

 

1 the Rooted Snapshot section(slice) disk1s6 in your case and the others disk1s5 -- all the same as this is the boot up snapshot rooted and protected.

some app tries to change it and then does succeed and the size of the snapshot then changes. 

OR

2 the snapshot is violated and but does not affect a real change to the app, but, because it was violated this gets notated as a violation and the snapshot changes in size due to this occurring. 

OR

3 a patched kext makes an update to it's file and the snapshot gets notified and this notification is logged on the snapshot.

 

The bottom line is the snapshot slice is accessed and change occurs for one reason or another.

Not necessarily corrupted?

 

Edited by makk
Link to comment
Share on other sites

9 hours ago, makk said:

Lockdown

 

I don't think it is specifically BlueToolFixup.kext.

For me, it is the BluetootlFixup.kext that is causing the mismatch on my laptop. If the mismatch hash appear, i lose bluetooth connectivity with my mouse.

If i dont install BluetoothFixup, then i have no problem, but i have to use USB mouse of course.

 

The mismatch appear if l pair my bluetooth devices intermittently and sometimes in the middle of my work.

Edited by LockDown
Link to comment
Share on other sites

19 minutes ago, LockDown said:

For me, it is the BluetootlFixup.kext that is causing the mismatch on my laptop. If the mismatch hash appear, i lose bluetooth connectivity with my mouse.

If i dont install BluetoothFixup, then i have no problem, but i have to use USB mouse of course.

 

The mismatch appear if l pair my bluetooth devices intermittently and sometimes in the middle of my work.

 

Ok weird that happens.

 

what is your SIP set to?  

 

The mismatch occurs on the snapshot partition

 

 

 

Link to comment
Share on other sites

 Share

×
×
  • Create New...