Jump to content
1335 posts in this topic

Recommended Posts

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

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.

@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
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

@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
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

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.

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.

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

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
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
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

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

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 

4 hours ago, Mustername said:
On 4/20/2020 at 1:07 PM, n.d.k said:

 

Your taste doesn't represent others.

It's the same for you....!!!

 

That's true, but lucky for me I am the one who get to decide. And I already did leave an option for everyone to choose whatever they like.  So no biggy here. Move on!

Edited by n.d.k
  • Like 2
×
×
  • Create New...