** Hackintosh ** Tips to make a bare metal MacOS


Recommended Posts

Thanks for the update!

So, are we able again to inject kexts in some way (bootloader kext compatibility mode with nvram variables)?

As far as I read kext injection doesn't work during installation yet, so you need a preinstalled image of mac os and add nvram variables in the bootloader (opencore) for kext injection compatibility mode (for now only lilu, whatevergreen, applealc, virtualsmc).

We are only at the beginning, who knows if it will be possible or not..however as it is now, it has too many restrictions, this means you probably won't be able to perform os updates in the usual way..

And not clear to me what cpus could be passed through, I hope sandy bridge will be included in some way...

Edited by ghost82
Link to comment

Ok to get this started i had to use some files from http:// https://github.com/kholia/OSX-KVM/tree/master/OpenCore-BS

Big shout out time kholia because without his files I would have not been able to get this started. A couple files needed from there are OVMF_VARS-1024_768.fd, OVMF_CODE.fd and his Opencore.qcow2 made for Big sure. The opencore img thats used is kinda bear with only the options included needed to boot but it works. 

 

First thing you are going to need is an installer image. I created one by using the gibMac script on my Catalina VM to pull down the developer preview. The files that will be downloaded will not be a straight up installer. With the set of files that will be downloaded the main one we need is a package called InstallerHelper. Install that pkg and it should add a Install Mac os beta app into your Application folder. Use that app to create a installer disk. I added a 16GB vdisk to my Catalina VM and used that to make the installer disk. You can use the disk utility to make a disk image on the VM and use that to make a installer disk if you perfer. I used the createmediainstaller command to make the installer disk. https://support.apple.com/en-us/HT201372

I had to use 16 GB for the image size, anything less than that the command would not bless and make the installer image bootable, strange bug. So do not try 8GB or something. Once you have the installer image created its time to use that make the VM.

 

Create Your VM like a normal Hackintosh style VM...with all the hackintosh needed bits. Instead of going with the normal OVMF paths unRAID adds use the files from Kholia link above and add there paths to them on your unRAID system. The files are from proxmox but they are needed to boot the Big Sur installer/system. Unraids OVMF crash right after you set the install boot selection so for right now we can not use it. Use his opencore image as the main boot image , add a vdisk for the systems main disk and add the installer image as the third disk to install Big Sur. Boot up the VM, select the big sur installer and install as a normal hack VM.

 

Once you have you system setup you will needed to make a couple edits to your opencore config.plist to make kext injection work. The system does not needed any kext to install or function in pure vnc form but if you plan on passing thru a GPU or onboard sound, hardware etc....You will need kext like lilu, whatevergreen or applealc. You will need versions of lilu, whatevergreen and applealc with the big sur bits for it to work with big sur. I found them here https://onedrive.live.com/?authkey=%21APjCyRpzoAKp4xs&id=FE4038DA929BFB23%21455036&cid=FE4038DA929BFB23

Also you need version 0.60 of opencore with added support for big sur. This one should work. https://1drv.ms/u/s!AiP7m5LaOED-npRyiiFiyxR0R46u3g

All this stuff can be found thru the Hackintosh discord.

 

Screenshot_from_2020-06-25_22-54-04.png.0ea8800c2366fca6e4717d36affc7856.png

 

Now to editing your config.plist. All the lines with the booter-fileset-basesystem, booter-fileset-kernel  need to be added as seen above. Also for lilu to work you need the -lilubetaall boot-arg for it to work in big sur. With those edits made then update opencore to 0.60. Now shutdown your VM. 

At this point if you try to boot right back into Big Sur it will crash. For whatever reason after adding the patches above will cause a kernel panic with a topology crash so you will need to remove all the topology lines from your VM. I tried to use the topology patch we have used here but it still did not work. Once you remove the topology line the VM will boot right up with working kext injection. I have a full VM setup with a GPU, usb pci-e wifi bluetooth card, onboard sound all working great. 

 

The system right pretty good right now. You will find apps that straight up crash like maps but this is a dev preview. Opencore should get some fixes soon that will make kext injection work without the config.plist edits made above. Also as opencore is updated maybe we can go back to unRAIDs OVMF files for bootup. 

OVMF_CODE.fd OVMF_VARS-1024x768.fd

Edited by david279
  • Like 1
Link to comment

If we are able to install and not to restore mac os by setting properly opencore and by changing the ovmf files, this is a good news, but I hope someone will figure out how to inject kexts during the boot.

Thanks for your report!

Strange that the last commits on kholia about ovmf files is last month, so not changed after the release of big sur..can you try if you want and if you have time if the latest stable stock ovmf files (may 2020) work?If it boots, maybe this could be solved with the update of unraid (and hopefully stock ovmf files). If it doesn't boot it shouldn't be too difficult (at least I think so..) to report to the opencore stuff and make a commit for it, as you also stated.

"Custom" opencore image could be a change in the config.plist file only to disable some quirks, boot had problems which maybe are already solved with latest commits.

 

Update: attachment removed, please read here:

 

Edited by ghost82
Link to comment

I just wanted to emphasize the OSX-KVM Github repo. After days of experimenting with all the scattered information and tips on this topic with still having issues with my VM (mostly audio dropouts, which made music production impossible, one of the main tasks for my macOS VM), I today decided to basically replace all files and the VM setup with the files in that repo – and now my VM runs butter smooth. So for anyone experiencing performance issues, I strongly advise to check that repo out.

Link to comment

Another tip if you have issues with mouse: I have a microsoft wireless mouse 1000 and I noticed issues with the scroll, not smooth at all and it was nearly impossible to scroll and read content in a page, even with tuning settings in mac os system preferences.

After disassembling all my mouses thinking about mechanical problems I found it was apple related.

So, I found a simple free application called MOS and the scroll is now perfect.

https://mos.caldis.me/

 

Github repo:

https://github.com/Caldis/Mos

Edited by ghost82
Link to comment

An internal link to enable trim and make the host to sync the size of the vdisk when you delete files on vdisk (without this since we are using sparse images the size of the vdisk increases on the host without syncing, when deleting files on the guest) :

 

 

Edited by ghost82
Link to comment
On 6/1/2020 at 9:29 PM, david279 said:

I want to try out the Virtio support it added

I tried virtio this morning without any luck..both for networks and for disks.

For disks it doesn't boot (someone stated that it works for additional disks), for networks I have weird issues, mac address is not assigned (it seems a random one is assigned) and network doesn't work properly (no route to host).

e1000-82545em is still rock solid.

Did you try?

Link to comment
Just now, ghost82 said:

ok, again thank you, then there's something wrong with my setup, could you kindly post the xml part relevant to disks?

<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback'/>
      <source file='/mnt/cache/domains/Catalina/catalina.opencorev0591.qcow2'/>
      <target dev='hdc' bus='usb'/>
      <boot order='1'/>
      <address type='usb' bus='0' port='1'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/>
      <source file='/mnt/disks/MKNSSDRE500GB_MK170901100386B42/Hackintosh/Catalina.img'/>
      <target dev='hdd' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>

 

  • Like 1
Link to comment
1 hour ago, david279 said:

<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback'/>
      <source file='/mnt/cache/domains/Catalina/catalina.opencorev0591.qcow2'/>
      <target dev='hdc' bus='usb'/>
      <boot order='1'/>
      <address type='usb' bus='0' port='1'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/>
      <source file='/mnt/disks/MKNSSDRE500GB_MK170901100386B42/Hackintosh/Catalina.img'/>
      <target dev='hdd' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>

 

That helped and I'm able to make the virtio to work, but I'm not quite happy (maybe it's only related to some missing settings):

More into details I'm not able to sync the size of the disk on the guest with the host: let's say if I copy a file from the host to the guest the available space on the disk decreases both on the guest and on the host, and that's ok, but if I delete the file on the guest, the available size increases on the guest but not on the host.

With sata, with changes on cache/io/discard (as yours) and with custom qemu args to enable trim the size syncs between guest and host: do you have the same issue?

Link to comment

From the opencore github repo I can see that Acindanthera team is fixing kernel collection for kext injection if I understood well; that's good news, maybe in a week we will have a working oc able to install big sur in the usual way.

 

05/07/2020: OcAppleKernelLib: Get kernel patcher work (mostly)

Edited by ghost82
Link to comment
5 hours ago, david279 said:

@ghost82 I got the Big Sur installer to boot with the latest master from Opencore and Lilu using the stock OVMF files.

 

881525962_Screenshotfrom2020-07-0521-20-06.thumb.png.7ceefd9c04efff337e27ae2ce8c2c48a.png

Same here, but partially success..It hangs after the second reboot, after booting from Preboot; latest error is: No port micro restart (we don't support SMC on this platform)

After this it reboots and loops.

 

IMG_20200706_091543.thumb.jpg.bd8bb014c38bfbcece738a1234cd62ac.jpg

 

It seems the same issue reported here:
http://bbs.pcbeta.com/forum.php?mod=viewthread&tid=1861942

 

And by translating the content they said they copy another clover efi, boot from oc, pointing to clover, pointing to mac os, but I don't like it at all.

Things are moving faster now!

Edited by ghost82
Link to comment

Adding vsmcgen=1 (virtualsmc) to boot-args solved the issue and the installation seems to proceed, I will update later.

 

UPDATE: after solving the above issue it was stuck at "Forcing CS_RUNTIME for entitlement: com.apple.rootless.restricted-block-devices": I needed a forced shutdown and a new boot pointing at the new partition (Mac-Os-Big-Sur) or whatever you named the hd.

 

SUCCESS (installation, not restore)

 

BigSur.thumb.png.84e8b448df06e027b01519aa07ce9c9a.png

 

Kext injection and kernel patching work, audio works, gpu passthrough works, cpu passthrough works! All seems to work quite well for this dev beta.

Edited by ghost82
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.