Is there an opencore fix for this APFS issue?

[Ginger Geek]

Hi.

 

I'm wondering if there are any third party workarounds for High sierra unsupported APFS...

 

 

 

[Slice]

No, HighSierra has very initial support for APFS and we can't improve it.

[cankiulascmnfye]

16 minutes ago, Ginger Geek said:

Hi.

 

I'm wondering if there are any third party workarounds for High sierra unsupported APFS...

 

 

 

 

I have this issue on my notebook as well, if I run High Sierra. Maybe it goes away if you format the disk from within diskutiliy during installation which I've never tried.

[joevt]

High Sierra also likes to modify the Preboot partitions of other macOS APFS containers. Is there anyway around that?

 

This happens even if your High Sierra partition is HFS+.

When this happens, Open Core will show the Data volume as the boot item for that macOS version instead of what was in the Preboot volume. So you will still be able to boot the later macOS versions.

 

You can look at the SystemVersion.plist file in each Preboot volume to see if it's been changed to 10.13.

 

source "/Volumes/Apps/File Utilities/diskutil pdisk fdisk gpt/DiskUtil.sh"
mountPrebootPartitions

IFS=$'\n'
for thefile in $(
    {
        find /Volumes/Preboot*/*/System/Library/CoreServices/SystemVersion.plist
        find /System/Volumes/Preboot*/*/System/Library/CoreServices/SystemVersion.plist
    } 2> /dev/null
); do
    theuuid="$(perl -pE "s|.*/([-0-9A-F]{36}).*|\1|" <<< "$thefile")"
    diskutil info "${theuuid}" | perl -nE 'if (/Volume Name:\s+(.*)/) { print $1 . "\n" }'
    echo "$thefile"
    plutil -p "$thefile"
done

[cankiulascmnfye]

@joevt True. I had this issue once on my Desktop before. I had Big Sur installed on one SSD. And after installing High Sierra on another physical SSD, I could no longer boot into Big Sur without -no_compat_check. After re-installed Big Sur on top of the previous install it worked again. I once found a guide to fix this via Terminal, but I can't find it any more. Worst thing about it: nobody believed me at first that this is a thing.

 

A part of the Terminal command does not work:

 

"source: no such file or directory: /Volumes/Apps/File Utilities/diskutil pdisk fdisk gpt/DiskUtil.sh
zsh: command not found: mountPrebootPartition"

Edited December 4, 2023 by cankiulascmnfye

[joevt]

18 hours ago, cankiulascmnfye said:

A part of the Terminal command does not work:

 

"source: no such file or directory: /Volumes/Apps/File Utilities/diskutil pdisk fdisk gpt/DiskUtil.sh
zsh: command not found: mountPrebootPartition"

You have to download DiskUtil.sh, then change that command to the path of that file.

 https://gist.github.com/joevt/6d7a0ede45106345a39bdfa0ac10ffd6

 

[ArcaneRhapsody]

@joevt This seems to be a known quirk when dealing with multiple macOS APFS containers. Your script for checking the SystemVersion.plist in each Preboot volume is a smart approach to identifying changes.

 

I've found this other thread at 

 that seems to be related to the issue. Is it? 

[cankiulascmnfye]

@joevt

 

After I downloaded that Utils.sh script and adjusted the path in the terminal command, another message pops-up:

 

# Download and build bless from https://github.com/joevt/bless , then update the path of directbless defined in DiskUtil.sh.

 

Can you buld something that just works by double-clicking, so that does what it's supposed to do?

 

Edited December 5, 2023 by cankiulascmnfye

[joevt]

13 hours ago, cankiulascmnfye said:

@joevt

 

After I downloaded that Utils.sh script and adjusted the path in the terminal command, another message pops-up:

 

# Download and build bless from https://github.com/joevt/bless , then update the path of directbless defined in DiskUtil.sh.

 

Can you buld something that just works by double-clicking, so that does what it's supposed to do?

 

You can ignore that message since you don't need bless to mount partitions.

Anyway, that script just lists info from your Preboot partitions. You can check the info manually.

 

[joevt]

16 hours ago, ArcaneRhapsody said:

@joevt This seems to be a known quirk when dealing with multiple macOS APFS containers. Your script for checking the SystemVersion.plist in each Preboot volume is a smart approach to identifying changes.

 

I've found this other thread at 

 that seems to be related to the issue. Is it? 

I've never seen that before so I don't think it's related. It seems that just booting into High Sierra causes changes to Preboot volumes but I haven't checked time stamps and logs to see exactly when it happens. One day I'll update my macOS installs (Big Sur and later), backup their Preboot volumes and bless info, then boot into High Sierra to see what happens when.

[Slice]

If you will have two partitions, one with BigSur and other with HighSierra, then booting High Sierra you will see the warning as in the first post telling that High Sierra can't understand APFS features used in Big Sur.

Whatever you may do.

[MacNB]

I also had this issue (of High Sierra corrupting "newer" macOS APFS volumes).

Here's the thread and possible workarounds on macroumors.

Essentially, you need to backup your SystemVersion.plist, PlatformSupport.plist and the .disklables in Preboot volume of Big Sur, etc.

Then if you boot High Siera on the same system and it corrupts those files, then you simply copy back those corrupted files.

 

[LockDown]

this was also my problem long time ago.

[joevt]

More info on the High Sierra issue at 
https://forums.macrumors.com/threads/high-sierra-booting-possibly-corrupts-newer-systems-fix-and-description.2415320/