[Support] SpaceinvaderOne - Macinabox


Recommended Posts

So, since I had some spare time, I tried to understand why for some users the macinabox container works and for someone else it doesn't work.

Premise: I don't use the container, I prefer to do things manually.

Premise2: I'm talking about new installations

Premise3: I'm not considering user errors, such as not working/modified xml (this means also different cpu cores and ram)

Premise4: I'm considering BigSur

 

I looked at the macinabox code hosted on github and I'm not sure if I found the root of the issue..

 

I didn't install macinabox, but just followed the code and replicated on my linux machine.

 

Everyone is using the same xml template.

There is no passthrough (cpu included, it's emulated).

Physical hardware doesn't matter, all it's emulated!

 

At first we thought about the "force penryn" patch: from my tests an original macinabox installation doesn't require at all any "force penryn" patch (macinabox still emulates penryn!)

Opencore: I'm using it from 2-3 years now, I checked the included image in macinabox, apart being a prior version it has nothing wrong in it.

I provided in github an updated image, with both "force penryn" patches, still some users have issue. Did they do something wrong in configuration? I'm supposing not.

 

So, what's next?

The installation media.

 

There are 2 methods to download big sur: method1 and method2.

The first method (method 2) calls fetch-macos.py, the second method (method 1) calls fetch-macos2.py.

 

fetch-macos.py downloads directly BaseSystem.dmg, fetch-macos2.py downloads more data, including InstallAssistant.pkg.

It extracts SharedSupport.dmg from InstallAssistant.pkg, from SharedSupport.dmg it extracts a zip file (0ff07e22b367f4fe0f6d2047ad5c917202716c8b.zip for Big Sur 11.4), and finally it extracts BaseSystem.dmg from this archive.

For this method I had to modify the command since the product-id in the macinabox code doesn't exist anymore:

from:

fetch.sh -v 10.16 -c PublicRelease -p 071-05432

To:

fetch.sh -v 10.16 -c PublicRelease -p 071-00696

 

071-00696 is the current (at the time of writing) product id for big sur 11.4.

 

So at the end, both methods end with the BaseSystem.dmg

 

This is the recovery image, so once mounted by opencore, one should open disk utilities, format the hard drive and proceed with the online installation.

 

I downloaded both BaseSystem.dmg following the code and....look at this picture:

base.png.ac9b9e7f9da590089b202d8a9e7f0b2b.png

 

The top one is the mounted BaseSystem.dmg downloaded with fetch-macos2.py, the bottom one is BaseSystem.dmg downloaded with fetch-macos.py

 

They are not the same!

The one downloaded with fetch-macos.py seems "more complete" (??)

 

Maybe this is the root of the issues (?)

 

I would choose fetch-macos.py, or in other words method 2, to have the "complete" BaseSystem.dmg (or may be the other method? Check and report :D )

 

Would be interesting to have feedbacks from users who have issues, if they used method 1 or method 2.

 

NOTE:

# Method 1 or 2
if [ "$method" = "method 1" ] ; then		
# method 1 uses script2
python3 fetch-macos2.py 
# method 2 uses script 1 
elif [ "$method" = "method 2" ] ; then
python3 fetch-macos.py "$@"
fi

this is in macinabox:

Method 1 = fetch-macos2.py

Method 2 = fetch-macos.py

 

Note 2: I never installed mac os from the BaseSystem, I always created an installation media from the complete package (including InstallAssistant.pkg), so I'm not sure if and what is the correct method to have a good BaseSystem.dmg image.

Edited by ghost82
Link to comment

I lost a couple more hours on this, I tried both BaseSystem.dmg (img) downloaded with method 1 and method 2.

 

First thing I have to say is that both BaseSystem work.

 

The original OpenCore.img in macinabox is not able to boot both BaseSystem images of Big Sur 11.4.

 

An updated OpenCore.img is able to boot both BaseSystem images of Big Sur 11.4, but only with SecureBootModel=Disabled; if SecureBootModel=Default it bootloops as it happens with the original Opencore image.

 

Strange is that SecureBootModel=Default is able to boot an installer created with the "create install media".

 

I asked directly to developers about this issue, maybe it's a bug.

 

As expected the penryn patch(es) has nothing to do when penryn is emulated, I'm able to install without that patch(es).

 

https://github.com/SpaceinvaderOne/Macinabox/pull/47#issuecomment-870724002

Edited by ghost82
Link to comment
11 hours ago, ghost82 said:

An updated OpenCore.img is able to boot both BaseSystem images of Big Sur 11.4, but only with SecureBootModel=Disabled; if SecureBootModel=Default it bootloops as it happens with the original Opencore image.

I believe Macinabox uses SecureBootModel=Disabled for compatibility reasons.

As per the instructions from Opencore I have been using SecureBootModel=x86legacy which is recommended for VMs on 11.0 and above. (Virtual Machines will want to use x86legacy for Secure Boot support.)
Also don't forget to set ForceSecureBootScheme to false.

https://dortania.github.io/OpenCore-Post-Install/universal/security/applesecureboot.html#securebootmodel

Link to comment

It's more than this: the fact that it's not possible to boot the BaseSystem downloaded from apple means that the installer is corrupted in some way.

Yesterday I filled a bug in acidanthera bugtracker: Vitaly replied:

Quote

Well, the issue is that EfiBoot rightly complains that the Apple Secure Boot signature file (System\Library\KernelCollections\BootKernelExtensions.kc.j137ap.im4m) does not exist. For this reason it reboots the platform. What I can say here is that the created installer is essentially corrupted and the fact that it boots without Apple Secure Boot is mere luck.

It's a good question on how to properly download the macOS installer on a non-mac. My personal choice is using macrecovery (bundled with OpenCore) and then going with an online installation.

 

So, as you can read, the method used by macinabox to install mac os seems to not be the correct one, and it could not work anymore with upgrades even with SecureBootModel set to Disabled.

 

A (The?) correct installation should be download the InstallAssistant.pkg on a mac (or mac os vm) and create the offline installer from it.

Extracting BaseSystem and convert it is not a correct method: it can work, but it's not correct.

 

I think something has to be recoded in the current container.

Edited by ghost82
Link to comment

Even more on this, pinging @SpaceInvaderOne

As written above and as many tutorials around describe, converting the BaseSystem.dmg to img or anything else is wrong, as it prevents to boot with SecureBootModel=Default, can cause bootloops and more in general it can cause unexpected behaviors, now and in the future.

 

This is the correct method, which I tested:

 

1. Obtain the BaseSystem.dmg and BaseSystem.chunklist files (both methods work at the time of writing, apart the product id which is wrong in fetch-macos2.py --> see above); method 2, which is the macrecovery script should be the preferred method. (UPDATE: this is for the github version, it seems that github code is not sync with the image downloaded from CA; it seems methods 1 and 2 are swapped).

2. Instead of converting the dmg to img and load it as a drive for the installation in qemu:

2a. Create a second raw hard drive in qemu (lets call it vdisk1.img):

qemu-img create -f raw /path/to/vm/vdisk1.img 16G

vdisk2.img will be the raw hd on which mac os will be installed.

2b. Format vdisk1.img as FAT32:

mkfs.fat -s 16 -F 32 /path/to/vm/vdisk1.img

2c. Mount the formatted vdisk1.img to copy files on it:

mount -t vfat -o loop,rw /path/to/vm/vdisk1.img /path/to/mount/point/

2d. Create folder com.apple.recovery.boot

mkdir /path/to/mount/point/com.apple.recovery.boot

2e. Copy both BaseSystem.dmg and BaseSystem.chunklist files into com.apple.recovery.boot:

cp /path/to/downloaded/BaseSystem.dmg /path/to/mount/point/com.apple.recovery.boot/BaseSystem.dmg
cp /path/to/downloaded/BaseSystem.chunklist /path/to/mount/point/com.apple.recovery.boot/BaseSystem.chunklist

2f. Unmount the mount point:

umount /path/to/mount/point

3. Set the xml to use vdisk1.img as installation media and vdisk2.img as hard drive where mac os will be installed:

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source file='/path/to/vm/vdisk1.img'/>
      <target dev='hdd' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='3'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source file='/path/to/vm/vdisk2.img'/>
      <target dev='hde' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='4'/>
    </disk>

4. Boot the vm and choose the recovery icon, it will not bootloop with SecureBootModel=Default

5. Open disk utility to format vdisk2.img

6. proceed with online installation

 

At the end of the installation one can delete vdisk1.img

 

-------------------

EDIT: it seems that the docker img and the source code on github are not syncronized, method 1 and 2 seem to be swapped.

 

In github, these should be all the required modifications to unraid.sh + add to the docker the mkfs.fat command (Dokerfile? Sorry but not expert in dockers...):

makeimg() function:

makeimg() {
# check if install image has previously been created and if not copy baseimage and put in iso share
if [ ! -e /isos/"$NAME"-install.img ] ; then
qemu-img create -f raw "/isos/$NAME-install.img" 16G
mkfs.fat -s 16 -F 32 "/isos/$NAME-install.img"
mkdir /Macinabox/tools/FetchMacOS/BaseSystem/mountpoint
mount -t vfat -o loop,rw "/isos/$NAME-install.img" /Macinabox/tools/FetchMacOS/BaseSystem/mountpoint
mkdir /Macinabox/tools/FetchMacOS/BaseSystem/mountpoint/com.apple.recovery.boot
cp /Macinabox/tools/FetchMacOS/BaseSystem/BaseSystem.dmg /Macinabox/tools/FetchMacOS/BaseSystem/mountpoint/com.apple.recovery.boot/BaseSystem.dmg
cp /Macinabox/tools/FetchMacOS/BaseSystem/BaseSystem.chunklist /Macinabox/tools/FetchMacOS/BaseSystem/mountpoint/com.apple.recovery.boot/BaseSystem.chunklist
umount /Macinabox/tools/FetchMacOS/BaseSystem/mountpoint && rm -r /Macinabox/tools/FetchMacOS/BaseSystem/mountpoint
touch /config2/install_media_is_in_isos_share # make a file showing user where install media is located
chmod 777 "/isos/$NAME-install.img"
#cleanup - remove baseimage from macinabox appdata now its been converted and moved
rm -r /Macinabox/tools/FetchMacOS/BaseSystem/*
else
SKIPIMG=yes
fi
}

 

extractbigsur() function:

extractbigsur() {
	if [ "$method" = "method 1" ] ; then
	echo " Nothing to extract using method 1"
	else
	7z e -txar -o/Macinabox/tools/FetchMacOS/BaseSystem/ /Macinabox/tools/FetchMacOS/BaseSystem/InstallAssistant.pkg '*.dmg' 
	rm /Macinabox/tools/FetchMacOS/BaseSystem/InstallAssistant.pkg
	7z e -tdmg -o/Macinabox/tools/FetchMacOS/BaseSystem/ /Macinabox/tools/FetchMacOS/BaseSystem/SharedSupport.dmg 5.hfs
	rm /Macinabox/tools/FetchMacOS/BaseSystem/SharedSupport.dmg
	mkdir /Macinabox/tools/FetchMacOS/BaseSystem/temp
	mount -t hfsplus -oloop /Macinabox/tools/FetchMacOS/BaseSystem/*.hfs /Macinabox/tools/FetchMacOS/BaseSystem/temp
	7z e -o/Macinabox/tools/FetchMacOS/BaseSystem/ /Macinabox/tools/FetchMacOS/BaseSystem/temp/*MacSoftwareUpdate/*.zip AssetData/Restore/Base*.dmg
	7z e -o/Macinabox/tools/FetchMacOS/BaseSystem/ /Macinabox/tools/FetchMacOS/BaseSystem/temp/*MacSoftwareUpdate/*.zip AssetData/Restore/Base*.chunklist
	umount /Macinabox/tools/FetchMacOS/BaseSystem/temp && rm -r /Macinabox/tools/FetchMacOS/BaseSystem/temp && rm /Macinabox/tools/FetchMacOS/BaseSystem/*.hfs
	fi		
}	

 

-------------------

 

From opencore developers:

download-fritz (aka mhaeuser):

Quote

DMGs are signed as a whole, and you circumvent that with the conversion. DMGs cannot have machine-specific signatures for the boot files for obvious reasons, so they cannot properly support SB. Hence SB is disabled for booting validated images (follows Apple behaviour), which does not happen for you.

 

vit9696:

Quote

Flashing BaseSystem.dmg contents (downloaded from macrecovery) to a media is unsupported, yes. You must put it to com.apple.recovery.boot directory along with the chunklist file. This is how Apple does it.

 

Indeed, after following their advices, as described here, the online installation has no issues at all.

Edited by ghost82
  • Like 1
Link to comment
On 5/6/2021 at 12:52 PM, glennv said:

Ok, its working now. It was indeed as you suggested "adding" the new penryn patch to the plist instead of as i did before replacing the existing patch.

Tnx again !!!

 

image.png.10f664a68baa9e6988cff37ad943416a.png

Think I'm in the same place as you. I am running 11.2.1 - updated today to 11.4 and now I'm in a boot loop.

 

In 11.2 I had adjusted my cores, RAM, and some light edits to allow the iMessage service to work. Believe this was the config.plist. It took me a while to get everything up and running the first time for Big Sur.

 

Now I get a bootloop (but can still boot the old image). I'm new to Hackintosh. Can you give me some more basic steps and info about this new Penryn patch and what else I would need to do to allow the upgrade to be successful?

 

Thanks!

Link to comment

Who can help me............................😭 

when i install macinabox ,something wrong with it ,looks like permit problem.

I have been installed it for many times and tried four PC , all like this.Please .....................................

 

 

)%75_M8_V3T$(0S1GW[(@IC.jpg

Link to comment
9 hours ago, Kodiak51103 said:

Downloaded macinabox start it to begin install getting this error? Thanks

Macinabox uses custom OVMF files.

Have you checked to see if the files exist?

The error message is pretty clear... It can't find /mnt/user/system/custom_ovmf/Macinabox_Code-pure-efi.fd

Usually when people get these types of errors it is because they have changed the default locations for files during the installation or deleted the files by mistake.
You can always download them again from GitHub.

https://github.com/SpaceinvaderOne/Macinabox/tree/master/ovmf

Link to comment
38 minutes ago, Kodiak51103 said:

When into spaceinvaders app yes file is in the correctly place.

Please don't take this as me being mean... Just trying to get the the bottom of the issue...

So you haven't demonstrated that the file is in the right place, the pic only shows the directory, not the file. Also I'm not familiar with the app you are using and what this "Custom Path" business is about.

If you open a terminal window for your server from the Unraid web GUI you should see the following;

 

root@Tower:~# ls -la /mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd 
-rwxrwxrwx 1 root root 3653632 Apr  5 06:54 /mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd

Also check what you have defined in the <OS> section of the VM template as it will need to match.

<loader readonly='yes' type='pflash'>/mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd</loader>

Unraid is just looking to read this file. There has to be something simple happening. Eg the file is missing, the permissions are set incorrectly, etc.

Link to comment
Posted (edited)
36 minutes ago, cat2devnull said:

Please don't take this as me being mean... Just trying to get the the bottom of the issue...

So you haven't demonstrated that the file is in the right place, the pic only shows the directory, not the file. Also I'm not familiar with the app you are using and what this "Custom Path" business is about.

If you open a terminal window for your server from the Unraid web GUI you should see the following;

 



root@Tower:~# ls -la /mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd 
-rwxrwxrwx 1 root root 3653632 Apr  5 06:54 /mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd

Also check what you have defined in the <OS> section of the VM template as it will need to match.



<loader readonly='yes' type='pflash'>/mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd</loader>

Unraid is just looking to read this file. There has to be something simple happening. Eg the file is missing, the permissions are set incorrectly, etc.

LOL your not mean your helpfull and correct i dont know much about linux the custom path garbage is the krusader app ran what you said:

root@DeathStar:~# ls -la /mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd
-rwxrwxrwx 1 root root 3653632 Apr  4 15:54 /mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd*
root@DeathStar:~# 
 

 <type arch='x86_64' machine='pc-q35-4.2'>hvm</type>
    <loader readonly='yes' type='pflash'>/mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd</loader>
    <nvram>/mnt/user/system/custom_ovmf/Macinabox_VARS-pure-efi.fd</nvram>
  </os>

Also before this i had another error could not delete the VM kept getting

Requested operation is not valid: cannot delete inactive domain with nvram

Ran this virsh undefine --nvram "macinabox bigSur"

then was able to delete the vm and now i got this

Thanks

Edited by Kodiak51103
Link to comment

Ok, so we have ruled out the obvious.

I did a quick bit of googling and nothing jumped out at me.

You could always try using the default OVMF file rather than the Macinabox version and you could try using a newer q35 machine model. v4.2 is pretty old and you may be hitting a weird bug.

  <os>
    <type arch='x86_64' machine='pc-q35-5.1'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
    <nvram>/etc/libvirt/qemu/nvram/055c9315-8848-0404-267f-4ddbae41e8bf_VARS-pure-efi.fd</nvram>
  </os>

Of course update the VM identifier accordingly for the nvram file or keep using your existing Macinabox nvram file.

Link to comment
Posted (edited)

Well progress I guess I enter your xml and now the VM starts BUT when i click on the apple hd to start the process it displays the apple logo and appears to be stuck nothing happens after that. Im going to leave it here for awhile to see if it starts there is no load bar so guessing it's stuck. Also here is the macinabox log file:

-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-boot strict=on \
-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x7.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x7 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x7.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x7.0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \
-blockdev '{"driver":"file","filename":"/mnt/user/isos/BigSur-opencore.img","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-3-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-3-storage"}' \
-device ide-hd,bus=ide.2,drive=libvirt-3-format,id=sata0-0-2,bootindex=1,write-cache=on \
-blockdev '{"driver":"file","filename":"/mnt/user/isos/BigSur-install.img","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \
-device ide-hd,bus=ide.3,drive=libvirt-2-format,id=sata0-0-3,write-cache=on \
-blockdev '{"driver":"file","filename":"/mnt/user/domains/Macinabox BigSur/macos_disk.img","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"}' \
-device ide-hd,bus=ide.4,drive=libvirt-1-format,id=sata0-0-4,write-cache=on \
-netdev tap,fd=33,id=hostnet0 \
-device virtio-net,netdev=hostnet0,id=net0,mac=52:54:00:83:04:58,bus=pci.1,addr=0x0 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=34,server,nowait \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-device usb-tablet,id=input0,bus=usb.0,port=1 \
-vnc 0.0.0.0:0,websocket=5700 \
-k en-us \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \
-device virtio-balloon-pci,id=balloon0,bus=pci.3,addr=0x0 \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
2021-07-03 01:51:22.177+0000: Domain id=14 is tainted: high-privileges
2021-07-03 01:51:22.177+0000: Domain id=14 is tainted: host-cpu
char device redirected to /dev/pts/0 (label charserial0)

Edited by Kodiak51103
Link to comment
Posted (edited)
18 hours ago, Kodiak51103 said:

image.png.102d203255a2508ba8593291e7d9817b.png

 

Macinabox_CODE-pure-efi.fd is not the missing file: please read carefully the error message --> qemu is unable to find any master var store for the loader.

So it's the _VARS-pure-efi.fd file that is missing, either the path is wrong, or you deleted it or you undefined the vm, or permission issues, as it was written.

Edited by ghost82
Link to comment
53 minutes ago, ghost82 said:

 

Macinabox_CODE-pure-efi.fd is not the missing file: please read carefully the error message --> qemu is unable to find any master var store for the loader.

So it's the _VARS-pure-efi.fd file that is missing, either the path is wrong, or you deleted it or you undefined the vm, or permission issues, as it was written.

Yep, of course... Feel like a bit of an idiot :)

 

My understanding is that there is nothing special about this file between Macinabox and a generic install. It just holds the NVRAM vars.

As such all @Kodiak51103 should need to do is check to see if he has a VARS file under;

/mnt/user/system/custom_ovmf/

and that they are correctly defined in the <OS> section of his VM config.

or use the copy made when the VM was created under;

/etc/libvirt/qemu/nvram/

 

In the interest of keeping everything stock standard, I would recommend pulling the file(s) down from GitHub and put them back into the custom_ovmf directory. Then return the VM config back to default.
 

<os>
  <type arch='x86_64' machine='pc-q35-4.2'>hvm</type>
    <loader readonly='yes' type='pflash'>/mnt/user/system/custom_ovmf/Macinabox_CODE-pure-efi.fd</loader>
    <nvram>/mnt/user/system/custom_ovmf/Macinabox_VARS-pure-efi.fd</nvram>
</os>

 

  • Like 1
Link to comment
Posted (edited)

Thank you guys It's up and running although now when i try to load my apple id it says unable to communicate to server but I saw some posts about this will take a look. Thanks again I would have never got this running without your help!!

Edited by Kodiak51103
Link to comment
55 minutes ago, Kodiak51103 said:

Thank you guys It's up and running although now when i try to load my apple id it says unable to communicate to server but I saw some posts about this will take a look. Thanks again I would have never got this running without your help!!

Everything you need to fix it is here;

https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html#using-gensmbios

 

1) Set SystemProductName to iMacPro1,1 unless you really know what you are doing.

2) Generate a unique serial number, UUID and Board number using GenSMBIOS.

3) Check the serial number with the Apple Tool. It is fine to use an invalid serial number if your Apple ID is in good standing. I've been doing this for years on multiple VMs and never had an issue.

4) Set the MAC address of your VMs virtual network card to an Apple Inc address.

5) Set the ROM address to be the same.

6) Make sure your ethernet interface is "en0" and marked as internal.

Then you should be good to go.

Link to comment
1 hour ago, Kodiak51103 said:

Thanks again will work on this today. 

Ok i have EN0 but the bulitin is not checked nor can i check it so I ran the 2 commands

 

sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

sudo rm /Library/Preferences/SystemConfiguration/preferences.plist

rebooted the Vm still uncheck do i need to continue with the next step?

Dosen't say anything about having EN0 and box not checked. Don't want to make things worse. Thanks

Once done reboot and check again.

If this doesn't work, add NullEthernet.kext (opens new window)and ssdt-rmne.aml (opens new window)to your EFI and config.plist under Kernel -> Add and ACPI -> Add respectively. The SSDT is precompiled so no extra work needed, reminder compiled files have a .aml extension and .dsl can be seen as source code.

 

 

image.png.65a75b8f635ba4bf3840feb0693d63f7.png

Link to comment
8 hours ago, Kodiak51103 said:

Ok i have EN0 but the bulitin is not checked nor can i check it so I ran the 2 commands

sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

sudo rm /Library/Preferences/SystemConfiguration/preferences.plist

rebooted the Vm still uncheck do i need to continue with the next step?

Dosen't say anything about having EN0 and box not checked.

 

Actually it does talk about how to fix the en0 not having a check mark, but I agree that it's not well written.

 

https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html#fixing-en0

"Here under Network Interfaces (network card icon), look for en0 under BSD and check whether the device has a check mark under Builtin. If there is a check mark, skip to Fixing ROM section otherwise continue reading."
 

After running the two commands to delete the .plist files it actually gives instructions about what to do if you don't have an en0 interface so you can ignore the section about NullEthernet.kext and ssdt-rmne.aml since that isn't your issue.

 

Jump to "Now head under the PCI tab of Hackintool and export your PCI DeviceProperties, this will create a pcidevices.plist on your desktop..."

 

You just need to add the en0 interface PCI root to your config.plist to tell the OS that it is built-in.

1558209223_ScreenShot2021-07-05at9_21_45am.png.0eba32c0adcce01c4be2af15916b4f54.png

In my case I had to define the built-in option for the WiFI, Bluetooth and the NVMe SSD.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.