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


Recommended Posts

On 5/15/2021 at 11:00 PM, giganode said:

image.thumb.png.e6f091f26f794ae4d5b0c3a7d54af099.png

 

My god...what a monster!!

 

Yesterday I changed the hard drive configuration, switching from vdisk file on ssd to sata controller passthrough with the same ssd attached with mac os restored on it.

Well, performances increase a lot..From 237/257 MB/s (write/read) to 422/495 MB/s (write/read) with blackmagik software.

AmorphousDisk mark results follow:

speed.png.fa502cda1b9f5cb8894f4688e82fd9f5.png

Looking more into details, I found that this is because the virtual sata controller for vdisks in mac os is seen as a generic AHCI controller running at only 1,5 gigabit, the marvell 88se9230 I'm passing through runs at 6 gigabit.

Not sure if the emulated sata controller running at 1,5 gigabit is a limit of mac os or of qemu (in other words I don't know if in a windows or linux vm it runs at the same 1,5 gigabit speed), anyway if you have a spare sata controller running at higher speed it may worth to pass it through!

--> see below comment by giganode --> low speed probably related to too much overhead through virtualized devices.

 

Moreover I used to keep the bootloader in a separated img or qcow2 image file instead of on the mac os EFI partition, but it seems that trim/discard doesn't work with virtual sata and FAT32 on mac os, so if you keep writing and delete on the EFI image file the host doesn't sync the free space with the vm.

Passing through the sata controller and moving the EFI to the EFI partition of mac os seems to overcome this issue, since the disk is no more seen by the host and all is managed by mac os.

Edited by ghost82
Link to comment
On 4/28/2020 at 4:21 PM, ghost82 said:

Maybe we first need to choose a smbios such that the original SystemProductName is equipped with an optical drive..I doubt it is going to work with a sata bluray/dvd writer if the original iMacPro1,1 has no optical drive..In this case, a sata to usb adapter could work..

And it works instead..ideally every sata cd/dvd/bluray should work.

I'm currently using a teac bluray attached to the passed through sata controller.

Not sure if it's possible to pass through directly the cd/dvd/bluray drive in libvirt, I tried in the past without success, but I think I didn't choose correctly the bus to attach it, attaching it to a virtual sata controller could work.

 

dvd.png.4283da7aa43f0e4775fa525cf236b7c2.png

 

dvd2.png.b800e21d76971762d178188e4ac7a867.png

Edited by ghost82
Link to comment
On 12/13/2020 at 9:54 PM, bjornatic said:

I'm here for some help again...

 

I passed through my Nvme and I finally put it on the right soket (the one wich support GEN 4 over chipset).

The command : lspci -vvvn -s 04:00.0 | grep LnkSta

results in : LnkSta:    Speed 16GT/s (ok), Width x4 (ok)

 

But, in System Report, I get a blank for the "link speed" information.

 

After the install of BigSur, as my drive was on the first socket (GEN 3), "link speed" was 8GT/s (as it should have been).

 

Now how do I get my drive at 16GT/s under Big Sur ?

 

 

 

Not 100% sure on this, I'm replying only now because I'm playing with pcie slots, gpu and speeds.

In my case, in system report for the gpu it reports always 2,5 GT/s, with gpu under load or not, the grep command reports 2,5 GT/s under no load, but 8 GT/s (GEN3) under load.

This to say that if the grep command reports 16GT/s (GEN4) don't bother to system report, your nvme should work at the max speed.

Link to comment

Yes it's passed through. And its a SAMSUNG 980PRO.

 

1128765452_Capturedecran2021-05-22a09_50_07.png.1a59d023f9008a3c2cbf79c1ab94c6cd.png

1195152740_Capturedecran2021-05-22a09_55_38.thumb.png.05d6b62ea29c492f5a6361495179f2ce.png

<hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
      </source>
      <alias name='hostdev0'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</hostdev>

 

I read that the Samsung controller where tricky and not advised on a Hackintosh. But I found no specific info/comment on this one ("Elpis" controller).

Edited by bjornatic
additionnal infos
Link to comment

The fact that you have an empty field for the GT/s instead of 16, makes me think that the os doesn't include yet the 16GT/s for nvme, I don't think a real mac has never been built with gen4 slot.

Anyway I saw around builds with gen4 drives and speeds reaching about 4 GB/s (most are 1 TB and different than samsung).

May be related to the os (or the drive?), but I'm not 100% sure.

The advice on samsung controllers should be related to older ones, I think it's correct to avoid samsung, however if you don't have kernel panics it means yours should work quite well (?).

No doubt speed is slow if it fits a gen4 slot, if the bios settings are correct and if you placed devices in correct slots so to not eventually cut the bandwidth.

Edited by ghost82
Link to comment
On 5/16/2021 at 11:02 AM, ghost82 said:

 

My god...what a monster!!

 

Yesterday I changed the hard drive configuration, switching from vdisk file on ssd to sata controller passthrough with the same ssd attached with mac os restored on it.

Well, performances increase a lot..From 237/257 MB/s (write/read) to 422/495 MB/s (write/read) with blackmagik software.

AmorphousDisk mark results follow:

speed.png.fa502cda1b9f5cb8894f4688e82fd9f5.png

Looking more into details, I found that this is because the virtual sata controller for vdisks in mac os is seen as a generic AHCI controller running at only 1,5 gigabit, the marvell 88se9230 I'm passing through runs at 6 gigabit.

Not sure if the emulated sata controller running at 1,5 gigabit is a limit of mac os or of qemu (in other words I don't know if in a windows or linux vm it runs at the same 1,5 gigabit speed), anyway if you have a spare sata controller running at higher speed it may worth to pass it through!

 

Moreover I used to keep the bootloader in a separated img or qcow2 image file instead of on the mac os EFI partition, but it seems that trim/discard doesn't work with virtual sata and FAT32 on mac os, so if you keep writing and delete on the EFI image file the host doesn't sync the free space with the vm.

Passing through the sata controller and moving the EFI to the EFI partition of mac os seems to overcome this issue, since the disk is no more seen by the host and all is managed by mac os.

 

Hi @ghost82...

 

The 1,5 Gbit indicated in the system overview of macOS are not relevant. Here is a benchmark with my image, stored on an nvme:

 

image.thumb.png.ac12d4dbe4e762b40a8fab294a40e4d4.png

Edited by giganode
  • Like 1
Link to comment

Anyone passing through a firewire controller?

I don't have any device to test, I'm not sure it works, in about this mac --> system report --> firewire, I read:


Firewire bus
Warning: unable to list firewire devices

 

firewire.png.eef58091837419d86df8dac2a8e97a30.png

 

It's a VIA VT6315 chipset, firewire 400, from the boot log it seems correctly initialized.

In my original macbook pro, there's no device attached but I can read the bus speed instead of the warning; however in that macbook pro the isight should be connected to the firewire bus internally.

Link to comment
  • 2 weeks later...
7 hours ago, david279 said:

Simple install with any recently updated version of opencore

Hi, I had no doubt, I saw yesterday the presentation at wwdc and apart xcode cloud and universal control (which I don't use) there's nothing new (and so I imagine the boot has the same logic of big sur)..No need for an entire os update if this is what apple presents..So apart a recompilation of all the basic kexts just to add the new kernel version number, no particular changes are needed.

Hopefully since they didn't improve anything they had time to fix the ton of bugs still there in big sur.

Edited by ghost82
Link to comment
On 6/8/2021 at 1:00 AM, david279 said:

image.thumb.png.24cdb22c88ca1eca6fb6900036363fc8.png

 

Simple install with any recently updated version of opencore. I hear bluetooth breaks boot on bare metal so i would avoid that. Im using virtio for the network and the disk type and it boots just fine. Now to see what does not work.

Mind sharing your (neutralised) EFI ?

Have Big Sur running fine but after update it does not boot (kp's) . Did update lilu/weg etc before (and did set -lilubetaall ), but something is off . Probably too old OC or something.

edit : updated tp OC 0.7.0 but still same . Boots fine in BigSur but not in the Monterey mode. 

edit2 : came a bit further. Found that kernel patches where limited by the set max release value (20.99.99) , changing that to 21.99.99 moved the boot process further. Still crashing at the end in a boot loop with mentions of SMC issue but out of time this week to investigate further. Will have to settle for patience ;-)

Edited by glennv
Link to comment
5 hours ago, glennv said:

Mind sharing your (neutralised) EFI ?

Have Big Sur running fine but after update it does not boot (kp's) . Did update lilu/weg etc before (and did set -lilubetaall ), but something is off . Probably too old OC or something.

edit : updated tp OC 0.7.0 but still same . Boots fine in BigSur but not in the Monterey mode. 

 

I have -lilubetaall in the boot args thats the only thing i added there. The OC im using is 0.6.3 version for the VM. My laptop running Monterey is on 0.6.9 with pretty much the same boot args and all my kext were update as of the yesterday. I will say i have a bug where it boot loops on VNC for some reason. Passing thru a gpu maybe more stable.

Link to comment

Ah , just when i wanted to call it a day, it started working ;-)
Issue was related to me using/trying to boot from an earlier created Monterey update partition, before i messed with opencore/nvram clearing etc etc when booting in the BigSur partition. So likely not valid anymore (nvram, seal , stuff like that) . 
I just booted in BigSur again and re-ran the updater, which recreated that partition and voila.  Update is running fine now and no boot issues.
The real issue in "my" opencore config was as i mentioned the max value limit (minkernel/maxkernel) on the kernel patches. The rest was noise . Likely would have also worked on my original pre 0.7 version. 
 
Edit : upgrade finished and entered into a screen loop (vnc) like you mentioned experiencing as well (see screenshot of looping 4 lines).
image.png.128567b9a931f2eaebd14e7769f25b40.png
Will try it some other day on GPU. I can dial into the VM via SSH , which works fine.
 
Edit 2:
Did a quick try with GPU to satisfy my curiosity (5700XT). Did get a black screen (but that can be something else) , but i could use RDP to dial in and proved it works.
image.png.e8bcd04a3049afa9a755e456ccd4126e.png
 
Just no VNC (looping. Login windows crashed. ssh works).
 
So almost but no sigar yet ;-)

Edited by glennv
Link to comment
On 6/9/2021 at 3:46 PM, glennv said:

Maybe we hit the same VNC bootloop then , who knows ;-)

 

Solved the mysterous VNC bootloop issue.

1.  Log in with a GPU passed thru (i used RDP as my GPU showed black at the time)

2. Set autologin in user options (seems to be an issue with login process looping in some cases)

3. Reboot without GPU passed thru and now VNC works fine.

 

Link to comment
4 hours ago, glennv said:

Solved the mysterous VNC bootloop issue.

1.  Log in with a GPU passed thru (i used RDP as my GPU showed black at the time)

2. Set autologin in user options (seems to be an issue with login process looping in some cases)

3. Reboot without GPU passed thru and now VNC works fine.

 

Do you also experience some laggs within a few seconds? It seems fluid but nearly every 5 seconds its get laggy, but immideatly back to normal, then again a short lagg and back to normal XD

Maybe I revert back to Big Sur xD

Link to comment
1 hour ago, RiDDiX said:

Do you also experience some laggs within a few seconds? It seems fluid but nearly every 5 seconds its get laggy, but immideatly back to normal, then again a short lagg and back to normal XD

Maybe I revert back to Big Sur xD

Nope cant say i have that. Seems all fluid. Did a quick performance test with Davinci Resolve and the passed thru 5700XT and seems exactly the same or even slightly faster than my normal production Resolve Render VM on Catalina.

Have not spend much time with it yet. Just for base testing my own code against he new OS , but as little seems to have changed compared to BigSur all is fine there.

 

I remember from my old Windows 10 VM's when i used them for gaming i did have these stutters , but typicaly where related to passed thru usb and or network polling latency issues. On OSX i have not seen this yet. But then again currently i have no USB card yet passed thru to this test VM. If i notice anything in the coming days i will let you know.  

Probably best to wait for the next beta anyway. Also i run Intel and you Ryzen so check for Ryzen related issues. I do remember seeing some reddit posts on Ryzen patches.

Edited by glennv
Link to comment
  • 1 month later...

For who is using the x86_validate_topology patch, there's a new patch that covers a wider range of kernels (I remember I had to change this patch from Mojave to Catalina and to Big Sur).

This is the new patch, should be valid for mac os monterey too:

			<dict>
				<key>Arch</key>
				<string>x86_64</string>
				<key>Base</key>
				<string>_x86_validate_topology</string>
				<key>Comment</key>
				<string>XLNC - Disable _x86_validate_topology - 10.13/10.14/10.15/11.0/12.0</string>
				<key>Count</key>
				<integer>0</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>
				</data>
				<key>Identifier</key>
				<string>kernel</string>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data>
				</data>
				<key>MaxKernel</key>
				<string>21.99.99</string>
				<key>MinKernel</key>
				<string>17.0.0</string>
				<key>Replace</key>
				<data>
				ww==
				</data>
				<key>ReplaceMask</key>
				<data>
				</data>
				<key>Skip</key>
				<integer>0</integer>
			</dict>

 

Also, the force penryn patch was recently modified to be compatible from big sur 11.3+ till monterey, for big sur 11.3+/Monterey 12:

			<dict>
				<key>Arch</key>
				<string>x86_64</string>
				<key>Base</key>
				<string>_cpuid_set_info </string>
				<key>Comment</key>
				<string>algrey - _cpuid_set_cpufamily - Force CPUFAMILY_INTEL_PENRYN - 11.3 + / 12.0</string>
				<key>Count</key>
				<integer>1</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>
				gD0AAAAABnU=
				</data>
				<key>Identifier</key>
				<string>kernel</string>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data>
				//8AAAAA//8=
				</data>
				<key>MaxKernel</key>
				<string>21.99.99</string>
				<key>MinKernel</key>
				<string>20.4.0</string>
				<key>Replace</key>
				<data>
				urxP6ngx2+s=
				</data>
				<key>ReplaceMask</key>
				<data>
				</data>
				<key>Skip</key>
				<integer>0</integer>
			</dict>

 

Edited by ghost82
  • Thanks 1
Link to comment

Commit 9324c9e:

https://github.com/acidanthera/OpenCorePkg/commit/9324c9e32c8b1cb714f2869b4fdde72f92d58bf4

in opencore 0.7.2 increases the default MinDate and MinVersion of APFS driver date/version to that of Big Sur.

If you have default values of MinDate and MinVersion (equal to integer=0) in your config.plist, you are running an os older than big sur and you updated opencore to a version equal or subsequent to that commit, you need to either disable, setting MinDate and MinVersion to -1 (integer) (not recommended), or manually set MinDate and MinVersion in the config.plist.

For example, if you're running Catalina, with MinDate and MinVersion equal to zero, you will not be able to boot, since the minimum date/version of the apfs driver is that of big sur.

 

To boot Catalina (at least 10.15.4) you need to set these values in the apfs section of the config.plist:

			<key>MinDate</key>
			<integer>20200306</integer>
			<key>MinVersion</key>
			<integer>1412101001000000</integer>

 

Other values:

High Sierra (10.13.6 - 17G12034)

MinDate: 20180621

MinVersion: 748077008000000

 

Mojave (10.14.6 - 18G4032)

MinDate: 20190820

MinVersion: 945275007000000

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.