MP 1,1-5,1 OCLP 0.6.4/Monterey broken by booting High Sierra

[GoJohnGo]

I've been having an interesting issue the past couple of week, and have narrowed down some ways to replicate it.

I have a cMP with firmware update 144.0.0.0.0, several HDDs, and two NVM.e drives, one with High Sierra (where I still do most of my work) and one with Monterey, installed via OCLP 0.6.4. When I install Monterey, it works fine, and stays working fine through multiple cold boots. However, when I use the option key and boot High Sierra, I get an "Incompatible Disk" warning after successfully booting High Sierra, telling me that it can't read the Monterey APFS partition. Ok, everything else is fine.
However, when I boot again and use the option key and the OCLP EFI to boot Monterey, the primary partition on the Monterey NVM.e drive no longer shows up and only the "-Data" version shows, which is not bootable. If I put in my Monterey install drive, I can boot to Recovery mode and Disk Tools shows the normal partition present, so it hasn't gone anywhere. It's just that booting High Sierra seems to do something to the Monterey drive such that OCLP EFI can no longer see the primary partition. I've also found that command-option-P-R will induce the same behavior. I've used OpenCore Configurator to verify that OCLP is on only one EFI partition (the Monterey NVM.e drive), and have run First Aid multiple times, but am not sure what to try next. Doing a reinstall of Monterey does fix everything, at least until I boot High Sierra again, but that process is getting a little tedious.

What else should I try?

 

[haralds]

Ignore. High Sierra and Mojave do not understand the updated APFS format of the newer systems.

I have seen the issue with only the -Data disk showing but was able to boot under OCLP using that disk anyway.

 

[MacNB2]

Ignore. High Sierra and Mojave do not understand the updated APFS format of the newer systems.

I have seen the issue with only the -Data disk showing but was able to boot under OCLP using that disk anyway.

High Sierra is known to corrupt other macOS volumes on due to APFS incompatibility if you multi-boot different macOS's.
It does a little "more damage" than than just changing boot volume name. After booting High Sierra, then booting say Big Sur, see here as to what it does and how to "repair" the corruption.

 

[Macschrauber]

I've been having an interesting issue the past couple of week, and have narrowed down some ways to replicate it.

I have a cMP with firmware update 144.0.0.0.0, several HDDs, and two NVM.e drives, one with High Sierra (where I still do most of my work) and one with Monterey, installed via OCLP 0.6.4. When I install Monterey, it works fine, and stays working fine through multiple cold boots. However, when I use the option key and boot High Sierra, I get an "Incompatible Disk" warning after successfully booting High Sierra, telling me that it can't read the Monterey APFS partition. Ok, everything else is fine.
However, when I boot again and use the option key and the OCLP EFI to boot Monterey, the primary partition on the Monterey NVM.e drive no longer shows up and only the "-Data" version shows, which is not bootable. If I put in my Monterey install drive, I can boot to Recovery mode and Disk Tools shows the normal partition present, so it hasn't gone anywhere. It's just that booting High Sierra seems to do something to the Monterey drive such that OCLP EFI can no longer see the primary partition. I've also found that command-option-P-R will induce the same behavior. I've used OpenCore Configurator to verify that OCLP is on only one EFI partition (the Monterey NVM.e drive), and have run First Aid multiple times, but am not sure what to try next. Doing a reinstall of Monterey does fix everything, at least until I boot High Sierra again, but that process is getting a little tedious.

What else should I try?

High Sierra booting may overwrite some plist

https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/post-31995153

and a repair method:

https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/post-31998000

 

[Dayo]

Everyone running HiSierra or Mojave, both of which are HFS+ faking APFS, should be converting them to "pure" HFS+ to facilitate co-existence with real APFS installations.

Ditching the fake APFS costume just requires cloning to an HFS+ volume once on the last available update.
No more hassle afterwards.

 

[MacNB2]

Everyone running HiSierra or Mojave, both of which are HFS+ faking APFS, should be converting them to "pure" HFS+ to facilitate co-existence with real APFS installations.

Ditching the fake APFS costume just requires cloning to an HFS+ volume once on the last available update.
No more hassle afterwards.

I am running High Sierra from a HDD Spinner formatted as HFS+ and it still "corrupts" Big Sur or Monterey.

 

[Dayo]

I am running High Sierra from a HDD Spinner formatted as HFS+ and it still "corrupts" Big Sur or Monterey.

In what way does it do so exactly out of curiousity?
Do you mean a HFS+ installation still accesses APFS preboot volumes and writes/amends stuff there?

ANSWER:
Yes, HiSierra HFS+ can read APFS: https://support.apple.com/HT208018
Should however be read only but some bug or change of policy might have allowed write access with bad results.
Converting Mojave still good idea since Apple probably never added the HFS+ "bridging" there.
I would still always convert HiSierra regardless myself.

 

[MacNB2]

In what way does it do so exactly out of curiousity?
Do you mean a HFS+ installation still accesses APFS preboot volumes and writes/amends stuff there?

ANSWER:
Yes, HiSierra HFS+ can read APFS: https://support.apple.com/HT208018
Should however be read only but some bug or change of policy might have allowed write access with bad results.
Converting Mojave still good idea since Apple probably never added the HFS+ "bridging" there.
I would still always convert HiSierra regardless myself.

As mentioned already here and "repairs" mentioned in following posts after that.
Most likely a bugs in High Sierra as Apple probably never envisioned (or ever tested) multi-booting on the same system.