Jump to content

High Sierra breaking Big Sur's seal?


Guest 5T33Z0
 Share

9 posts in this topic

Recommended Posts

Guest 5T33Z0

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
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

@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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

@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

 

 

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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
Link to comment
Share on other sites

  • 2 years later...

@deeveedee Yes. I actually did find an explanation a year later or so and a fix via Terminal – I can't find booth any more and it looked pretty complicated. Somehow, when installing High Sierra, it changes something in the Preboot Volume and after that you will be greeted with the dreaded crossed-out circle instead. I guess the SMBIOS/board-id is not recgnized /too new then, so you need to use the `-no_compat_check` boot-arg to be able to boot into mac Big Sur(or newer?) again.

 

Next, you have to fix the Preboot Volume with terminal wizardry to fix the issue or by re-install Big Sur over your existing Install to fix it.

 

Since the I haven't dared to install High Sierra again after that, my recommendation for users who need 32 bit support is to install macOS Mojave instead.

Edited by cankiulascmnfye
  • Thanks 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...