Summary:
We discovered a serious bug: booting High Sierra without System Integrity Protection (csrutil disable) possibly corrupts another mounted (unsupported) APFS2* OS Preboot volume, even when on another drive. Consequently, the corrupted OS may appear as High Sierra and check for compatibility with Board IDs compatible with High Sierra, possibly prevents booting. I've created a tool to address this problem.
This is a follow-up by the writings a while ago in another thread: https://forums.macrumors.com/thread....2207814/page-500?post=31995153#post-31995153
Ventura with High Sierra icon and data volume name
Try to boot the newer OS with
The problem:
Booting High Sierra (natively) and having APFS2 Volume(s) in the machine could possibly replace
Also, the
Where the latter is just cosmetic, the no more matching board ID in
Also we found that it replaces 3
The effect:
The following example details is for a Mac Pro 5,1: A wrong
If we set the boot-arg
A wrong
The cure:
Replacing
So we replace the Preboot files with the proper files, and the situation is fixed. If the OS cannot boot anymore because of the missing Board ID (prohibition sign or Board ID message), we need to either boot another APFS2 capable OS, mount the System volume, and replace the files or add the boot-arg:
1 Ventura SystemVersion_plist mismatch
2 found High Sierra SystemVersion.plist in Ventura Preboot
3 fix SystemVersion.plist ?
4 fixed SystemVersion.plist
... same for PlatformSupport.plist ...
5 the report when the tool is done
6 .contentDetails fix
7 .contentDetails fixed
8 a second run of Preboot fixer
9 Ventura icon and System name are back
The tool:
If it is started on an APFS1 OS (late versions of Sierra, High Sierra, Mojave), it cannot mount the APFS2 System volume to read the original plists. However, it alarms if it finds High Sierra
The wrong
You can edit the names and icons with the tool as well, even with multiple lines by entering option-return for a new line.
This is the button <proceed with label editor>. Thanks to @joevt for all the help and providing the bash functions for it.
Maybe a possible exorcism:
you can try to update the date of High Sierra's
This needs more testing but it seems it helps, preventing High Sierra from replacing files in newer System's Preboots.
Boot High Sierra and do this in
*
Changelog:
3-1-2024: first release
5-1-2024: fixed a glitch where unmouted APFS1 System Volumes would give false alarm. Confusing and cosmetical, nothing get harmed. Changed the text from
21-1-2024: first final release, as part of the Dumper package.
I placed the tools in my firmware dumper package to ease administration. They can be found in the
Using the Dumper to check and backup the bootrom is a good practice for all Macs, but that's another topic ;-)
downloader for the package (disk image password is: rom):
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
or on Github:
link to the Dumper post:
We discovered a serious bug: booting High Sierra without System Integrity Protection (csrutil disable) possibly corrupts another mounted (unsupported) APFS2* OS Preboot volume, even when on another drive. Consequently, the corrupted OS may appear as High Sierra and check for compatibility with Board IDs compatible with High Sierra, possibly prevents booting. I've created a tool to address this problem.
This is a follow-up by the writings a while ago in another thread: https://forums.macrumors.com/thread....2207814/page-500?post=31995153#post-31995153
Ventura with High Sierra icon and data volume name
Try to boot the newer OS with
High Sierra's PlatformSupport.plist
got prevented because Board ID of Mac Pro7,1 is missingThe problem:
Booting High Sierra (natively) and having APFS2 Volume(s) in the machine could possibly replace
SystemVersion.plist
and PlatformSupport.plist
in the Proboot volume of another mounted APFS2 OS with its own outdated version.Also, the
.contentDetails
and .disk_label*
files, which stores the name the BootPicker and OpenCore displays for the System name, could be renamed to the data volume name of the OS. If the Data Disk name for this system is 'Ventura - Data', High Sierra could have set the name for the System to 'Ventura - Data.'Where the latter is just cosmetic, the no more matching board ID in
PlatformSupport.plist
could make the system non-bootable.Also we found that it replaces 3
.im4
files for Macs with T2 chip.The effect:
The following example details is for a Mac Pro 5,1: A wrong
PlatformSupport.plist
file of High Sierra gives a prohibited sign, or in verbose mode, the message for an unsupported board ID of a Mac Pro 7,1 Mac-27AD2F918AE68F61
if this machine is spoofed. And shuts down hard after 30 seconds.If we set the boot-arg
-no_compat_check
in OpenCore's config.plist
, the OS ignores these issues and boots.A wrong
SystemVersion.plist
file of High Sierra gives a High Sierra icon in the OpenCore boot menu (which is just cosmetic) but could prevent the OS from updating or installing an OS reading the wrong High Sierra version 10.13.x.The cure:
Replacing
SystemVersion.plist
, PlatformSupport.plist
and the .im4
files with the proper versions. They are also stored in the CoreServices folder of the System volume and in the i386 folder of the Preboot volume.So we replace the Preboot files with the proper files, and the situation is fixed. If the OS cannot boot anymore because of the missing Board ID (prohibition sign or Board ID message), we need to either boot another APFS2 capable OS, mount the System volume, and replace the files or add the boot-arg:
-no_compat_check
to the OpenCore config.plist
.1 Ventura SystemVersion_plist mismatch
2 found High Sierra SystemVersion.plist in Ventura Preboot
3 fix SystemVersion.plist ?
4 fixed SystemVersion.plist
... same for PlatformSupport.plist ...
5 the report when the tool is done
6 .contentDetails fix
7 .contentDetails fixed
8 a second run of Preboot fixer
9 Ventura icon and System name are back
The tool:
Preboot fixer and renamer
checks all Preboot folders for matching SystemVersion / PlatformSupport plists and .im4
files and asks for replacing them if they don't match.If it is started on an APFS1 OS (late versions of Sierra, High Sierra, Mojave), it cannot mount the APFS2 System volume to read the original plists. However, it alarms if it finds High Sierra
SystemVersion.plist
files in APFS2 Preboots.The wrong
.contentDetails
and the .disk_label*
icon drawn by the native Apple boot picker can be rebuilt by the tool as well.You can edit the names and icons with the tool as well, even with multiple lines by entering option-return for a new line.
This is the button <proceed with label editor>. Thanks to @joevt for all the help and providing the bash functions for it.
the names in the boot picker could be renamed by the preboot fixer and renamer tool
The @joevt multiline names are ESPs, there is also a tool for renaming ESPs in the Dumper package
The @joevt multiline names are ESPs, there is also a tool for renaming ESPs in the Dumper package
Maybe a possible exorcism:
you can try to update the date of High Sierra's
SystemVersion.plist
This needs more testing but it seems it helps, preventing High Sierra from replacing files in newer System's Preboots.
Boot High Sierra and do this in
Terminal
Code:
sudo touch -t 203009110327 /System/Library/CoreServices/SystemVersion.plist
sudo touch -t 203009042358 /System/Library/CoreServices/PlatformSupport.plist
*
APFS1: APFS Systems with one volume
APFS2: APFS Systems with a separated system and data volume
Changelog:
3-1-2024: first release
5-1-2024: fixed a glitch where unmouted APFS1 System Volumes would give false alarm. Confusing and cosmetical, nothing get harmed. Changed the text from
Comparing to the System Volume is not possible on this OS
to Can not compare (System Volume not mounted)
as an unmounted APFS1 System Volume is giving the same status as a APFS2 System Volume what could not be mounted on old APFS1 OS.21-1-2024: first final release, as part of the Dumper package.
I placed the tools in my firmware dumper package to ease administration. They can be found in the
Readme & other tools
folder.Using the Dumper to check and backup the bootrom is a good practice for all Macs, but that's another topic ;-)
downloader for the package (disk image password is: rom):
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
or on Github:
Macschrauber-s-Rom-Dump/Rename_and_repair_preboot.md at main · Macschrauber/Macschrauber-s-Rom-Dump
A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4.1 / 5.1 - Macschrauber/Macschrauber-s-Rom-Dump
github.com
GitHub - Macschrauber/Macschrauber-s-Rom-Dump: A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4.1 / 5.1
A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4.1 / 5.1 - Macschrauber/Macschrauber-s-Rom-Dump
github.com
link to the Dumper post:
Healthy NVRAM normal behaviour on 4,1->5,1 machines
Macschrauber's Rom Dump I needed to encrypt the disk image as DropBox has flagged it for containing Flashrom. The password is rom. What's new in the latest versions: Update from 20-2-2024 -> checking Fsys for missing items or wrong order sometimes they get into the wrong order or items...
forums.macrumors.com
Last edited: