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.
Bildschirmfoto 2022-07-13 um 07.26.10.jpg


12.5 RC updated and patched on MacBook Pro 4,1.
Runs just as well as with the latest betas, but still some issues exist. Beach balling without animation for Apps saving files (preview i.e.). Frozen Apps when invoking them. Spotlight not finding anything. Will try on a fresh user account to see if its a config problem.
 
  • Like
Reactions: K two
I suggest not to upgrade to RC 12.5 who has iMac 27-inch late 2013.
I have not installed 12.5, but a friend asked me for help because his iMac is blocked at Login.
Before updating to 12.5 I will wait for official version and maybe wait some more until I am sure that all the issues have been solved.
 
I suggest not to upgrade to RC 12.5 who has iMac 27-inch late 2013.
I have not installed 12.5, but a friend asked me for help because his iMac is blocked at Login.
Before updating to 12.5 I will wait for official version and maybe wait some more until I am sure that all the issues have been solved.
Seems to be Kepler metal GPU related. If so, not an Apple bug but has to be solved with upcoming OCLP release.
 
  • Like
Reactions: RogueB and OKonnel
/System/Library/CoreServices/boot.efi is normally on an APFS partition, not the ESP. For a standard install, you should not need it where it is shown above.

Someone might ask, "how could a file on an APFS partition be used to boot macOS, if no APFS driver is present initially"? When using OpenCore the answer is, by using the EnableJumpstart option, which implements an Apple-defined method to read and start an APFS UEFI driver, read in a defined way from raw data blocks, which are always stored in each APFS partition.

On some non-Macs (VM, hacks) without OpenCore, I guess you might need it there to get the boot process going.
 
  • Like
Reactions: perez987
/System/Library/CoreServices/boot.efi is normally on an APFS partition, not the ESP. For a standard install, you should not need it where it is shown above.

Someone might ask, "how could a file on an APFS partition be used to boot macOS, if no APFS driver is present initially"? When using OpenCore the answer is, by using the EnableJumpstart option, which implements an Apple-defined method to read and start an APFS UEFI driver, read in a defined way from raw data blocks, which are always stored in each APFS partition.

On some non-Macs (VM, hacks) without OpenCore, I guess you might need it there to get the boot process going.
/System/Library/CoreServices/boot.efi is added by OCLP. I'm not sure what the benefit is. The contents are not sufficient for the Monterey Startup Disk preferences panel but maybe they are sufficient for other boot pickers? It could exist so that you don't need /EFI/BOOT/bootx64.efi?
 
  • Like
Reactions: perez987
/System/Library/CoreServices/boot.efi is added by OCLP. I'm not sure what the benefit is. The contents are not sufficient for the Monterey Startup Disk preferences panel but maybe they are sufficient for other boot pickers? It could exist so that you don't need /EFI/BOOT/bootx64.efi?
Ah! Really? Idk exactly why it would be - above is my current understanding - but there's always more to learn! Maybe someone OCLP can clarify the advantage?
 
Code:
# OpenCore Legacy Patcher changelog
...
## 0.0.18
...
- Move BOOTx64.efi to System/Library/CoreServices/ to support GPT BootCamp installs

@joevt - Okay, that's the reasoning - not convinced that I'm convinced ... but I guess it may make life easier! It's an alternative place for OpenCore's BOOTx64.efi, to allow it to co-exist with Windows, by the sound of it. Certainly still not required, on a 'standard'/vanilla OC install (not even for happy co-existence with Windows, in my experience) - but that would explain where it appeared from and why. Thanks.
 
  • Like
Reactions: perez987
Think I have figured out the issue.

Opencore on my startup disk doesn't have SIP fully disabled, even though I selected all the options, rebuilt and installed Opencore... I tried doing it again, and it still only has the 2 settings that are preset in the setting selected.

Might have to start again with a fresh install, maybe after the next update.

Edited* Since I found what was causing the issue with not being able to put the kext file in the Extension's folder, I deleted what was here as it doesn't matter any more and I still can't remove the pointless attachment... Sorry.
 

Attachments

  • ExtFolder.png
    ExtFolder.png
    108.6 KB · Views: 53
Last edited:
/System/Library/CoreServices/boot.efi is normally on an APFS partition, not the ESP.
Correct but small correction is that it is normally on the MacOS volume and is not APFS related. That is, it is the default MacOS loader path and been like that from HFS+ based MacOS versions.

HFS+ volume with this path added is what rEFInd calls "OwnHFS" type installation. This appeared in rEFInd quite a few years ago now (I think around Yosemite).

It could exist so that you don't need /EFI/BOOT/bootx64.efi?
Exactly. Mac firmware will search that default loader path for a loader if it does not find a UEFI loader, /EFI/BOOT/bootx64.efi. This is what rEFInd took advantage of as it will boot the boot.efi file it finds and doesn't vet it.

Have to say that AFAIK, it searches for the path on normal volumes and not ESPs as @Bmju hinted. I doubt it also checks ESP as MacOS never creates such a path. Could be that OCLP defines things to match the default Mac path for convenience. Possibly to simiplfy moving things to a USB stick.
 
  • Like
Reactions: Bmju
Seems to be Kepler metal GPU related. If so, not an Apple bug but has to be solved with upcoming OCLP release.
I hope dear @Larsvonhier...; but if it's a Kext problem it will be very hard to fix...
So! Apple sadly started treacherously to block any unsupported Mac where Monterey works very well and sometimes even almost better than some new basic Macs, officially supported; as in my case.
 
Guess my 13,2 iMac is stuck on 12.5 beta 2 until further notice… oh well, we had a good run… my other Mac’s seem fine on RC 12.5 so far at least
 
  • Like
Reactions: Larsvonhier
So I can confirm, 12.5 RC runs fine now without Finder problems on Mac Pro 4,1 (5,1). I´m still on non-metal accel due to the Kepler OCLP issue since 12.5 beta 4. Anyone with success story with i.e. a GT630 card on 12.5 now?
I can also confirm the nasty bug with Finder not able to open folders from the dock is no longer encountered. Previous to this RC, I had a shortcut to kill Finder which worked for a while until needed again.
 
Guess my 13,2 iMac is stuck on 12.5 beta 2 until further notice… oh well, we had a good run… my other Mac’s seem fine on RC 12.5 so far at least

I reached out to one of the members (who seems to be in direct (?) contact with developers) in response to posts #6691 and #6695, the latter one in particular, where poster stated "... developers have not experienced this problem ...".
I offered to secure system logs and share information with OCLP developers, via response to poster, if somone advised which exact logs to secure. I have yet to receive a response, but I essentially offered my iMac 13,2 as a test bed for any alpha OCLP patches. It is possible that developers do not have access to iMacs with particular Kepler graphic cards.

I do agree that we (iMac 13,* owners) had a "good run", and it was always understood that at some point there would be no exit from the Apple-set Error Trap (pun intended).

My MacBook Pro 5,2 (2009) runs very well on Monterey, 12.b5.
 
Correct but small correction is that it is normally on the MacOS volume and is not APFS related. That is, it is the default MacOS loader path and been like that from HFS+ based MacOS versions.

HFS+ volume with this path added is what rEFInd calls "OwnHFS" type installation. This appeared in rEFInd quite a few years ago now (I think around Yosemite).


Exactly. Mac firmware will search that default loader path for a loader if it does not find a UEFI loader, /EFI/BOOT/bootx64.efi. This is what rEFInd took advantage of as it will boot the boot.efi file it finds and doesn't vet it.

Have to say that AFAIK, it searches for the path on normal volumes and not ESPs as @Bmju hinted. I doubt it also checks ESP as MacOS never creates such a path. Could be that OCLP defines things to match the default Mac path for convenience. Possibly to simiplfy moving things to a USB stick.
In addition to the default paths, any efi file in any path can be booted automatically on HFS+ or APFS volumes since those file systems have a structure that contains a path (actually a file id) to a boot file. This path is modified using the --file argument of the bless command. I don't think RefindPlus calls the EFI protocol for getting this blessed boot file? OpenCore has code to do that.

EFI (or FAT) partitions don't have a blessed file. Booters on these partitions need to be at a default path: /EFI/BOOT/bootx64.efi (and also /System/Library/CoreServices/boot.efi for Macs - maybe).
 
Last edited:
  • Like
Reactions: perez987
View attachment 2029242

12.5 RC updated and patched on MacBook Pro 4,1.
Runs just as well as with the latest betas, but still some issues exist. Beach balling without animation for Apps saving files (preview i.e.). Frozen Apps when invoking them. Spotlight not finding anything. Will try on a fresh user account to see if its a config problem.
I have a MacBook Pro 5,2 (17" -mid 2009, C2D 3.06, EVO SSD, NVIDIA GeForce 9600 GT 512 GB), 8 GB RAM).
Just updated OTA to 12.5 RC. Spotlight functions as expected. No finder bugs to report. Preview works without issues.
 
So I can confirm, 12.5 RC runs fine now without Finder problems on Mac Pro 4,1 (5,1). I´m still on non-metal accel due to the Kepler OCLP issue since 12.5 beta 4. Anyone with success story with i.e. a GT630 card on 12.5 now?
iMac 13,2 with NVIDIA GeForce GTX 680MX 2 GB (Kepler); login-window loop as well.
 
  • Like
Reactions: bmillz
I don't think RefindPlus calls the EFI protocol for getting this blessed boot file?
It doesn't try to get the blessed loader by default. You could however add firmware to the scanfor items in the config file. This will add Boot#### variables as loaders which can be narrowed down using the dont_scan_firmware config setting.

You could also set a manual stanza up to use the firmware_bootnum option:

I still need to look at these ported over options in detail

Booters on these partitions need to be at a default path: /EFI/BOOT/bootx64.efi (and also /System/Library/CoreServices/boot.efi for Macs).
Default UEFI bootloader is /EFI/BOOT/bootx64.efi
Default MacOS bootloader is /System/Library/CoreServices/boot.efi

My previous understanding was that if a blessed item is not found on start up, Mac firmware will search for default UEFI bootloaders on ESPs and that on failing to find one, the default outcome, it will move on to search for default MacOS bootloaders on regular volumes: https://forums.macrumors.com/posts/30191266

Do you mean to say that it also searches for default MacOS bootloaders on ESPs as part of this search? If so, do you know where this fits in the sequence?

EDIT: Make clear that fallback bootloader search only happens if a blessed item is not found on start up
 
Last edited:
In addition to the default paths, any efi file in any path can be booted automatically on HFS+ or APFS volumes since those file systems have a structure that contains a path (actually a file id) to a boot file. This path is modified using the --file argument of the bless command. I don't think RefindPlus calls the EFI protocol for getting this blessed boot file? OpenCore has code to do that.

EFI (or FAT) partitions don't have a blessed file. Booters on these partitions need to be at a default path: /EFI/BOOT/bootx64.efi (and also /System/Library/CoreServices/boot.efi[icode] for Macs).
Bless can do loads of things, but the functionality which sets the boot file sets up NVRAM Boot#### entries - so not a structure on the filesystem, as such. Also it certainly can be applied to the ESP: it's a manual step in the 'OpenCore on the Mac Pro' thread instructions (i.e. to bless OpenCore), and in fact it's what OpenCore's LauncherOption option does, setting ESP:/EFI/OC/OpenCore.efi as the file to boot from.
 
  • Like
Reactions: Dayo
Do you mean to say that it also searches for default MacOS bootloaders on ESPs as part of this search? If so, do you know where this fits in the sequence?
I don't know about that. It would require testing to be sure. It's a possibility. For example, if a HFS+ partition is not blessed properly, then hopefully the Apple boot picker will look for a booter at the default path on the partition. A FAT partition is like an HFS+ partition that is not blessed properly.

Bless can do loads of things, but the functionality which sets the boot file sets up NVRAM Boot#### entries - so not a structure on the filesystem, as such. Also it certainly can be applied to the ESP: it's a manual step in the 'OpenCore on the Mac Pro' thread instructions (i.e. to bless OpenCore), and in fact it's what OpenCore's LauncherOption option does, setting ESP:/EFI/OC/OpenCore.efi as the file to boot from.
Bless can set nvram boot#### entries and it can set APFS/HFS+ blessed file.
When it sets nvram boot#### entries for a APFS/HFS+ volume, the efi path does not include the file path because the path can be obtained by the filesystem structure.

Use bless --info /Volumes/thevolume to see what the blessed file is for a APFS/HFS+ volume. Note that if you pass the system volume of an APFS container, it will show the info for the Preboot volume instead which is why I created https://github.com/joevt/bless . Note that there is a blessed file and a blessed folder. On an HFS+ volume, there's more info such as a list of open folders, a separate blessed folder for Mac OS X (where the other blessed folder is for Mac OS 9).

Use the the dumpallbootvars command from the gfxutil.sh script at https://gist.github.com/joevt/477fe842d16095c2bfd839e2ab4794ff to show all the boot#### entries and file paths.

Boot Camp for legacy BIOS booting is a special case. bless (or Startup Disk preferences panel or Apple Startup Manager) set the boot#### entry to point to a Boot Camp EFI app in the firmware. That app boots the disk pointed to by the BootCampHD nvram variable (a EFI device path). The disk's MBR boots the partition that is marked as active. rEFInd and RefindPlus can boot any Legacy BIOS / Boot Camp partition by setting the BootCampHD nvram variable and setting the active partition in the MBR and executing the BootCamp EFI app. They use a fixed list of Boot Camp EFI apps. All the Boot Camp EFI apps in the list have the same GUID but different Macs have the app in different firmware volumes which means the EFI path of the firmware volume differs between Macs. They should just search all the firmware volumes for the GUID of the EFI app instead of having a list.

Newer Macs don't have a Boot Camp EFI app so they must boot Windows using UEFI.
 
They should just search all the firmware volumes for the GUID of the EFI app instead of having a list.
This reads a lot better:
@joevt should propose and provide the modifications to rEFInd/RefindPlus (better to rEFInd if possible as RefindPlus will definitely grab it if done) to just search all the firmware volumes for the GUID of the EFI app instead of having a list.
 
after i did erase my EFI partition with "diskutil reformat disk0s1" and than reinstalling OCLP 0.47 the iMac 14.2 does boot, but it also does mount the EFI partition. In linux I would edit the "/etc/fstab". Where is this in Monterey?
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.