pac-man Posted November 29, 2020 Share Posted November 29, 2020 (edited) I have legacy system (ASUS Rampage III / i7 920 CPU) with a working Catalina System running and previously booted by Clover. Since the last days I have switched to OpenCore and finally now I have a working legacy System booted by OpenCore. Nearly everything is working but I can't upgrade to Big Sur. In the System Software-Update Preferences I have downloaded the Big Sur Upgrade and have started the Upgrade Process. After the first restart a new partition "macOS Installer" was found and this volume I had selected for continuing the upgrade Progress. Sadly the upgrade ends to a "endless reboot without progress" and I don't know why.... What I have done so far: 1. Working Catalina with Upgrade Process startet 2. My used EFI: EFI.zip Note: Folders Microsoft and Resources cleared due to upload file size limit... 4. Opencore Logfile: opencore.txt Does anyone knew why my system won't upgrade? Regards pac-man Edited November 29, 2020 by pac-man 1 Link to comment Share on other sites More sharing options...
mickeyd453 Posted November 30, 2020 Share Posted November 30, 2020 You do not have working NVRAM and without that you will not be able to install. Link to comment Share on other sites More sharing options...
pac-man Posted November 30, 2020 Author Share Posted November 30, 2020 What exactly do you mean with "working NVRAM"? Native-NVRAM or should Emulated NVRAM also working? I have also configured Emulated NVRAM as described here: https://dortania.github.io/OpenCore-Post-Install/misc/nvram.html Link to comment Share on other sites More sharing options...
mickeyd453 Posted November 30, 2020 Share Posted November 30, 2020 native NVRAM Link to comment Share on other sites More sharing options...
pac-man Posted December 1, 2020 Author Share Posted December 1, 2020 Wow, thats really hard. This means that legacy systems without native NVRAM will no longer be able to upgrade to Big Sur...? What about this statement? Is there a difference between macOS and the installer? Is the installer not be able to read the nvram.plist as mentioned? Link to comment Share on other sites More sharing options...
1Revenger1 Posted December 1, 2020 Share Posted December 1, 2020 There are no shutdown hooks in the installer that can be used to save into the nvram.plist. So reading works just fine, but it fails to write on shutdown since there aren't logout hooks we can use to actually write nvram.plist. @pac-man 1 Link to comment Share on other sites More sharing options...
pac-man Posted December 1, 2020 Author Share Posted December 1, 2020 Would it help to "manually" execute the LogoutHook.command as soon as the installer wants to restart? Or does the installer write nvram values after the restart process has started and executing the LogoutHook.command will be too early? Link to comment Share on other sites More sharing options...
mickeyd453 Posted December 1, 2020 Share Posted December 1, 2020 You can run BS on a legacy system just fine but i have not yet found a way to make the installer complete. For me i complete the installation for BS on a more modern machine then put the SSD back into the legacy system to run. Once installed you are able to upgrade between versions on the legacy system, at least i have done for all the betas. Link to comment Share on other sites More sharing options...
pac-man Posted December 1, 2020 Author Share Posted December 1, 2020 Sounds interesting... I will try your suggestion. 25 minutes ago, mickeyd453 said: Once installed you are able to upgrade between versions on the legacy system Does that mean that only the first "upgrade" is not working but for example upgrade from 11.0 to 11.0.1 or 11.1 will then be possible? Link to comment Share on other sites More sharing options...
mickeyd453 Posted December 1, 2020 Share Posted December 1, 2020 Clean install or an upgrade from 10.15.x > 11.x can be done on a different machine and then SSD transferred over. Once on 11.x you should be able to perform standard upgraded from software update as and when they come out. Link to comment Share on other sites More sharing options...
pac-man Posted December 3, 2020 Author Share Posted December 3, 2020 (edited) Please mark topic as solved... Positive news for all other people with same problem! I have found the final solution to be able to upgrade from Catalina to BigSur on the legacy system itself: 1. You have to have a working "Emulated NVRAM" as described here: https://dortania.github.io/OpenCore-Post-Install/misc/nvram.html 2. Add the additional value "msu-product-url" to the "LegacySchema" section under "7C436110-AB2A-4BBB-A880-FE41995C9F82" 3. Add the necessary value to the NVRAM using following command: sudo nvram msu-product-url="msu-product-url://$(diskutil info /System/Volumes/Data | grep "Volume UUID" | awk '{print $3}')/macOS%2520Install%2520Data" 4. Upgrade to BigSur from inside Catalina 5. The system restarts now to a working updater 6. After several restarts the system is updated to BigSur 7. Remove NVRAM variable and previous added OC config Entry "msu-product-url" 8. Have Fun with BigSur Edited December 3, 2020 by pac-man 4 1 Link to comment Share on other sites More sharing options...
MacNB Posted December 5, 2020 Share Posted December 5, 2020 Good work ! I have a legacy system (Hack 2) with emulated NVRAM and did not have a problem upgrading from High Sierra to Catalina. Just had to make sure that you select the macOS Installer disk on every reboot until it is no longer there. But have not yet tried BS. What happens if you DO NOT remove the NVRAM variable msg-product-url ??? Also, what's the source of info for the msg-product-url NVRAM variable ? Link to comment Share on other sites More sharing options...
deeveedee Posted December 7, 2020 Share Posted December 7, 2020 (edited) @pac-man This is good stuff - will definitely need to try it on my legacy socket 1156 (still running Catalina 10.15.7.03 as a MacPro5,1 / -no_compat_check). Nice detective work! @TheBloke I hope you don't mind if I pull you into this, but thought this might be helpful - is this clever solution related to what you were discussing about X299 in the other forum? Edited December 10, 2020 by tonyx86 Link to comment Share on other sites More sharing options...
TheBloke Posted December 7, 2020 Share Posted December 7, 2020 Thanks for the ping. This is exactly what I was discussing, yes. I investigated the NVRAM issue and discovered that msu-product-url was the key to failed Big Sur update and install on systems with broken NVRAM. I wrote a little script that enables fresh Big Sur install by getting the necessary APFS UUID out of OpenCore debug logs. Then I was working on a Python script to enable both install and upgrade - the latter by getting the info from diskutil, then writing it directly to OpenCore config under NVRAM -> ADD -> 7C436110-AB2A-4BBB-A880-FE41995C9F82. But other things have got in the way so I'm not yet done with the script. Using OpenCore's NVRAM -> ADD means OpenCore sets the NVRAM variable, and therefore enabling Legacy NVRAM and LogoutHook are not necessary. But enabling Legacy NVRAM is probably desirable on such systems, so @pac-man 's solution works well as well. Be aware though that legacy NVRAM won't work for a new Big Sur install, only for upgrades. During stage 1 of a fresh install, the installer will adjust the target drive's APFS volumes, and the required UUID is generated during that process. This is why my preliminary script gets the necessary UUID out of OpenCore log files, once the user has rebooted at the end of stage 1 and before they proceed into stage 2 (the part that fails if msu-product-url is not correctly set in NVRAM.) On 12/5/2020 at 7:34 PM, MacNB said: I was asking @pac-man where did the information about this "new" variable come from ? That is, where is it documented ? Who published it ? I don't know about pac-man, but I confirmed the variable as a result of a couple of days of testing on a system with working NVRAM, in which I simulated non-working NVRAM by resetting NVRAM on every boot from the OpenCore boot picker. A large number of NVRAM variables are added at the end of stage 1 of a Big Sur upgrade or install After a process of elimination, I narrowed it down to that one variable as the one required to get the upgrade/install to continue successfully. Maybe pac-man saw my research on the other forum, or quite possibly discovered it independently. 1 2 Link to comment Share on other sites More sharing options...
deeveedee Posted December 7, 2020 Share Posted December 7, 2020 Great insight - thank you. Can't wait to try this on my old Socket 1156 / H55 when I get back to it. 1 Link to comment Share on other sites More sharing options...
pac-man Posted December 9, 2020 Author Share Posted December 9, 2020 (edited) Quote What happens if you DO NOT remove the NVRAM variable msg-product-url ??? Also, what's the source of info for the msg-product-url NVRAM variable ? I'm not sure what happens if you do not remove the NVRAM variable afterwards but on my "vmware fusion" try this was also removed after the successful upgrade. Maybe future macOS releases will reuse this variable... Quote Maybe pac-man saw my research on the other forum, or quite possibly discovered it independently. I found it independently but afterwards I have found out (googled for this nvram variable) and I only found one mention on another forum (X299 Big Sur Topic). What I have done to find out what is missing was: 1. Installed Catalina in VMWare Fusion 2. Read out all NVRAM variables before upgrading using "nvram -p" inside Terminal of Catalina 3. Updated from Catalina to Big Sur inside the VM 4. While restarting the first time I switched to the efi shell (before installer loads) 5. Got all NVRAM variables out by the efi command "dmpstore" 6. Compared both NVRAM outputs After comparing both NVRAM outputs I found out (try & error) that only msu-product-url was the reason for the failed update process. Edited December 9, 2020 by pac-man 2 Link to comment Share on other sites More sharing options...
iceage2609 Posted March 3, 2021 Share Posted March 3, 2021 (edited) On 1/29/2021 at 7:35 PM, Hervé said: I can confirm that @pac-man's above method works perfectly on systems with legacy BIOS, having experienced the exact same boot loop situation after initiating a fresh Big Sur installation, then attempting the upgrade from Catalina on my old Dell Vostro 200 C2D desktop. All that's required is working nvram, whether emulated or not, so that the msu-product-url parameter can be safely stored. Please note that it's highly advisable to retain the parameter in NVRAM because it's required for Big Sur updates... In the command from pac-man my disk volumeUUID should be in quotes ? sudo nvram msu-product-url="msu-product-url://$(diskutil info /System/Volumes/Data | grep "Volume UUID" | awk '{print $3}')/macOS%2520Install%2520Data" The Catalina partition should be read/write or it’s fine as it is? I need the volume uuid from Catalina or from data partition ?) Thanks Edited March 3, 2021 by iceage2609 Link to comment Share on other sites More sharing options...
pac-man Posted September 18, 2021 Author Share Posted September 18, 2021 Just for Information, on my legacy system I had to do the same steps for upgrading 11.5.2 to 11.6... Link to comment Share on other sites More sharing options...
markl18 Posted February 11, 2022 Share Posted February 11, 2022 hi getting stuck on unabel to start image already started config.plist Link to comment Share on other sites More sharing options...
Recommended Posts