Jump to content

High Sierra breaking Big Sur's seal?


10 posts in this topic

Recommended Posts

So I've notived a strange issue with my build. After running High Sierra I can no longer start Big Sur. I just get the stop sign thing…

 

SYSTEM CONFIGURATION:

 

I have 3 macOS Versions installed on 3 seperate discs:

 

  • Big Sur on a NVME (default)
  • Catalina on a SSD
  • High Sierra on a m.2 SATA (I sometimes need to access this drsk to open old audio projects containing 32 bit plugins)

 

Each macOS install has its own dedicated EFI and config due to the fact, that each of the OSes require specific csr-values for SIP to be disabled.

 

In the case of High Sierra it also requires a different System Definition and an emulated CPU in order to boot. The NVRAM is set-up in a way that the csr-active config value is reset on each reboot so that the new one can be applied if I change the system I want to run. Every time I want to boot a different OS than the default, I use the BIOS boot menu to pick the correct drive with the associted EFI and Config.

 

ISSUE:

 

Now, every time I use High Sierra and reboot, I can no longer boot Big Sur. I get the ugly stop sign. The only work around for now has been to use the "-no_compat_check" boot-arg to boot Big Sur. Once I install Big Sur on top of the existing install,everything is working normal again. I don't know what's the reason for it. I wonder if is related to this seal feature or something. I am kind of baffled about this and don't know what exactly causes this.

 

Maybe someone on here has an explanation.

 

 

Edited by 5T33Z0
4 hours ago, 5T33Z0 said:

So I've notived a strange issue with my build. After running High Sierra I can no longer start Big Sur. I just get the stop sign thing…

 

SYSTEM CONFIGURATION:

 

I have 3 macOS Versions installed on 3 seperate discs:

 

  • Big Sur on a NVME (default)
  • Catalina on a SSD
  • High Sierra on a m.2 SATA (I sometimes need to access this driver to open old audio projects containing 32 bit plugins)

 

Each macOS install has its own dedicated EFI and config due to the fact, that each of the OSes require specific csr-values for SIP to be disabled.

 

In the case of High Sierra it also requires a different System Definition and an emulated CPU in order to boot. The NVRAM is set-up in a way that the csr-active config value is reset on each reboot so that the new one can be applied if I change the system I want to run. Every time I want to boot a different OS than the default, I use the BIOS boot menu to pick the correct drive with the associted EFI and Config.

 

ISSUE:

 

Now, every time I've used High Sierra and rebooted, I can no longer boot Big Sur. I get the ugly stop sign. The only work around for now has been to use the "-no_compat_check" boot-arg to boot Big Sur. Once I install Big Sur on top of the existing install everything works normal again. I don't know what's the reason for it. I wonder if is related to this seal feature or something. I am kind of baffled about this and don't know what exactly causes this.

 

Maybe someone on here has an explanation.

 

 

 

If you do ResetNVRAM the first time you boot BS after Sierra, it fixes the problem?

@5T33Z0 I don't believe only clearing and reloading "csr-active-config" with values in the NVRAM sections of the config.plist pertaining to each respective macOS version, suffices.

Suggest you do it as per the attached screenshot and apply that clearing and reloading principle to the NVRAM section of all your config.plist files being used in your setup. I believe only "manipulating" csr-active-config will leave some  NVRAM variables set, from other operating systems, which Big Sur does not like, or alternatively, is not compatible with.

 

Greetings Henties

 

Screen Shot 2021-04-20 at 2.33.52 PM.png

Edited by Henties
Posted (edited)

NVRAM Reset didn't fix the issue. It must be related to somehing else.

 

@Henties I don't think listing "run efi-updater" under "Delete" makes sens, since it is disabled anyway…

Edited by 5T33Z0
1 hour ago, 5T33Z0 said:

NVRAM Reset didn't fix the issue. It must be related to somehing else.

 

@Henties I don't think listing "run efi-updater" under "Delete" makes sens, since it is disabled anyway…

It was too easy. I was sure you had thought about it.

In my old hackintosh with a P55 board, when I changed the disk with macOS and different EFI folder, in addition to ResetNVRAM I had to turn off the PC and also the power button for a few seconds. I know it sounds weird but ResetNVRAM wasn't enough.

 

Edited by miliuco

No, this can't be it either. The PC is cut off from power completely every time I stop working. Because it is hooked up to a multi socket outlet with a switch. And once the shutdown is completed, I turn off the mulit socket outlet, so the system is completly disconnected from power for a longer period of time.

  • Like 1

@5T33Z0 I agree that "run-efi-updater" is superfluous and can be omitted from the NVRAM delete section. Suggest you use Hackintool and check which NVRAM variables differ between your macOS versions and include those also under the NVRAM delete section of each config.plist file used in your system. 

 

Greetings Henties

 

 

This issue cannot be related to NVRAM, because a) the only variable that differs is csr-active config and b) even if there were differences they would become irrelevant once an NVRAM reset is triggered. And since NVRAM reset dooesn't change anything, NVRAM cannot be the cause for this issue. The issue must be rooted somewhere else.

@5T33Z0 As a next step I would remove the 3 EFI folders from their respective EFI partitions and safeguard each one in a  dedicated folder on one of the desktops (or all three for easy access later). Then pick one of the saved EFI folders and place that in the EFI partition of a USB stick and then boot the macOS system with the USB stick for which that particular EFI folder was originally intended.

 

This procedure ensures that multiple EFI folders cannot be present simultaneously when booting, which I believe is crucially important.

 

Repeat this with the other 2 EFI folders and again boot the respective macOS system for which it is intended.

 

Each operating system should now boot flawlessly, even multiple times in succession, provided the contents of the respective EFI folder are configured correctly for the operating system it is meant to boot. 

 

Once that is working for each of your 3 macOS operating systems I would consider using/configuring  MISC--Entries to be the boot source for each of your operating systems, that way you can ensure that the correct EFI folder is alway selected for the operating system for which it is intended. 

 

A sample of how I do this for 2 Windows and one Linux system has been attaches.

 

 

Screen Shot 2021-04-21 at 1.14.48 AM.png

On 4/20/2021 at 5:46 AM, 5T33Z0 said:

So I've notived a strange issue with my build. After running High Sierra I can no longer start Big Sur. I just get the stop sign thing…

 

SYSTEM CONFIGURATION:

 

I have 3 macOS Versions installed on 3 seperate discs:

 

  • Big Sur on a NVME (default)
  • Catalina on a SSD
  • High Sierra on a m.2 SATA (I sometimes need to access this drsk to open old audio projects containing 32 bit plugins)

 

Each macOS install has its own dedicated EFI and config due to the fact, that each of the OSes require specific csr-values for SIP to be disabled.

 

In the case of High Sierra it also requires a different System Definition and an emulated CPU in order to boot. The NVRAM is set-up in a way that the csr-active config value is reset on each reboot so that the new one can be applied if I change the system I want to run. Every time I want to boot a different OS than the default, I use the BIOS boot menu to pick the correct drive with the associted EFI and Config.

 

ISSUE:

 

Now, every time I use High Sierra and reboot, I can no longer boot Big Sur. I get the ugly stop sign. The only work around for now has been to use the "-no_compat_check" boot-arg to boot Big Sur. Once I install Big Sur on top of the existing install,everything is working normal again. I don't know what's the reason for it. I wonder if is related to this seal feature or something. I am kind of baffled about this and don't know what exactly causes this.

 

Maybe someone on here has an explanation.

 

 

 

Note that you could run all of these installs on the same HDD and use a bootloader specific to each or any.

 

For instance, clover 5122 works for Sierra through Catalina.  Open Core 068 works well for Catalina and Big Sur.

 

If you are a linux multibooter, you can use GRUB2 linux boot loader for your main boot loader and chainload to either clover or Open Core.

Keep in mind that GRUB2 apparently does not any longer directly chainload Open Core 065 and newer.

 

In this case you can use Refind to chainload Open Core.

 

Clover, Refind and GRUB2 can all be installed on the same ESP.  You can also install different Open Core/Clover versions to separate FAT32 partitions and chainload them selectively.  This allows you to make changes without disturbing other working bootloaders.

 

https://www.insanelymac.com/forum/topic/346639-updated-tips-and-observations-for-114/

 

Edited by HenryV
update link
×
×
  • Create New...