Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
I don't think High Sierra can mount Big Sur, Monterey, or Ventura but I think it might do stuff to the Preboot volumes. I can still boot them using OpenCore of OCLP.

Here's a script to look at all the SystemVersion.plist files of the Recovery and Preboot volumes:
Code:
source "/Volumes/Apps/File Utilities/diskutil pdisk fdisk gpt/DiskUtil.sh"

mountEFIpartitions
mountRecoveryHDpartitions
mountRecoveryPartitions
mountPrebootPartitions

IFS=$'\n'
for thefile in $(find /Volumes/Preboot* /System/Volumes/Preboot* /Volumes/Recovery* -name SystemVersion.plist 2> /dev/null); do
	version="$(plutil -p "${thefile}" | grep ProductVersion | sed -E 's/.* => "(.*)"$/\1/')"
	theuuid="$(perl -nE 'if (m|.*/(\w{8}-\w{4}-\w{4}-\w{4}-\w{12})/.*|) { print $1 ; }' <<< "$thefile")"
	thedev="$(df -P "$thefile" | perl -nE 'if (m|dev/([^ ]+) .*|) {print $1 }')"
	getdiskinfo "$thedev" "thefile_"
	if [[ -n $theuuid ]]; then
		getdiskinfo "$theuuid" "parent_"
		roles="$(getapfsroles "$parent_APFSContainerReference")"
		role="$(sed -nE "/.*_(.*)=$parent_DeviceIdentifier/s//\1/p" <<< "$roles")"
		getdiskinfo "$parent_APFSPhysicalStore" "preboot_container_"
		getdiskinfo "$preboot_container_ParentWholeDisk" "parent_wholedisk_"
		echo $version ${thefile_VolumeName}_${parent_VolumeName}_${role}_$(tr -d '\n" ' <<< "$parent_wholedisk_MediaName")_$(tr -d '\n" ' <<< "$parent_BayName") "$thefile" | sed -E 's/ - Data_Data/_Data/'
	else
		wholedisk="${thedev%s*}"
		slice="${thedev##*s}"
		getdiskinfo "${wholedisk}s$((slice-1))" "parent_"
		getdiskinfo "$wholedisk" "parent_wholedisk_"
		echo $version ${thefile_VolumeName// /}_${parent_VolumeName}_$(tr -d '\n" ' <<< "$parent_wholedisk_MediaName")_$(tr -d '\n" ' <<< "$parent_BayName") "$thefile"
	fi
done | sort -V

Here's the result:
Code:
10.7.4 RecoveryHD_Lion_TOSHIBAMD04ACA500_Bay1 /Volumes/Recovery HD4/com.apple.recovery.boot/SystemVersion.plist
10.8 RecoveryHD_MountainLion_TOSHIBAMD04ACA500_Bay1 /Volumes/Recovery HD3/com.apple.recovery.boot/SystemVersion.plist
10.9 RecoveryHD_Mavericks_TOSHIBAMD04ACA500_Bay1 /Volumes/Recovery HD2/com.apple.recovery.boot/SystemVersion.plist
10.12.2 RecoveryHD_Sierra_OWCMercuryEXTREMEPro6GSSD_Bay3 /Volumes/Recovery HD/com.apple.recovery.boot/SystemVersion.plist
10.13.4 RecoveryHD_HighSierra_OWCMercuryEXTREMEPro6GSSD_Bay3 /Volumes/Recovery HD1/com.apple.recovery.boot/SystemVersion.plist
10.13.6 Preboot_BigSur_Data_OWCMercuryEXTREMEPro6GSSD_Bay3 /Volumes/Preboot2/CA18DE49-ECFD-49C2-A293-0B036B7AFC50/System/Library/CoreServices/SystemVersion.plist
10.13.6 Preboot_Monterey_Data_OWCMercuryEXTREMEPro6GSSD_ /System/Volumes/Preboot/46F1EA55-9F1B-4B09-963E-D17066406B13/System/Library/CoreServices/SystemVersion.plist
10.14.6 Preboot_Mojave__OWCMercuryEXTREMEPro6GSSD_Bay3 /Volumes/Preboot/10D5CE8C-43FE-43F2-8089-DAEDF6485644/System/Library/CoreServices/SystemVersion.plist
10.14.6 Recovery_Mojave__OWCMercuryEXTREMEPro6GSSD_Bay3 /Volumes/Recovery/10D5CE8C-43FE-43F2-8089-DAEDF6485644/SystemVersion.plist
10.15.7 Preboot_Catalina_System_OWCMercuryEXTREMEPro6GSSD_Bay3 /Volumes/Preboot3/23DC9494-8D50-4085-A389-493878A2404B/System/Library/CoreServices/SystemVersion.plist
10.15.7 Recovery_Catalina_System_OWCMercuryEXTREMEPro6GSSD_Bay3 /Volumes/Recovery4/23DC9494-8D50-4085-A389-493878A2404B/SystemVersion.plist
11.7.2 Recovery_BigSur_Data_OWCMercuryEXTREMEPro6GSSD_Bay3 /Volumes/Recovery3/CA18DE49-ECFD-49C2-A293-0B036B7AFC50/SystemVersion.plist
12.6.2 Recovery_Monterey_Data_OWCMercuryEXTREMEPro6GSSD_ /Volumes/Recovery2/46F1EA55-9F1B-4B09-963E-D17066406B13/SystemVersion.plist
13.1 Preboot_Monterey_Data_OWCMercuryEXTREMEPro6GSSD_ /System/Volumes/Preboot/46F1EA55-9F1B-4B09-963E-D17066406B13/cryptex1/proposed/SystemVersion.plist
13.1 Preboot_Ventura_Data_OWCMercuryEXTREMEPro6GSSD_ /Volumes/Preboot1/21F3EFB2-4CA0-4890-9A36-2CDB3D388762/System/Library/CoreServices/SystemVersion.plist
13.1 Preboot_Ventura_Data_OWCMercuryEXTREMEPro6GSSD_ /Volumes/Preboot1/21F3EFB2-4CA0-4890-9A36-2CDB3D388762/cryptex1/current/SystemVersion.plist
13.1 Recovery_Ventura_Data_OWCMercuryEXTREMEPro6GSSD_ /Volumes/Recovery1/21F3EFB2-4CA0-4890-9A36-2CDB3D388762/SystemVersion.plist

See how the preboot of BigSur and Monterey have a 10.13.6 HighSierra version? I hope they'll go back to normal when I update them to the latest version. Then I'll be sure to backup those preboot folders so I can see when they get modified.
I'm not sure why Monterey preboot has a 13.1 proposed.
I don't know why I don't have a Recovery HD for 10.10 and 10.11 but I don't usually use Recovery partitions. I have macOS installer partitions for BigSur, Monterey, and Ventura since it's faster to boot/install from SSD instead of USB flash drive and earlier macOS versions no longer get updates.
 
  • Like
Reactions: Macschrauber
Edit: Did reverse test to double check. After booting High Sierra once natively it wrote its PlatformSupport.plist and SystemVersion.plist into Monterey /Preboot, also it changed .contentDetails back to "Monterey - Data".
For the .contentDetails files, my DiskUtil.sh script uses sudo chflags schg to protect those files so they don't get modified.
But you probably have to undo that with sudo chflags noschg,nouchg when it's time to do a macOS update so no errors happen when the installer wants to update disk labels.
 
OK, so does that happen the instant the newer APFS drives are mounted by High Sierra? Is there a way to prevent it, rather than repairing around it (other than just never booting to older systems)?

In theory you can force s.i.p. on when booting High Sierra, maybe write protect those two files like @joevt suggested with .contentdetails.

Need to try, as I don't use High Sierra mixed that way the cure with copying back is enough for me. A few posts later I posted an AppleScript to automate this.
 
  • Like
Reactions: mattspace
can you run VIM on your Monterey install to write the fstab to the High Sierra install, so it applies when HS is running?
Well, wouldn't it ruin the idea of not mounting one OS from another OS? I would go with a manual route of running the command from within each OS installation. The UUIDs are set forever (as in: until reformat), so best would be to write down all the UUIDs that you want to exclude from mounting in fstab and add them manually to respective fstabs in each OS (just don't exclude the disk of the OS you are on at the moment by accident).
 
  • Like
Reactions: mattspace and cdf
can you run VIM on your Monterey install to write the fstab to the High Sierra install, so it applies when HS is running?
The /etc folder always points to the /private/etc of the root.

For Catalina and later, /etc is on the System role apfs volume and it is a link to /private/etc on the Data role.

/private/etc is also on the System role but it represents the thing on the Data role somehow? Is there a command that shows this relationship?

Code:
stat -f "%i" "/Volumes/Ventura/etc"
1152921500312421235

stat -f "%i" "/Volumes/Ventura/etc/"
129765

stat -f "%i" "/Volumes/Ventura/private/etc"
129765

stat -f "%i" "/Volumes/Ventura - Data/private/etc"
129765

df -P "/Volumes/Ventura/etc"
Filesystem   512-blocks     Used Available Capacity  Mounted on
/dev/disk7s1  937487664 39141096 869344056     5%    /Volumes/Ventura - Data

df -P "/Volumes/Ventura/etc/"
Filesystem   512-blocks     Used Available Capacity  Mounted on
/dev/disk7s1  937487664 39141096 869344056     5%    /Volumes/Ventura - Data

df -P "/Volumes/Ventura/private/etc"
Filesystem   512-blocks     Used Available Capacity  Mounted on
/dev/disk7s1  937487664 39141096 869344056     5%    /Volumes/Ventura - Data

df -P "/Volumes/Ventura - Data/private/etc"
Filesystem   512-blocks     Used Available Capacity  Mounted on
/dev/disk7s1  937487664 39141096 869344056     5%    /Volumes/Ventura - Data


These folders are all writable with root privileges (using sudo)
Code:
IFS=$'\n'
for thedir in $(ls -d /Volumes/*/private/etc/ /System/Volumes/*/private/etc/); do
	echo "$thedir" > /tmp/testing1.txt
	sudo cp /tmp/testing1.txt "$thedir" && printf "read/write" || printf "read-only"
	echo " $thedir"
done

read/write /System/Volumes/Data/private/etc/
read/write /Volumes/BigSur - Data/private/etc/
read/write /Volumes/Catalina - Data/private/etc/
read/write /Volumes/Catalina/private/etc/
read/write /Volumes/ElCapitan/private/etc/
read/write /Volumes/HighSierra/private/etc/
read/write /Volumes/Leopard/private/etc/
read/write /Volumes/Lion/private/etc/
read/write /Volumes/Mavericks/private/etc/
read/write /Volumes/Mojave/private/etc/
read/write /Volumes/Monterey/private/etc/
read/write /Volumes/MountainLion/private/etc/
read/write /Volumes/Sierra/private/etc/
read/write /Volumes/SnowLeopard/private/etc/
read/write /Volumes/Tiger/private/etc/
read/write /Volumes/Ventura - Data/private/etc/
read/write /Volumes/Ventura/private/etc/
read/write /Volumes/Yosemite/private/etc/

Note that I'm running Monterey in this test. I'm not sure why BigSur system role isn't mounting.

Instead of using VIM, you can use a text editor like BBEdit.app that knows how to save to a folder that requires root privileges.

Or you can use the cp command.

Code:
source "/Volumes/Apps/File Utilities/diskutil pdisk fdisk gpt/DiskUtil.sh"
for thedisk in "BigSur" "Monterey" "Ventura"; do
	getdiskinfo "$thedisk" "thedisk_"
	echo "# $thedisk"
	echo "UUID=$thedisk_VolumeUUID none apfs rw,noauto"
done > /tmp/fstab.txt
sudo cp /tmp/fstab.txt /Volumes/HighSierra/etc/fstab
cat /Volumes/HighSierra/etc/fstab

# BigSur
UUID=8D8F915E-D780-4231-9B04-9B3AEB1CF14E none apfs rw,noauto
# Monterey
UUID=9EE87C48-CB1B-4C90-B262-F577EC54A879 none apfs rw,noauto
# Ventura
UUID=D5AF0B76-D322-40FB-AB5A-0FE0ACD2358E none apfs rw,noauto

I wonder if I need to add the Data role UUIDs as well? I'll find out one day when I fix my Preboot volumes (after updating Big Sur, Monterey, Ventura) and try booting HighSierra.
 
The UUIDs are set forever (as in: until reformat), so best would be to write down all the UUIDs that you want to exclude from mounting in fstab and add them manually to respective fstabs in each OS (just don't exclude the disk of the OS you are on at the moment by accident).

Ahh ok that's the bit I was missing - I was trying to figure out how to get the UUID of a drive, without mounting it and potentially exposing it to the issue.

I suppose the safest way to do it, is physically pull the drives, and only have one installed at a time to write its fstab?
 
Instead of using VIM, you can use a text editor like BBEdit.app that knows how to save to a folder that requires root privileges.

barebones are going a big discount right now, might be time to snag a copy if it means I don't have to use Vi/Vim any more :)
 
Ahh ok that's the bit I was missing - I was trying to figure out how to get the UUID of a drive, without mounting it and potentially exposing it to the issue.
Not forgetting that UUIDs are for volumes rather than drives, in my understanding there is no way to exclude a volume on same drive before ever mounting it, because these other macOS volumes are automount by default. :-(

Probably worth adding that from what I've seen (however not only or mainly on Mac Pro) that excluding other macOS APFS volumes from automounting completely solves the 'Volume hash mismatch' message problem - but does not completely resolve the Monterey slowdowns that were assumed to be directly connected to this.
 
Last edited:
  • Like
Reactions: mattspace
observed a mad behaviour of High Sierra:

it has overwritten SystemVersion.plist
I have HS, Catalina and Monterey. When mounting the Preboot volume there are 2 subfolders in the Catalina preboot and only the plist in one of them is modified:
Code:
cat /Volumes/Preboot1/77E29688-6993-46E0-83D8-54157C163576/System/Library/CoreServices/SystemVersion.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>ProductBuildVersion</key>
    <string>19H15</string>
    <key>ProductCopyright</key>
    <string>1983-2020 Apple Inc.</string>
    <key>ProductName</key>
    <string>Mac OS X</string>
    <key>ProductUserVisibleVersion</key>
    <string>10.15.7</string>
    <key>ProductVersion</key>
    <string>10.15.7</string>
    <key>iOSSupportVersion</key>
    <string>13.6</string>
</dict>
</plist>
HSs-Mac-Pro:FileNVRAM hs$ cat /Volumes/Preboot1/FEB0809C-57E4-41D1-A1E4-CE9CB14EE96B/System/Library/CoreServices/SystemVersion.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>ProductBuildVersion</key>
    <string>17G66</string>
    <key>ProductCopyright</key>
    <string>1983-2018 Apple Inc.</string>
    <key>ProductName</key>
    <string>Mac OS X</string>
    <key>ProductUserVisibleVersion</key>
    <string>10.13.6</string>
    <key>ProductVersion</key>
    <string>10.13.6</string>
</dict>
</plist>

The plist of the Monterey volume shows actually Ventura version rather than Monterey:
Code:
cat /Volumes/Preboot/*/System/Library/CoreServices/SystemVersion.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>BuildID</key>
    <string>6B08394E-D0A4-11ED-8DAB-1CA630367858</string>
    <key>ProductBuildVersion</key>
    <string>22E261</string>
    <key>ProductCopyright</key>
    <string>1983-2023 Apple Inc.</string>
    <key>ProductName</key>
    <string>macOS</string>
    <key>ProductUserVisibleVersion</key>
    <string>13.3.1</string>
    <key>ProductVersion</key>
    <string>13.3.1</string>
    <key>iOSSupportVersion</key>
    <string>16.4</string>
</dict>
</plist>

System Software Overview:
System Version: macOS 12.6.5 (21G531)
Kernel Version: Darwin 21.6.0
Boot Volume: Monterey
Boot Mode: Normal
Computer Name: Mont’s Mac Pro
User Name: Mont (mont)
Secure Virtual Memory: Enabled
System Integrity Protection: Disabled
Time since boot: 2 minutes
 
Last edited:
I've just updated to OC 0.9.2, but seem to be having an issue with the BootPicker: It's text-only! I suppose something in my config.plist is wrong. I initially thought it had something to do with the new (?) InitialMode parameter and changed that from Auto to Graphics, but to no avail. I hope someone here can point out where my error is. TIA.
 

Attachments

  • config.plist.zip
    5 KB · Views: 64
I've just updated to OC 0.9.2, but seem to be having an issue with the BootPicker: It's text-only! I suppose something in my config.plist is wrong. I initially thought it had something to do with the new (?) InitialMode parameter and changed that from Auto to Graphics, but to no avail. I hope someone here can point out where my error is. TIA.
Did you check if OpenCanopy (and the associated images) is actually there?
 
I've just updated to OC 0.9.2, but seem to be having an issue with the BootPicker: It's text-only! I suppose something in my config.plist is wrong. I initially thought it had something to do with the new (?) InitialMode parameter and changed that from Auto to Graphics, but to no avail. I hope someone here can point out where my error is. TIA.
Hi @PeterHolbrook
Have you tried replacing "auto" in "PickerVariant" with the exact path of the OpenCanopy images folder? "Acidanthera\GoldenGate" for example? or if you have a custom theme, make sure you check the exact name of the folder used.

Another thing that has nothing to do with it:
After checking your config.plist file your base64 value for the VMM flag is not correct.
they are: AAAAAAAAAAAAAAAAAAAAAA==
should be: AAAAAAAAAAAAAACAAAAAAA==

In this case you should only activate VMM for installation/update and deactivate (do not put anything as value) in your config.plist located in the EFI->OC folder of your boot disc
 
  • Like
Reactions: PeterHolbrook
Did you check if OpenCanopy (and the associated images) is actually there?
You are absolutely right! My entire Resources folder had vanished! I must inadvertently erased it this morning when modifying my experimental USB pen drive. Doh!
 
Last edited:
I updated from OC 0.9.1 to 0.9.2 and since then my settings have gone haywire in the Finder(Monterey).
  • In the volume view on the desktop, the hard disk checkbox is unchecked and all volumes except the startup volume are hidden.
  • Desktop display option settings revert to default.
The timing of this occurrence is irregular.

I would also like to know one more thing.
In installing EnableGop, the firmware flush tool uses DirectHW, but is it not possible to complete the EnableGop installation procedure in Monterey? I always boot with Mojave to complete the EnableGop installation process.
 
In installing EnableGop, the firmware flush tool uses DirectHW, but is it not possible to complete the EnableGop installation procedure in Monterey? I always boot with Mojave to complete the EnableGop installation process.

You need to approve directhw.kext in security settings. If you use my Dumper it will tell you ;-)
 
Interesting..
Just been offered the Big Sur 11.7.7 update without enabling VMM flag in the config.plist:

Screenshot 2023-05-19 at 12.24.23.png

But with Monterey (on the same system), there were no offers of updates until I enabled the VMM flag.
 
Interesting..
Just been offered the Big Sur 11.7.7 update without enabling VMM flag in the config.plist:

View attachment 2204132

But with Monterey (on the same system), there were no offers of updates until I enabled the VMM flag.
This is normal if use the correct firmware feature mask.

For Monterey, because secure boot also related, therefore, a little bit different story. But if you want to, you can also make Monterey update without VMM.
 
  • Like
Reactions: MacNB2
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.