Jump to content

P7H55M-LX Big Sur installation (OpenCore)


17 posts in this topic

Recommended Posts

Hello,


951445815_ScreenShot2021-03-25at10_36_43PM.thumb.png.7ea1276617ba8d75190d221906b65db4.png

 

'Big Sur' successfully installed on a computer of following configuration

 

Computer:
-----------------------
MB: P7H55M-LX
CPU: X3470 (Nehalem)
VC: NVidia Geforce GTX760 2GB
RAM: 8GB
HDD: ST3500414SC (500GB)
OpenCore: 0.6.7
SMBIOS: MacPro6,1

SMBIOS was generated with GenSMBIOS and result integrated into config.plist file

 #######################################################
 #               MacPro6,1 SMBIOS Info                 #
#######################################################

Type:         MacPro6,1
Serial:       F5KSH3Y7F9VM
Board Serial: F5K640403GUFHDDA8
SmUUID:       1C789E6A-8E4D-49D1-957E-04F7AD1D4000


Please generate a new serial number and integrate into config.plist file or manually or with an assistance of ProperTree.

File config.plist has NVRAM msu-product-url data integrated in for installation partition, which should be modified to match with yours partition UUID, please see attached perl script uuid_disk.pl to recreate value for your system.

It should be sufficient to drop EFI folder in proper location of your USB/HDD boot drive (for a test start from USB drive and once confirmed copy to HDD).

EFI folder for this configuration is attached to the post.

NOTE: CPU x3470 (Nehalem) lacks support for RDRAND command, due this reason a driver OpenHfsPlus.efi was replaced with HfsPlusLegacy.efi

NOTE:
Currently sound (VT1708s) does not work in Big Sur with VoodooHDA.kext from Catalina - the issue is under investigation.

NOTE:
uuid_disk.pl script can be run in any of following forms

uuid_disk.pl -h
uuid_disk.pl -m

uuid_disk.pl -u A6F75FD3-9288-485F-B13F-F3BDD465C65F
uuid_disk.pl -v 'Big Sur'
uuid_disk.pl -m '/Volumes/Big Sur'
uuid_disk.pl -i disk1s7
uuid_disk.pl -n /dev/disk1s7


osx151212

EFI.zip GenSMBIOS-master.zip

 

uuid_disk.pl

Edited by osx151212

Well done mate. Yours is the first legacy install i've seen. I have a an old gigabyte P55a UD3 and i've been trying to get big sur installed on it for the last 4 weeks without any success. I currently have Catalina with clover instal but have had no success with Opencore at all. time for another try. I'll let you know how i get on.

 

 

Posted (edited)
21 minutes ago, antic said:

Well done mate. Yours is the first legacy install i've seen. I have a an old gigabyte P55a UD3 and i've been trying to get big sur installed on it for the last 4 weeks without any success. I currently have Catalina with clover instal but have had no success with Opencore at all. time for another try. I'll let you know how i get on.

 

 

My attempt with clover have failed so far.

First of all my mainboard does not support natively NVRAM, other possible problem is that most recent Clover_r5131 stops boot process at USBMSC and my best guess is that the issue might be related to my CPU as x3470 which does not provide RDRAND instruction (and I have no idea how to verify if HFS driver require RDRAND instruction) and perhaps HFS driver can not mount filesystem with 'Big Sur' installation files.

Clover_r5131 is an initial switch to OpenCore trend (OpenRuntime.efi) and I guess that HFS driver may require RDRAND instruction support.With this version of Clover I even can not boot Catalina (but Catalina boots fine with Clover_r5130).

I found that NVRAM emulation in Clover has it's limits: I can assign the variable and after reboot it persists. But then I can not change it -- system does not permit to make the change. To solve this issue I have to Mount EFI, remove nvram.plist, edit /etc/rc.shutdown.d/80.save_nvram_plist.local (Clover installed script) and add first executable command 'exit 0'. Otherwise on shutdown current NVRAM state will be dumped back into nvram.plist - described procedure blocks nvram save. And only after reboot I can modify NVRAM variable, edit /etc/rc.shutdown.d/80.save_nvram_plist.local file and remove 'exit 0' - on shutdown new assigned value to NVRAM variable will get dumped into nvram.plist.

osx151212

Edited by osx151212

Well that didn't go well, trashed my installation.

Catalina working again after re-instal.

 

Can you give more details on uuid_disk.pl what exactly is it supposed to do and how to run the scrpit. .

 

I'm also having problems with USB my motherboard doesn't support handoff. I get kernal panic when installer tries to take ownership of USB controllers.

 

I can actually get to the the Big Sur installer screen if I run the installer from a sata SSD but as there's no usb every thing is just locked up.

 

Its a bit strange as I can run the first part of the Big Sur installer from clover 5131 but it keeps rebooting at 12 minutes into the instal saying SIP is disabled allowing process at /System/Library/Extensions/IOGraphicsFamily.kext/logdlagnose. Don't know why this is as i've checked SIP in the clover boot loader and its not disabled.

 

I'm beginning to think it might be just easier to get a used Asus P55M mother board they are pretty cheap on ebay 

 

 

Posted (edited)
9 hours ago, antic said:

Can you give more details on uuid_disk.pl what exactly is it supposed to do and how to run the scrpit. .


Hi,

'Big Sur' at first stage of installation copy files to disk and reboots system. At second stage it rely on NVRAM variable msu-product-url pointing to installation volume. If installation does not find this NVRAM variable value it will wait for a while and then abruptly interrupts.

P7H55M-LX does not provide NVRAM and variable msu-product-url required to be emulated. This can be achieved by inserting into config.plist in NVRAM section this value.

Value msu-product-url must be represented in binary format encode64.

This is a purpose of uuid_disk.pl script -- you start the script with an option which refer to your Big Sur installation volume. The script computes binary encoded value and prints on the screen an instruction what section the value should be inserted into.

For example in your system 'Big Sur' installation partition mounted as '/Volumes/Big Sur' then the script can be run as

./uuid_disk.pl -v '/Volumes/Big Sur'

Or you know that 'Big Sur' installation volume has identifier disk2s7 then the script should be run as

./uuid_disk.pl -i disk2s7

Or other example you are installing 'Big Sur' on other computer and obtained from that computer volume's UUID then you ran the script as

./uuid_disk.pl -u A6F75FD3-9288-485F-B13F-F3BDD465C65F

where in the example 'A6F75FD3-9288-485F-B13F-F3BDD465C65F' is UUID of installation volume.

The script does not modify any files but computes and prints msu-product-url value which you must integrate into config.plist file (you can use vim to edit the file manually or use any other proper editor for plist files).

You look in the file for msu-product-url and replace exiting value with new computed one.

 

If you run the script with following two options '-h' or '-m' it tells more about itself and it's purpose

./uuid_disk.pl -h
./uuid_disk.pl -m

The script supports short and long options as '--help', '--man', '--identifier', '--uuid' and etc.

NOTE:
I use separate disk for test installation to avoid unpleasant corruption of existing one. Once the test installation succeed and I am confident in installation process the disk with existing OSX connected and add new OSX version gets installed in separate volume.

osx151212 

Edited by osx151212
Posted (edited)
10 hours ago, antic said:

I can actually get to the the Big Sur installer screen if I run the installer from a sata SSD but as there's no usb every thing is just locked up.

Hi,

as an option you can 'shrink' last volume on your disk with assistance of diskutil to freeup about 14-16GB disk space. Then put 'Big Sur' installer into this volume to be used instead USB installation drive.

By going this route you avoid using USB drive completely during the installation -- it will bypass your problem with USB ports, it might be somewhat quicker as read from disk might be faster than from USB drive.

I was using this approach for a long time since 'El Capitan' with Clover bootloader.

In my situation with 'CLOVER" the 'Big Sur' installation at second stage stops at USBSMC message and sits there for a while and abruptly interrupts. My guess is that or it can not find msu-product-url NVRAM variable (it is emulated with nvram.plist and CLOVER scripts) or can not access HDD (VBoxHfs_64.efi driver) or something else.

osx151212

Edited by osx151212

Hi there again. have given up on my gigabyte P55 and decided to get a used asus P7P55 LX motherboard. Cost from £50 from ebay including shipping. Arrived today. Took me about an hour to swap out the motherboard and it booted straight into Catalina without any problems. Had a quick go at running Big Sur instal from USB and I can get to the installer screen with all USB devices working OK.

 

Before I have a go at installing it proper can you tell me what the other entry you have in your config.plist which is 'msu-save-url'

Edited by antic
Posted (edited)
On 3/30/2021 at 3:48 PM, antic said:

Before I have a go at installing it proper can you tell me what the other entry you have in your config.plist which is 'msu-save-url'


Hello,

you will find config.pllist in EFI.zip file which you can inspect for settings. I would suggest to do a research of OpenCore documentation - without doing so you will be at loss.

A significant part of configuration is same for different platforms, but some parts is very specific which depends on used CPU(selecting your platform). Here the documentation will lead what settings are recommended/required for your configuration.

For example in my case CPU X3470 does not support RDRAND instruction which required to replace default HfsPlus.efi with HfsPlusLegacy.efi driver.

A quick Google search returned following webpage which indicates that i7-860 does not support RDRAND instruction -- you have to use HfsPlusLegacy.efi driver.

Further Google search reveals that i7-860 CPU is also Nehalem - what leads me to believe that my configuration might work for you without or with minimal changes.

I would suggest you follow the path:

--------------------------------------------
1. Create Big Sur installation drive

2. Make flash drive bootable with assistance of BootInstall_X64.tool

  - Download OpenCore 0.6.7

  - Look into OpenCore/Utilities/LegacyBoot for BootInstall_X64.tool

3. Mount EFI partition

sudo diskutil mount EFI

4. Remove /Volumes/EFI/EFI folder or rename it to EFI.orig

5. Copy content of my EFI.zip (extracted) as replacement for EFI folder

  - here you will need to substitute msu-product-url to match your partition UUID

6. Unmount EFI partition

sudo diskutil umount EFI

7. Shutdown your system

8. Disconnect all your HDDs and connect test HDD

9. At boot time press F8 to bring boot menu
10. Select Big Sur USB installation drive as boot device

11. Proceed with the installation
12. Expect to have several reboots during installation

13. If test installation successful you have two options

  a. install Big Sur on your main HDD into separate volume

  b. boot from your old Catalina system

  -- on main HDD shrink last volume to free up space for Big Sur

  -- connect test installation HDD

  -- using disktool copy test installation to new created volume

 

*** As an alternative you can use test HDD drive instead of USB installation drive:

- connect test HDD to your running Catalina system (no any manipulation on Catalina system HDD)

- using disktool partition test HDD into Big Sur volume and extra 14GB for Big Sur installer

- put 'Big Sur installer' in 14GB volume

- make test HDD bootable with assistance BootInstall_X64.tool

- mount test HDD EFI volume
- copy into test HDD EFI volume my EFI folder

- if required make adjustment in EFI folder
- unmount EFI volume
- shutdown system

- disconnect all HDDs except test HDD

- boot from test HDD and proceed with the installation


NOTE:
Verify what BIOS version is in P7P55 mainboard, verify what is the latest BIOS version (1002) for this board available, if you experience a problem with installation one of possible reason might be the outdated BIOS (rare event but sometimes it require to update BIOS to most recent version for installation to proceed).

NOTE:
X3470 has about 10% performance gain over I7-860, X3480 has about 12.6% performance improvement (but cost is higher I considered 'it does not worth it')

osx151212

Edited by osx151212

Tried instal proper but still cant get a successful instal.

 

I can get through to the installer screen. After formatting the SSD and then installing Big Sur it stops at 12 minutes into the instal saying SIP is disabled allowing process at /System/Library/Extensions/IOGraphicsFamily.kext/logdiagnose. This is exactly the same problem I had when trying to instal Big Sur using Clover 5131 

 

On searching google I came across an entry from crazybird on this forum who was having the same problem. He thought it might be related to the video card. He was using a GT640 the same as me. I have checked the opencore guide an my card is supposed to be supported.

 

I have had various pm's with crazybird but he could not get a successful instal using the opebcore method . He ended up making a VMware instal of Big Sur then using opencore to boot it.

 

Can you tel me what the other entry you have in your config.plist which is 'msu-save-url'. Its listed below msu-product-url. 

On 4/1/2021 at 12:09 AM, antic said:

 

Can you tel me what the other entry you have in your config.plist which is 'msu-save-url'. Its listed below msu-product-url. 


Hello,

sorry for a delay with the answer. You can delete msu-save-url from config.plist file (I forgot about it, it is not required).

Now one question - is your volume for 'Big Sur' formatted as APFS volume? If not, then try to format it as APFS and do not forget to update msu-product-url as volume will have new UUID after formating.

osx151212

 

Absolutely no luck doing a fresh install. 
Finally managed to get an install but had to cheat a little bit. I got my daughter to install it on a sata SSD drive connected to USB C on her macbook pro

 

Took the SSD and connected it up to my Hack and it started up OK using opencore 0.6.7. The GT 640 graphics card is working as normal. cant understand why the failed attempts were due to the card. Maybe something else. 

 

Only problem was the ethernet card showing as en4 but sorted that after deleting a couple of Plists in /Library/Preferences/SystemConfiguration/

 

The only outstanding issue is the audio, but not too concerned as I've got a USB C-Media Headphone set connected to my speaker.

 

Edited by antic
On 4/3/2021 at 11:33 AM, antic said:

Maybe something else. 

Hello,
 

I did an attempt to install to 'Mac OS Extended' filesystem and it has failed (tried a few times). As only I formatted volume as APFS and the installation proceeded as expected.

This experience was a source of my previous notice.

osx151212

Thanks. I’m aware of this and have my drive formatted as APFS

 

 

On the lack of sound support on the motherboard. I managed to get audio through HDMI by adding AppleALC.kext and adding my video cards audio support to Device Properties which I exported from hackintool. 
 

Other issues sorted was iCloud access. Couldn’t get logged in. Used the same Platform info as had on my Catalina install but kept getting “could not communicate with server error” even though my ethernet was showing as en0. Sorted that out by adding ssdt-rmne.aml and NullEthernet.kext from RehabMan. Since deleted. Now added Ethernet support to Device Properties. 

 

Everything is working except wifi & Restart. My Atheros card is no longer supported since going to Catalina and Restart shuts down macOS but doesn't restart. I have to press power button to turn off/on again to restart. Sleep and Shutdown both work OK.

 

Would appreciate any advice on the Restart problem if anyone has any ideas.

Edited by antic
14 hours ago, antic said:

Would appreciate any advice on the Restart problem if anyone has any ideas.

 

Hello,

restart works in Catalina but not in Big Sur. In Catalina I used SMBIOS iMac14,4 and in Big Sur MacPro6,1 -- an attempt to use iMac14,4 did not resolve the issue.

The sound issue in my case related to VT170s chip which was supported by Catalina in VoodooHDA.kext but not in Big Sur. I guess that possible solution can be achieved by creating a patch to AppleALC.kext, I did some reading on patching but information somewhat dated and I am not sure it this approach will work today.

osx151212

×
×
  • Create New...