Jump to content

Customized OpenCore with additional features

n.d.k

By n.d.k,
in OpenCore

 Share
1,348 posts in this topic

Recommended Posts

n.d.k
n.d.k
Posted
  • Author
Posted (edited)
5 hours ago, Matgen84 said:

 

You know a solution.

 

Yay, recent new commits from EDKII broke the build,  I just modified the ndk-macbuild.tool to build against the previous working EDKII commit.

You can do a git pull to update the ndk-macbuild.tool and compile again.

 

PS.  ndk-macbuild.tool is just updated again to work with the most recent EDKII commit.

Edited by n.d.k
  • Like 1
  • Thanks 1
Link to comment
Share on other sites
Blu24
Blu24
Posted
Posted (edited)
4 hours ago, MacNB said:

@Blu24, When you use the boot picker, there's is NO autoboot (certainly not on the official OC).

Think about it, "It's a feature". When using External boot picker AND you set Show Picker =True, THEN the timeout value has NO FUNCTION. The boot picker will sit there waiting for you to select the drive you wish to boot. That behaves just like a real Mac. IMHO this is correct behaviour.

 

My system always auto boots my desired default OS. What I do is set the Show Picker = FALSE because I do NOT want to see the boot picker EVERYTIME I boot (I see no point in that). 

I only want to see the boot picker when on a rare occasion when I want to boot a DIFFERENT OS in that case, I hold the OPT/Alt key on the keyboard (Apple magic keyboard) while booting and OC displays the boot picker (or, use the ESC key).

You CAN autoboot the DEFAULT OS (read the configuration manual to find out how to do that; HINT: Startup disk preferences).

I now understand. I've set show picker to False. works flawlessly. On very rare occasions when I need Windows, I just hold the OPT/ALT key. Perfect!!

I also don't need to see boot picker everytime. Thanks for clearing things up :)

Edited by Blu24
Link to comment
Share on other sites
startergo
startergo
Posted
Posted
23 hours ago, MacNB said:

When you use the boot picker, there's is NO autoboot (certainly not on the official OC).

With the NDKbootpicker driver it times out and auto reboots. With the official OC and Opencanopy it does not. Also with the latest official OC and Opencanopy the keyboard stopped responding, only the mouse.

Link to comment
Share on other sites
MacNB
MacNB
Posted
Posted (edited)
5 hours ago, startergo said:

With the NDKbootpicker driver it times out and auto reboots. With the official OC and Opencanopy it does not. Also with the latest official OC and Opencanopy the keyboard stopped responding, only the mouse.

 

I'm on the released 0.5.7 official build and have no problems with the keyboard.

Whenever you build your own from the sources, you have to bear in mind that the sources

are changing by the hour and you have a snapshot so some things may be broken for some people.

E.g. an update tot he sources 2 hours ago:

1231942112_Screenshot2020-04-17at13_49_48.thumb.png.2b825908a8f53c5d41513e796edcca82.png

 

UPDATE:

I just built the official OC from GitHub sources (0.5.8) and have no problem entering OpenCanopy via OPT/Alt (or ESC) key.

Edited by MacNB
update
Link to comment
Share on other sites
edenpulse
edenpulse
Posted
Posted

Okay, so compiled and tried the fork. 

I added the EnableForAll quirks to boot Windows, and even tried to add a custom entry to the bootloader.
Neither works. 
Enableforall set to true of false doesn't do change the fact that it won't boot. 
In one case I get the BSOD ACPI_BIOS_ERROR, in the other case, Windows doesn't seem to find bootmgfw (i don't remember the exact error) and tells me to repair it.
Link to comment
Share on other sites
n.d.k
n.d.k
Posted
  • Author
Posted
28 minutes ago, edenpulse said:

Okay, so compiled and tried the fork. 

I added the EnableForAll quirks to boot Windows, and even tried to add a custom entry to the bootloader.
Neither works. 
Enableforall set to true of false doesn't do change the fact that it won't boot. 
In one case I get the BSOD ACPI_BIOS_ERROR, in the other case, Windows doesn't seem to find bootmgfw (i don't remember the exact error) and tells me to repair it.

 

On some firmware, you may need the Booter->Quirks->EnableForAll enabled.

 

 

Link to comment
Share on other sites
n.d.k
n.d.k
Posted
  • Author
Posted
17 minutes ago, edenpulse said:

 

Yup, did both (should I have done just the one in ACPI Quirks?)

 

If you have never successfully booted Windows from OC/Clover before, then you may need to repair the boot record from Windows side https://www.easeus.com/partition-manager-software/fix-uefi-boot-in-windows-10-8-7.html or visit the hackintosh multi-boot forums for more information.

  • Like 3
Link to comment
Share on other sites
edenpulse
edenpulse
Posted
Posted

I have booted successfully Windows with Opencore and Clover ;) 

with only ssdt patches I manage to boot it with opencore and clover. 

Maldon provided me a fully patched dsdt, that’s when it doesn’t work anymore. 
incan also boot it just using the select menu from bios.

I have booted successfully Windows with Opencore and Clover ;) 

with only ssdt patches I manage to boot it with opencore and clover. 

Maldon provided me a fully patched dsdt, that’s when it doesn’t work anymore. 
incan also boot it just using the select menu from bios.

Link to comment
Share on other sites
alkemix
alkemix
Posted
Posted (edited)

@n.d.k    I'm trying Your 0.5.8 release but Windows10 will not boot, error code 0xc000000d, and blue screen. Mojave starts and works fine ! How can I fix that ?

 

By opencore nightly 0.5.8 Windows boot without issues, but I like your version !

Edited by alkemix
Link to comment
Share on other sites
alkemix
alkemix
Posted
Posted (edited)
44 minutes ago, meaganmargaret said:

@alkemix  I also boot Windows from an special entry (found under the Misc section of OC), not from the default menu of NDK's version of OC. 

 

....

 

 

Yes, I also Boot Windows from a special entry under Misc section of OC for rename Windows label ;-) 

 

Thanks a lot ! You're great ! My salvation ! Finally Windows10 starts!

Edited by alkemix
Link to comment
Share on other sites
Awesome Donkey
Awesome Donkey
Posted
Posted (edited)

@n.d.k I've noticed for the last day or two of commits the list of custom entries randomly will get out of order or entries won't appear (aka are 'lost').

 

Here's how it should look (with the list in this order, Windows 10, macOS Catalina and Arch Linux)...

 

ScreenShot-2020-04-17-112749.thumb.png.cae33f6a739c9bbdd62d22db169044f3.png

 

But at random, the order is getting mixed up to this...

 

ScreenShot-2020-04-18-022616.thumb.png.e1429e218d1971b3e578a4eb2569b206.png

 

Looks like the Windows 10 entry is randomly getting 'lost' with the generic entry being shown. I did double check the path for the Windows 10 entry but it's correct and the correct Windows 10 entry will reappear after a reboot. I've also noticed a couple times the Arch Linux entry will randomly be 'lost' as well - I also checked the path for this and it's correct (and it will appear back after a reboot). It's not the drives failing (odd that two different SSDs would fail at the same time, and both appear fine in the UEFI BIOS boot list) or anything like that. For the time being, I've reverted to a backup from three days ago (I first noticed this this morning, so within the last day or so). Who knows, maybe it's related to the EDKII stuff from the last few days?

 

Any ideas?

 

 

Edited by Awesome Donkey
Link to comment
Share on other sites
CHmodzs
CHmodzs
Posted
Posted
4 hours ago, meaganmargaret said:

@alkemix  and @edenpulse    Here are my settings for the Booter Quirks, and these are the settings I had to have for Windows to boot.  You should also know that I am running NDK's version of OC (0.5.8) and it's about a week old.  I also boot Windows from an special entry (found under the Misc section of OC), not from the default menu of NDK's version of OC. 

 

 

            <key>AvoidRuntimeDefrag</key>
            <true/>
            <key>DevirtualiseMmio</key>
            <true/>
            <key>DisableSingleUser</key>
            <false/>
            <key>DisableVariableWrite</key>
            <false/>
            <key>DiscardHibernateMap</key>
            <false/>
            <key>EnableForAll</key>
            <true/>
            <key>EnableSafeModeSlide</key>
            <true/>
            <key>EnableWriteUnprotector</key>
            <true/>
            <key>ForceExitBootServices</key>
            <false/>
            <key>ProtectMemoryRegions</key>
            <false/>
            <key>ProtectSecureBoot</key>
            <false/>
            <key>ProtectUefiServices</key>
            <false/>
            <key>ProvideCustomSlide</key>
            <true/>
            <key>RebuildAppleMemoryMap</key>
            <true/>
            <key>SetupVirtualMap</key>
            <false/>
            <key>SignalAppleOS</key>
            <false/>
            <key>SyncRuntimePermissions</key>
            <true/>

 

Hi  @meaganmargaret, I followed up above Booter quirks config and able to boot into the windows 10 that on same drive, but unfortunately this broke my macOS boot failed with kernel panic. 

 

If I revert the Booter quirks with modify DevritualiseMmio, RebuildAppleMemoryMap, SyncRuntimePermissions from True to False, and set SetupVirtualMap into True, can boot into macOs fine. 

 

attached is my config.plist with windows 10 unable to boot (error with 0x000000d need to repair the bootcd)

 

any advise ?

config.plist

Link to comment
Share on other sites
n.d.k
n.d.k
Posted
  • Author
Posted
11 hours ago, Awesome Donkey said:

@n.d.k I've noticed for the last day or two of commits the list of custom entries randomly will get out of order or entries won't appear (aka are 'lost').

 

Here's how it should look (with the list in this order, Windows 10, macOS Catalina and Arch Linux)...

 

ScreenShot-2020-04-17-112749.thumb.png.cae33f6a739c9bbdd62d22db169044f3.png

 

But at random, the order is getting mixed up to this...

 

ScreenShot-2020-04-18-022616.thumb.png.e1429e218d1971b3e578a4eb2569b206.png

 

Looks like the Windows 10 entry is randomly getting 'lost' with the generic entry being shown. I did double check the path for the Windows 10 entry but it's correct and the correct Windows 10 entry will reappear after a reboot. I've also noticed a couple times the Arch Linux entry will randomly be 'lost' as well - I also checked the path for this and it's correct (and it will appear back after a reboot). It's not the drives failing (odd that two different SSDs would fail at the same time, and both appear fine in the UEFI BIOS boot list) or anything like that. For the time being, I've reverted to a backup from three days ago (I first noticed this this morning, so within the last day or so). Who knows, maybe it's related to the EDKII stuff from the last few days?

 

Any ideas?

 

 

 

I recently added custom entry and tool check, which meant before the custom/tool entry is added, it will check for the file existence based on the provided path. This ensure that all displayed boot entries are valid.

 

The problem you described seems like your drives are inconsistence available during the file check.

Link to comment
Share on other sites
Awesome Donkey
Awesome Donkey
Posted
Posted

Can there be a way to disable the file check (like an advanced option)? I'm willing to accept the potential consequences of having that file check disabled (even though I've never had issues with custom entries not booting).

 

The only reason I can think of why there might be an inconsistency is perhaps from a delay initializing all the drives in my PC while it POSTs, since I have 6 of them installed. However the drives *are* always there and do boot correctly regardless. Or it might be some UEFI BIOS quirk, not sure.

Link to comment
Share on other sites
n.d.k
n.d.k
Posted
  • Author
Posted (edited)
2 hours ago, Awesome Donkey said:

Can there be a way to disable the file check (like an advanced option)? I'm willing to accept the potential consequences of having that file check disabled (even though I've never had issues with custom entries not booting).

 

The only reason I can think of why there might be an inconsistency is perhaps from a delay initializing all the drives in my PC while it POSTs, since I have 6 of them installed. However the drives *are* always there and do boot correctly regardless. Or it might be some UEFI BIOS quirk, not sure.

 

Sure, will add an option somewhere..

 

PS.  Fork Only:  Added an optional field Misc->Boot->SkipCustomEntryCheck.  (Others without the problem, no need to add it)

337762990_ScreenShot2020-04-18at10_55_02AM.thumb.png.7cd04914a8d9a03eba998fbcbd5d463c.png

 

Edited by n.d.k
  • Like 1
Link to comment
Share on other sites
Awesome Donkey
Awesome Donkey
Posted
Posted (edited)

Nice, thank you very much! I'm now using that option. :)

 

BTW, I also noticed while testing with my 'issue' above that tools, e.g. OpenShell.efi, failed to appear as well. Looking at the OC debug logs it mentioned this...

  

OC: Invalid tool path

Which may or may not have anything to do with it. I'm going to guess this is happening because tools that are used (like in the sample .plist files) don't use the full paths, instead appearing like this by default...

  

		<key>Tools</key>
		<array>
			<dict>
				<key>Arguments</key>
				<string></string>
				<key>Auxiliary</key>
				<true/>
				<key>Comment</key>
				<string></string>
				<key>Enabled</key>
				<true/>
				<key>Name</key>
				<string>UEFI Shell</string>
				<key>Path</key>
				<string>OpenShell.efi</string>
			</dict>
		</array>

 

Once I started using SkipCustomEntryCheck, my UEFI Shell tool entry reappeared and works again. Might be worth checking to make sure tools aren't being broken by the file check for lacking the full path.

 

 

Edited by Awesome Donkey
Link to comment
Share on other sites
n.d.k
n.d.k
Posted
  • Author
Posted (edited)
30 minutes ago, Awesome Donkey said:

Nice, thank you very much! I'm now using that option. :)

 

BTW, I also noticed while testing with my 'issue' above that tools, e.g. OpenShell.efi, failed to appear as well. Looking at the OC debug logs it mentioned this...

  


OC: Invalid tool path

Which may or may not have anything to do with it. I'm going to guess this is happening because tools that are used (like in the sample .plist files) don't use the full paths, instead appearing like this by default...

  


		<key>Tools</key>
		<array>
			<dict>
				<key>Arguments</key>
				<string></string>
				<key>Auxiliary</key>
				<true/>
				<key>Comment</key>
				<string></string>
				<key>Enabled</key>
				<true/>
				<key>Name</key>
				<string>UEFI Shell</string>
				<key>Path</key>
				<string>OpenShell.efi</string>
			</dict>
		</array>

 

Once I started using SkipCustomEntryCheck, my UEFI Shell tool entry reappeared and works again. Might be worth checking to make sure tools aren't being broken by the file check for lacking the full path.

 

 

 

Hmm, the SkipCustomEntryCheck only apply to Custom entries, not Tools. All tools are located in booted drive and doesn't use full path, which are already taken into account when checking tool entries.  It seems your system drive's response are inconsistence.

Edited by n.d.k
  • Like 1
Link to comment
Share on other sites
btwise
btwise
Posted
Posted
54 minutes ago, Barry_dhb52 said:

Just personal interest, I prefer the official Opencore GUI boot resource, is there any way/ any plan to migrate the official theme into OC-forked?

 

only replace icon resources files to ndk forks!

3 minutes ago, btwise said:

only replace icon resources files to ndk forks!

 

content-21699827.png

  • Like 1
Link to comment
Share on other sites
nijhawank
nijhawank
Posted
Posted

I converted my Clover based Catalina installation to OpenCore and everything is perfect.
 

However I now tried to upgrade my 10.15.2 installation to 10.15.4 (I’m using the full Installer), the Installer says that my Mac needs a firmware update to install to APFS volume and it asks me to pick a HFS+ partition instead. See the attached screenshot.

I can however workaround the problem by choosing Macbookpro14,1 instead of Macbookpro13,1 that I normally use. It seems OpenCore is spoofing / reporting  an older Boot ROM when using Macbookpro13,1. 
My hack is a Lenovo T460 laptop with i5-6300u and is better matched with Macbookpro13,1 but even otherwise the problem of spoofing an older Boot ROM seems to be a bug with OpenCore. I’m using OpenCore 0.5.7. What you all think?

FE10C52A-3F29-46E0-8849-B2032802563C.jpeg

Link to comment
Share on other sites
alboz83
alboz83
Posted
Posted

Hi, i'm using OC NDK 058 Nightly, works fine but at boot i see for half second this:
 

OC: Settings NVRAM 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:rtc-blacklist - Not Found. 

 

Is a new voice on config, and there is no value. What should I do?

If i delete this (also in Block Key) i get OCB: Failed to match a default boot option 

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...