[Support] SpaceinvaderOne - Macinabox


Recommended Posts

3 hours ago, ghost82 said:

Premise is that I don't use macinabox now, but it seemed that method 2 in the docker from ca was method 1 in github code when I tested it the first time; I'm not sure is still like this, can you check if method 1 downloads few hundreds of MB or about 12 GB? --> during the download you can check folder /isos and look for the file size.

If method 1 is the same method 1 in github (method 1 is fetch-macos2.py in github), I pushed a pr for it:

https://github.com/SpaceinvaderOne/Macinabox/pull/54

 

Did you apply it, together with all my other prs?

Hi! thanks for the help.

 

It downloaded a 3.3GB file named "BigSur-install.img" i don't know if this is correct or I checked too late.

 

I don't know how to apply your prs sorry

Link to comment
6 minutes ago, Bullerwins said:

It downloaded a 3.3GB file named "BigSur-install.img" i don't know if this is correct or I checked too late.

Well, I just checked now and the method you chose seems to download the full installer (btw 3.3Gb is an incomplete installer, full installer size should be 12 Gb or so), but I don't know what it downloads (I didn't try it)...

 

If you choose the other method (with the pr applied, board id Mac-2BD1B31983FE1663) it should download a BaseSystem of 637.20MB, corresponding to big sur 11.6 recovery image.

If you choose the other method (without the pr applied, board id Mac-E43C1C25D4880AD6) it should download a BaseSystem of 611.44MB, corresponding to monterey 12.0.1 recovery image.

 

So pr is needed for the "other method" to correctly download the big sur recovery image, instead of monterey.

Link to comment
On 10/28/2021 at 9:08 AM, ghost82 said:

I think it's not your error: I find that the product id of big sur changed, so 071-00696 is no longer valid.

I pushed a pr for it:

https://github.com/SpaceinvaderOne/Macinabox/pull/55

Moreover, the basesystem which will download the recovery image may not work with the board id coded in the script, I pushed another pr for it:

https://github.com/SpaceinvaderOne/Macinabox/pull/54

 

So, you should apply these pr manually until they get merged..

Here there are instructions that may work:

https://github.com/SpaceinvaderOne/Macinabox/pull/49#issuecomment-898740266

This replaced the opencore img and the unraid.sh

 

Obviously, you need to change the https addresses pointing to the new files and also apply (add) the fix for the board id and opencore img.

 

Thanks for your time and effort. I will try again later.

Link to comment
1 hour ago, steve1977 said:

GPU passthrough still working?

 

1 hour ago, steve1977 said:

Anything to keep in mind?

Don't use q35-6.1 (this is valid for all mac oses), if you're using 6.10 RC, use 6.0 or lower; nvidia kepler support is not available.

Edited by ghost82
Link to comment

Thanks. I am running the upgrade now. Will keep you posted how it goes.

 

I hadn't used the VM for a while. Noticed two things:

 

1) Facetime and iMessenger no longer work. Cannot log in. Both used to work some while ago. What can I do to get them working again?

 

2) Opencore suggests that I do an update. Should I do this?

 

 

Link to comment
12 minutes ago, steve1977 said:

1) Facetime and iMessenger no longer work. Cannot log in. Both used to work some while ago. What can I do to get them working again?

Check en0 is built-in with hackintool or ioregistry explorer.

Do not use vmxnet3, either use e1000-82545em or virtio or virtio-net.

 

15 minutes ago, steve1977 said:

2) Opencore suggests that I do an update. Should I do this?

Opencore cannot suggest to update; you mean opencore configurator?Don't use it to open the config.plist, don't use it at all, or use it ONLY as an EFI mounter.

Link to comment

You’re right, the configurator. Should i uninstall it?

 

I thought i used the configurator before for some of the checks you suggest above? That no longer works?

 

Can you share a bit more how to do the steps you suggest above? don’t think i’ve ever used any of these tools.

 

Thanks for your help!

Link to comment
25 minutes ago, ghost82 said:

Check en0 is built-in with hackintool or ioregistry explorer.

With hackintool:

hackintool.png.75c5fb9d1272f07e6cc699b5342d9279.png

Or with ioregistry explorer:

ioregistry.thumb.png.01ae6ae1603c07a98fea38ed82863852.png

 

If it's not built in change the bus address in the xml of the vm to 0x00 (and obviously set a free slot), this will make the network built-in without applying any patch:

xml.png.9d55aa43843e4fe4206ff80b756a4d7b.png

 

33 minutes ago, ghost82 said:

Do not use vmxnet3, either use e1000-82545em or virtio or virtio-net

 

This is done in the xml of the vm:

xml1.png.40014b374c063f05c1b0dd99b404f0a5.png

 

 

26 minutes ago, steve1977 said:

I thought i used the configurator before for some of the checks you suggest above? That no longer works?

Most probably you used it to change the smbios data.

Each opencore configurator version requires a very specific version of opencore; for example, if you update the configurator and you load a config.plist of an older opencore version it will mess it, resulting in an unbootable system.

As I said, if you don't load the config.plist (you use it for example as an efi mounter with a gui), or if you use the version corresponding to the version of opencore it was built for, then it's fine.

 

Always make backups before updating.

Link to comment

Thanks a lot. WIll look into it.

 

Unfortunately, update to Monterrey "bricked" my VM. I tried to switch back to VNC to understand what's going on, but this also doesn't work (guest has not initiated the screen yet). I remember the latter error was easily fixable through some change in the XML (and a bug when switching back from passthrough to VNC). I couldn't find though what I had to change in the XML. Anyone remember?

Link to comment
10 hours ago, steve1977 said:

Thanks a lot. WIll look into it.

 

Unfortunately, update to Monterrey "bricked" my VM. I tried to switch back to VNC to understand what's going on, but this also doesn't work (guest has not initiated the screen yet). I remember the latter error was easily fixable through some change in the XML (and a bug when switching back from passthrough to VNC). I couldn't find though what I had to change in the XML. Anyone remember?

I had this happened to me when switching from GPU passthough to VNC. I had to delete the VM (keeping the disks) and recreating it again to fix it. I haven't tried if there is a better solution.

On 10/25/2021 at 1:54 PM, ghost82 said:

I understand it can be difficult to manually edit the config.plist to update smbios data.

As I wrote I pushed a pr to the container.

Since it's not merged yet, you can "manually" apply the changes by following these advices:

0. clean the container, delete all files

1. Setup Macinabox in Apps (uncheck Autostart)

2. 

wget https://github.com/SpaceinvaderOne/Macinabox/raw/2a2400c44af497a00f2610523cb0c0844d2aae27/bootloader/OpenCore.img.zip

3. 

docker cp ./OpenCore.img.zip macinabox:/Macinabox/bootloader/OpenCore.img.zip

4. Start Docker Container and proceed as normal

 

Then, you can use opencore configurator, latest version at the time of writing, or better to use v. 2.51.0.0:

https://mackie100projects.altervista.org/download/opencore-configurator-2-51-0-0/

 

since the latest version 2.52.0.0 supports opencore development version (not stable) which added a couple of new options in the config.plist.

I ended up installing Monterey (I didn't know how to fix the download methods) with this fix to update the opencore version. GPU passthough was not working with a rx580 with the default version, or maybe it was the .kexts? It works fine now with the exception that I cannot pass 18,20 or 22 cores.. even though i had the remove topology to "yes" in the macinabox user script. I had to choose 16

Link to comment

Hi all,

 

Had a question for those who had to configure audio in their VM.

 

I was able to get an install of macOS Monterey going. I was able to get Apple services, GPU pass thru, network, etc.

 

I followed this article for audio: https://dortania.github.io/OpenCore-Post-Install/universal/audio.html#testing-your-layout

 

I was working on audio last night using OpenCore Configurator and it will work if I have the boot-arg in the NVRAM section. But, if I add the layout-id via Device Properties and remove the boot-arg as stated it doesn't appear to work.

 

Am I doing something incorrectly?

 

Also, does anyone use VoodooHDA instead? I'm curious to see if that will get my line-in for mic to work but it's not a deal breaker as I may just opt to use a USB audio interface since I'm planning to utilize this VM more for music production.

 

Thanks in advance!

Edited by Donny S Beatz
misspelling
Link to comment
33 minutes ago, Donny S Beatz said:

Am I doing something incorrectly?

Probably yes if it works with boot-arg but not by injecting the layout :D

 

To correctly apply layout id:

0. Make sure audio is on bus 0x00 in your xml

1. Find the correct device path with hackintool (in this example PciRoot(0x0)/Pci(0x2,0x0)):

audio.thumb.png.a1e0abb1010e492771f12f237679a54a.png

 

2. Mount the efi and open the config.plist with a text editor; in "DeviceProperties --> Add" add your layout-id:

	<key>DeviceProperties</key>
	<dict>
		<key>Add</key>
		<dict>
			<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
			<dict>
				<key>layout-id</key>
				<data>BwAAAA==</data>
			</dict>
          ....
          ....

 

Use an integer (decimal) to base64 converter, for example:

https://v2.cryptii.com/decimal/base64

In this example BwAAAA== base64 means 7 0 0 0 decimal (7<space>0<space>0<space>0), so in that site if layout is 7 input 7 0 0 0 and convert it.

For a 2 digits layout, for example 13, input it like 13 0 0 0 (13<space>0<space>0<space>0).

 

3. Remove the layout id boot arg

 

You may want to read also this, related to audio and device path:

 

33 minutes ago, Donny S Beatz said:

Also, does anyone use VoodooHDA instead? I'm curious to see if that will get my line-in for mic to work but it's not a deal breaker

I was using that in the past, but switched to AppleALC since it has better quality.

About the line-in are you sure you are using the correct layout?What's your codec/motherboard?

Edited by ghost82
  • Like 1
Link to comment
6 hours ago, Bullerwins said:

It works fine now with the exception that I cannot pass 18,20 or 22 cores.. even though i had the remove topology to "yes" in the macinabox user script. I had to choose 16

20 22 cores will not work for sure, it's an odd number of cores.

However it's possible to run it with a modification to the xml: you set all the cores, but you disable some of them.

This is the setup I'm currently running, with 28 cores (2x xeon 16 cores each):

 

  <vcpu placement='static' current='28'>32</vcpu>
  <vcpus>
    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
    <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/>
    <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/>
    <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/>
    <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/>
    <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/>
    <vcpu id='6' enabled='yes' hotpluggable='yes' order='7'/>
    <vcpu id='7' enabled='yes' hotpluggable='yes' order='8'/>
    <vcpu id='8' enabled='yes' hotpluggable='yes' order='9'/>
    <vcpu id='9' enabled='yes' hotpluggable='yes' order='10'/>
    <vcpu id='10' enabled='yes' hotpluggable='yes' order='11'/>
    <vcpu id='11' enabled='yes' hotpluggable='yes' order='12'/>
    <vcpu id='12' enabled='yes' hotpluggable='yes' order='13'/>
    <vcpu id='13' enabled='yes' hotpluggable='yes' order='14'/>
    <vcpu id='14' enabled='yes' hotpluggable='yes' order='15'/>
    <vcpu id='15' enabled='yes' hotpluggable='yes' order='16'/>
    <vcpu id='16' enabled='yes' hotpluggable='yes' order='17'/>
    <vcpu id='17' enabled='yes' hotpluggable='yes' order='18'/>
    <vcpu id='18' enabled='yes' hotpluggable='yes' order='19'/>
    <vcpu id='19' enabled='yes' hotpluggable='yes' order='20'/>
    <vcpu id='20' enabled='yes' hotpluggable='yes' order='21'/>
    <vcpu id='21' enabled='yes' hotpluggable='yes' order='22'/>
    <vcpu id='22' enabled='yes' hotpluggable='yes' order='23'/>
    <vcpu id='23' enabled='yes' hotpluggable='yes' order='24'/>
    <vcpu id='24' enabled='yes' hotpluggable='yes' order='25'/>
    <vcpu id='25' enabled='yes' hotpluggable='yes' order='26'/>
    <vcpu id='26' enabled='yes' hotpluggable='yes' order='27'/>
    <vcpu id='27' enabled='yes' hotpluggable='yes' order='28'/>
    <vcpu id='28' enabled='no' hotpluggable='yes'/>
    <vcpu id='29' enabled='no' hotpluggable='yes'/>
    <vcpu id='30' enabled='no' hotpluggable='yes'/>
    <vcpu id='31' enabled='no' hotpluggable='yes'/>
  </vcpus>
  <cputune>
    <vcpupin vcpu='0' cpuset='1'/>
    <vcpupin vcpu='1' cpuset='2'/>
    <vcpupin vcpu='2' cpuset='3'/>
    <vcpupin vcpu='3' cpuset='4'/>
    <vcpupin vcpu='4' cpuset='5'/>
    <vcpupin vcpu='5' cpuset='6'/>
    <vcpupin vcpu='6' cpuset='7'/>
    <vcpupin vcpu='7' cpuset='9'/>
    <vcpupin vcpu='8' cpuset='10'/>
    <vcpupin vcpu='9' cpuset='11'/>
    <vcpupin vcpu='10' cpuset='12'/>
    <vcpupin vcpu='11' cpuset='13'/>
    <vcpupin vcpu='12' cpuset='14'/>
    <vcpupin vcpu='13' cpuset='15'/>
    <vcpupin vcpu='14' cpuset='17'/>
    <vcpupin vcpu='15' cpuset='18'/>
    <vcpupin vcpu='16' cpuset='19'/>
    <vcpupin vcpu='17' cpuset='20'/>
    <vcpupin vcpu='18' cpuset='21'/>
    <vcpupin vcpu='19' cpuset='22'/>
    <vcpupin vcpu='20' cpuset='23'/>
    <vcpupin vcpu='21' cpuset='25'/>
    <vcpupin vcpu='22' cpuset='26'/>
    <vcpupin vcpu='23' cpuset='27'/>
    <vcpupin vcpu='24' cpuset='28'/>
    <vcpupin vcpu='25' cpuset='29'/>
    <vcpupin vcpu='26' cpuset='30'/>
    <vcpupin vcpu='27' cpuset='31'/>
    <emulatorpin cpuset='0,8,16,24'/>
  </cputune>

 

About the remove topology, there's a patch to avoid the kernel panic, having the correct topology is not so important, there's no improvement in performace.

 

		<key>Patch</key>
		<array>
			<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></string>
				<key>MinKernel</key>
				<string></string>
				<key>Replace</key>
				<data>
				ww==
				</data>
				<key>ReplaceMask</key>
				<data>
				</data>
				<key>Skip</key>
				<integer>0</integer>
			</dict>

 

Edited by ghost82
  • Thanks 1
Link to comment
1 hour ago, ghost82 said:

Probably yes if it works with boot-arg but not by injecting the layout :D

 

To correctly apply layout id:

0. Make sure audio is on bus 0x00 in your xml

1. Find the correct device path with hackintool (in this example PciRoot(0x0)/Pci(0x2,0x0)):

audio.thumb.png.a1e0abb1010e492771f12f237679a54a.png

 

2. Mount the efi and open the config.plist with a text editor; in "DeviceProperties --> Add" add your layout-id:

	<key>DeviceProperties</key>
	<dict>
		<key>Add</key>
		<dict>
			<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
			<dict>
				<key>layout-id</key>
				<data>BwAAAA==</data>
			</dict>
          ....
          ....

 

Use an integer (decimal) to base64 converter, for example:

https://v2.cryptii.com/decimal/base64

In this example BwAAAA== base64 means 7 0 0 0 decimal (7<space>0<space>0<space>0), so in that site if layout is 7 input 7 0 0 0 and convert it.

For a 2 digits layout, for example 13, input it like 13 0 0 0 (13<space>0<space>0<space>0).

 

3. Remove the layout id boot arg

 

You may want to read also this, related to audio and device path:

 

I was using that in the past, but switched to AppleALC since it has better quality.

About the line-in are you sure you are using the correct layout?What's your codec/motherboard?

 

Thank you for the reply! I will take a look at this later tonight.

 

The motherboard is a Gigabyte B450 AORS PRO WIFI - which has the same Realtek ALC1220 used in the article.

 

Just to clarify I should remove the boot-arg, then in the Device Properties add a layout-id value of "11 0 0 0" and that should work?

 

Also thank you for linking the thread, I will go through that as well.

Link to comment
On 10/29/2021 at 12:53 PM, ghost82 said:

Well, I just checked now and the method you chose seems to download the full installer (btw 3.3Gb is an incomplete installer, full installer size should be 12 Gb or so), but I don't know what it downloads (I didn't try it)...

 

If you choose the other method (with the pr applied, board id Mac-2BD1B31983FE1663) it should download a BaseSystem of 637.20MB, corresponding to big sur 11.6 recovery image.

If you choose the other method (without the pr applied, board id Mac-E43C1C25D4880AD6) it should download a BaseSystem of 611.44MB, corresponding to monterey 12.0.1 recovery image.

 

So pr is needed for the "other method" to correctly download the big sur recovery image, instead of monterey.

 

@ghost82 How do I apply this fix to an existing docker, to get back to being able to install BigSur?

Link to comment
10 hours ago, ghost82 said:

<data>CwAAAA==</data>

 

I would try all the layouts available if line in doesn't work.

https://github.com/acidanthera/AppleALC/tree/master/Resources/ALC1220

 

Check all the files named layoutXXX.xml and try all that listed XXX as layout-id until you find the one working for you.

 

I'm not entirely sure what i'm doing wrong.

 

I tested the different layout IDs and went through each one on the list but still can't seem to get audio to work when applying it via Device Properties.

 

If i do the boot-args method it will work.

 

Am I missing something?

 

 

Screen Shot 2021-11-02 at 11.39.45 PM.png

Link to comment
2 hours ago, Donny S Beatz said:

I'm not entirely sure what i'm doing wrong.

You are not converting correctly from decimal to base64, I explained that.

Don't use hexadecimal, dortania is saying AppleALC could accept hexadecimal values, not opencore.

in your screenshot you applied a layout id of 0CAAAA00 --> ??? (layout 12?? don't know how you converted it :D ...anyway not converted correctly)

 

Correct values (type DATA):

Layout 1:          AQAAAA==

Layout 100:      ZAAAAA==

Layout 11:         CwAAAA==

Layout 13:         DQAAAA==

Layout 15:         DwAAAA==

Layout 16:         EAAAAA==

Layout 17:         EQAAAA==

Layout 2:          AgAAAA==

Layout 21:         FQAAAA==

Layout 27:         GwAAAA==

Layout 28:         HAAAAA==

Layout 29:         HQAAAA==

Layout 3:          AwAAAA==

Layout 30:         HgAAAA==

Layout 34:         IgAAAA==

Layout 35:         IwAAAA==

Layout 5:          BQAAAA==

Layout 7:          BwAAAA==

Layout 98:         YgAAAA==

Layout 99:         YwAAAA==

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

You are not converting correctly from decimal to base64, I explained that.

Don't use hexadecimal, dortania is saying AppleALC could accept hexadecimal values, not opencore.

in your screenshot you applied a layout id of 0CAAAA00 --> ??? (layout 12?? don't know how you converted it :D ...anyway not converted correctly)

 

Correct values (type DATA):

Layout 1:          AQAAAA==

Layout 100:      ZAAAAA==

Layout 11:         CwAAAA==

Layout 13:         DQAAAA==

Layout 15:         DwAAAA==

Layout 16:         EAAAAA==

Layout 17:         EQAAAA==

Layout 2:          AgAAAA==

Layout 21:         FQAAAA==

Layout 27:         GwAAAA==

Layout 28:         HAAAAA==

Layout 29:         HQAAAA==

Layout 3:          AwAAAA==

Layout 30:         HgAAAA==

Layout 34:         IgAAAA==

Layout 35:         IwAAAA==

Layout 5:          BQAAAA==

Layout 7:          BwAAAA==

Layout 98:         YgAAAA==

Layout 99:         YwAAAA==

 

Thank you for your prompt reply again!

 

This is where my confusion comes into play.

 

I converted each of these when I tested them with the website you gave me. I noticed after a reboot I went back into check the string and that's where it is getting converted to that "0CAAAAA00" or whatever value. Is there something that could be causing this.

 

Just so I'm not missing a step.

  1. Boot up macOS
  2. Launch OpenCore Configurator
  3. Tools > Mount EFI > Mount disk
  4. Open config.plist from OC folder
  5. Go to "Device Properties"
  6. Add/edit "layout-id" field
  7. Convert layout ID i.e "11 0 0 0" to Base64
  8. Input in "Value" field
  9. Save
  10. Unmount EFI
  11. Reboot

After a reboot, I check sound preferences and don't see any device so I go back and mount the EFI/config and check the value and that's where I see that "0CAAAA00".

 

Sorry I forgot to mention that last night, it was well past midnight and I was ready for bed. 😅

Link to comment
2 hours ago, Donny S Beatz said:

 

Thank you for your prompt reply again!

 

This is where my confusion comes into play.

 

I converted each of these when I tested them with the website you gave me. I noticed after a reboot I went back into check the string and that's where it is getting converted to that "0CAAAAA00" or whatever value. Is there something that could be causing this.

 

Just so I'm not missing a step.

  1. Boot up macOS
  2. Launch OpenCore Configurator
  3. Tools > Mount EFI > Mount disk
  4. Open config.plist from OC folder
  5. Go to "Device Properties"
  6. Add/edit "layout-id" field
  7. Convert layout ID i.e "11 0 0 0" to Base64
  8. Input in "Value" field
  9. Save
  10. Unmount EFI
  11. Reboot

After a reboot, I check sound preferences and don't see any device so I go back and mount the EFI/config and check the value and that's where I see that "0CAAAA00".

 

Sorry I forgot to mention that last night, it was well past midnight and I was ready for bed. 😅

 

Ok, sorry, I need to describe it again if you use opencore configurator (I don't like it at all!!!)

1. OK

2. OK

3. OK

4. OK

5. OK

6. OK

7. No, sorry, here opencore configurator behavior is not standard in my opinion: it is asking for DATA type, but you need to input HEX data, that HEX data are written in base64 to the config.plist (what a mess!!!)

So, look at this example:

Layout n. 17  --> 17 0 0 0 (decimal)

Converted to HEX: 11 00 00 00 --> 11000000

11000000 is the value that you input into opencore configurator (type DATA):

un1.thumb.png.dfc983894da49b5abbedbc8cb0fe7af2.png

 

If you save the config.plist and you open it with a text editor they are saved as base64 automatically:

un2.png.f216ac1fc71df9c6b250e5f7522e1c5b.png

 

So, new values to input into opencore configurator:

 

Layout 1:          01000000

Layout 100:      64000000

Layout 11:         0B000000

Layout 13:         0D000000

Layout 15:        0F000000

Layout 16:        10000000

Layout 17:         11000000

Layout 2:          02000000

Layout 21:        15000000

Layout 27:        1B000000

Layout 28:        1C000000

Layout 29:        1D000000

Layout 3:          03000000

Layout 30:        1E000000

Layout 34:        22000000

 

8. OK, check type is DATA

9. OK

10. OK

11. OK

 

You can check the right value is applied with ioregistry explorer (this is my layout for layout-id=7 decimal):

un3.png.f3d71ca2309272f5571af52b6dd07e58.png

Values are correctly applied if you read it in <HEX>

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

 

Ok, sorry, I need to describe it again if you use opencore configurator (I don't like it at all!!!)

1. OK

2. OK

3. OK

4. OK

5. OK

6. OK

7. No, sorry, here opencore configurator behavior is not standard in my opinion: it is asking for DATA type, but you need to input HEX data, that HEX data are written in base64 to the config.plist (what a mess!!!)

So, look at this example:

Layout n. 17  --> 17 0 0 0 (decimal)

Converted to HEX: 11 00 00 00 --> 11000000

11000000 is the value that you input into opencore configurator (type DATA):

un1.thumb.png.dfc983894da49b5abbedbc8cb0fe7af2.png

 

If you save the config.plist and you open it with a text editor they are saved as base64 automatically:

un2.png.f216ac1fc71df9c6b250e5f7522e1c5b.png

 

So, new values to input into opencore configurator:

 

Layout 1:          01000000

Layout 100:      64000000

Layout 11:         0B000000

Layout 13:         0D000000

Layout 15:        0F000000

Layout 16:        10000000

Layout 17:         11000000

Layout 2:          02000000

Layout 21:        15000000

Layout 27:        1B000000

Layout 28:        1C000000

Layout 29:        1D000000

Layout 3:          03000000

Layout 30:        1E000000

Layout 34:        22000000

 

8. OK, check type is DATA

9. OK

10. OK

11. OK

 

You can check the right value is applied with ioregistry explorer (this is my layout for layout-id=7 decimal):

un3.png.f3d71ca2309272f5571af52b6dd07e58.png

Values are correctly applied if you read it in <HEX>

 

So I went through each layout you converted for me (thank you so much, btw!) but still no dice.

 

I changed out the layout-id in OpenCore Configurator, verified in the config.plist that the conversion is right but in IORegistryExplorer the layout-id is not right.

 

If the layout # works under boot-args it should work for the layout-id value right?

 

 

Screen Shot 2021-11-03 at 9.16.17 PM.png

Link to comment
5 hours ago, Donny S Beatz said:

So I went through each layout you converted for me (thank you so much, btw!) but still no dice.

Now you are doing it correctly.

 

5 hours ago, Donny S Beatz said:

If the layout # works under boot-args it should work for the layout-id value right?

Yes, and ioreg is reporting "a correct value", but not that of the device properties, it seems it still applies the boot-arg value (?), or you didn't reboot the vm (?).

 

Assuming the screenshot comes from a reboot of the vm (you see the changes in ioreg only after you applied the device property in the config.plist and only after a reboot, it doesn't happen "on the fly"), in device properties you have layout id 11, in ioreg you have layout id 7.

 

If this happens (even after applying the device property and after a reboot of the vm), check in a terminal of the vm:

nvram 7C436110-AB2A-4BBB-A880-FE41995C9F82:boot-args

1. Check that the layout-id variable is not there

2. Check in config.plist that you have an entry for 7C436110-AB2A-4BBB-A880-FE41995C9F82 in the Delete tab for boot-args

3. Check that WriteFlash is enabled

oc.thumb.png.7f91c75ad4c227f216d61bb19c72194d.png

 

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.