Jump to content
ErmaC

Clover General discussion

19,676 posts in this topic

Recommended Posts

1 minute ago, vector sigma said:

Found the problem, and is not a problem with Clover. Go there: https://github.com/acidanthera/AppleSupportPkg/releases

and download latest release.... it contains VBoxHfs.efi:hysterical::hysterical:

Nooo waaay, Huawei. :))

 

Yeah, that explains it... And because I'm downloading the drivers with "--ext-pre" ...there it is another one. So...there's one from Clover and one from AppleSupportPkg? Uhm...oook... Is that intended? :)) It still doesn't feel quite ok to me.

 

Share this post


Link to post
Share on other sites
Advertisement
Just now, arsradu said:

It still doesn't feel quite ok to me.

Lol. We can filter a driver... but what if achid-devs add another one?? Lol

Share this post


Link to post
Share on other sites

The question is: is their driver, different, better or whatever? Since one use precompiled drivers ("--ext-pre"), should we replace the stock one.... or just don't copy the copy?

1799224163_Schermata2019-05-07alle21_51_58.png.ab346a8c4770d85d6219f6526c8e355a.png

:hysterical:

Share this post


Link to post
Share on other sites
Posted (edited)
14 minutes ago, vector sigma said:

Lol. We can filter a driver... but what if achid-devs add another one?? Lol


Good point.

 

8 minutes ago, vector sigma said:

The question is: is their driver, different, better or whatever? Since one use precompiled drivers ("--ext-pre"), should we replace the stock one.... or just don't copy the copy?

 

Very good question indeed.

 

I think this needs to be discussed with him... I'm pretty sure he wasn't aware that this would cause conflicts with existing drivers.

 

So, in my opinion, this needs to be discussed so we can establish which one to keep. Based on which one is better, has better support etc. If theirs is better, I guess we can check for that first and simply skip the stock one. I'm not sure what was the purpose of including that driver in the first place (i mean the one from AppleSupportPkg)... That's why I think more than anything this needs to be discussed. Cause there might be a very good reason for that.

 

And here we come again to the same issue of using different sources from different places into the same build...

Edited by arsradu

Share this post


Link to post
Share on other sites
2 minutes ago, arsradu said:

 

So, in my opinion, this needs to be discussed so we can establish which one to keep. Based on which one is better, has better support etc. 

probably it has to do with some nvram reading, otherwise I can't see profit.

Share this post


Link to post
Share on other sites
9 hours ago, arsradu said:

 

Well, the same one I've always used (attached)... And I'm using UDK2018. Not sure what changed and where. Which one are you using? :)) Also, is this with a clean environment?

CloverNew

Hi @arsradu

where do you insert USE_APPLE_HFSPLUS_DRIVER in your script?

Share this post


Link to post
Share on other sites
7 hours ago, vector sigma said:

Lol. We can filter a driver... but what if achid-devs add another one?? Lol

I think it is better not to use achid drivers. We should not depend on alien project. We have to use only own files and let users use any other drivers downloaded anywhere they want.

Share this post


Link to post
Share on other sites
Posted (edited)
12 hours ago, ellaosx said:

Hi @arsradu

where do you insert USE_APPLE_HFSPLUS_DRIVER in your script?

 

Hi Ella!

 

I'm not using that option. As I said in one of my previous posts, that was a misunderstanding on my side. :)

 

However, in ebuild.sh, under Options, I can see this:

2033716515_Screenshot2019-05-08at12_30_57.png.943f9d7ed3d83e471bfadc2e8a8d99ee.png

 

Which seems to be set up above by this:

1435420401_Screenshot2019-05-08at12_32_52.png.1b8ff94f88884c5c2587d18f90f63aeb.png

 

So, my guess is that you need HFSPlus in /Filesystems/HFSPlus/X64/HFSPlus.efi and when you invoke ./ebuild.sh, you need to add "-D MACRO, --define=MACRO" as parameters. At least that's what I get from the description...

 

Personally, I couldn't get it to work. But most likely, I'm doing it wrong. :))

 

Update:

 

Correct usage is probably:

./ebuild.sh -D USE_APPLE_HFSPLUS_DRIVER

That seems to be working fine.

 

Also, regarding the previous issue with VBoxHfs-64.efi duplicated by AppleSupportPkg. If I use "--ext-co" (so compiling rather than downloading), this issue does not occur anymore.

Edited by arsradu

Share this post


Link to post
Share on other sites
Posted (edited)
16 hours ago, Slice said:

I think it is better not to use achid drivers. We should not depend on alien project. We have to use only own files and let users use any other drivers downloaded anywhere they want.

I like the apfs wrapper + AptioMemoryFix and AptioInputFix. Should be better to take those? At the end giving a specific argument to ebuild.sh to download external drivers is just a will for who write that in the Terminal. Please let me know. 

Edited by vector sigma
typo

Share this post


Link to post
Share on other sites

Yup - i had to go with "--ext-co" vs (pre) to get a proper build with the expected UEFI drivers.

 

question: i dont recall having this problem before Mojave, but unless I move my /ESP/EFI/Microsoft folder out of the way for an OS update, Clover wants to boot up microsoft in the middle of the update. 

 

meaning i download the update package.

it creates the boot files in / (root) and then reboots and Clover picks Boot from MacOS Install or something like that.

all seems right... I see the usual progress bar and sometimes i get a white flash, but then it reboots. But now instead of restarting with the macOS Install, Clover wants to boot up the Microsoft. so i have to manually pick the Install icon. However, if I rename the Microsoft folder to M, then macOS update works without issue. 

 

Is there a better location/name for the EFI/Microsoft folder so it doesnt confuse Clover during a macOS update?

Share this post


Link to post
Share on other sites
Posted (edited)
2 hours ago, tluck said:

Yup - i had to go with "--ext-co" vs (pre) to get a proper build with the expected UEFI drivers.

 

question: i dont recall having this problem before Mojave, but unless I move my /ESP/EFI/Microsoft folder out of the way for an OS update, Clover wants to boot up microsoft in the middle of the update. 

 

meaning i download the update package.

it creates the boot files in / (root) and then reboots and Clover picks Boot from MacOS Install or something like that.

all seems right... I see the usual progress bar and sometimes i get a white flash, but then it reboots. But now instead of restarting with the macOS Install, Clover wants to boot up the Microsoft. so i have to manually pick the Install icon. However, if I rename the Microsoft folder to M, then macOS update works without issue. 

 

Is there a better location/name for the EFI/Microsoft folder so it doesnt confuse Clover during a macOS update?

 

I remember having the same issue before...

 

Are you using both Windows and MacOS from the same drive? Or separate drives?

 

If so, which one is set in Bios as primary boot drive? In case they're separate, make sure Bios is set to boot from the MacOS drive. If they're not, well, I'm not sure... I know Windows wants to always be on top. First boot, etc. And it doesn't play well with other operating systems on the same drive. Not even with more than one drive (even if the other ones have no OS or Windows on them). It won't get installed. This is an ancient issue, and for as far as I know, to this day it's still present. In order to get Windows installed on a machine that has multiple drives, you have to unplug all the other drives and only leave the one you want Windows installed on.

 

I'm not sure this issue is with Clover as much as it's with Microsoft itself. But I could be wrong here.

Edited by arsradu

Share this post


Link to post
Share on other sites

Yes, windows will decide that it needs to set itself as the default for some unknown reason and it appears to be completely random. Also, windows update will cause \EFI\BOOT\BOOTX64.efi to be overwritten often.

Share this post


Link to post
Share on other sites

windows does not overwrite or use \efi\boot\bootx64.efi.  It overwrites \efi\microsoft\boot\bootmgfw.efi.  It is a firmware issue - as usually the firmware will scan the ESP for boot files, and always put \efi\microsoft\boot\bootmgfw.efi before \efi\boot\bootx64.efi in the boot order.  Some firware mask \efi\boot\bootx64.efi if they find \efi\microsoft\boot\bootmgfw.efi on the ESP (the former won't show up on the boot list because the firmware stops scanning).  If the firmware has put both files on the boot list, the order can be edited from the bios setup.  Also, boot entries can be edited/deleted/created/reordered from EFI shell "bcfg boot" command line utility.  Additionally, Windows' bcdedit when run with "bcdedit /enum all" shows the EFI boot order list and all non-windows boot entries - so it may be capable of actually editing and reordering the list, but I've never tried this.

Share this post


Link to post
Share on other sites
Posted (edited)

That's weird because I have installed clover as \EFI\BOOT\BOOTX64.efi and then created a boot entry to \EFI\CLOVER\CLOVERX64.efi. Guess what? Windows updated and now my \EFI\BOOT\BOOTX64.efi is a copy of \EFI\Microsoft\Boot\bootmgfw.efi. It absolutely does this, clear your nvram after a windows update and windows will boot, say something happened to your startup, do a bunch of random nonsense, make you restart and will have set itself as the default pointing to \EFI\Microsoft\Boot\bootmgfw.efi. If masking was the issue then you would have to use the alternate method of launching clover in the first place, unless you already know before hand and install to the disk, boot from a USB, use the EFI shell to set the boot entry. I'm pretty sure you wouldn't be asking a question about why it was happening if you were aware of this. And are you really telling me how to use bcfg or bcdedit? Windows BCD only contains entries pertaining to windows boot manager and does nothing with EFI entries. It is not capable of editing EFI boot entries, however, it can chain load, though it doesn't always work. I just updated my windows like a week ago and my clover like a week before that, here is proof that it does overwrite \EFI\BOOT\BOOTX64.efi:

bootx64.PNG

 

EDIT: No idea what's up with the times, those don't even make sense. I haven't even had this ssd that long.... WTF?

 

EDIT2: Those are creation times, I guess, because actually that may be the day I got this ssd... Weird.

Edited by apianti

Share this post


Link to post
Share on other sites

I've never had windows overrun \efi\boot\bootx64.efi, and I've updated it lots of times.  However, I definitely had the 2nd thing you mention happen - which is for the nvram to be cleared, after which the firmware rescans for boot files, and puts \efi\microsoft\boot\bootmgfw.efi on the list, and the other file is not on the list (because it stopped scanning after it found the first).

 

I've never created an entry for \efi\clover\cloverx64.efi and don't keep it around.  It is loaded by legacy CloverEFI, which I don't use so I don't need it.

 

the "bcdedit/enum all" command displays the efi boot list and non-windows entries on it, taken from nvram, not from BCD.  The Windows-specific stuff is taken from BCD.  I don't know why you're sure bcdedit can't modify nvram just as is able to read nvram.  As you well know, nvram is accessible to the OS via the RT services which is why macos can read and modify nvram.  So Windows can also do it.  Whether bcdedit has the feature to modify nvram I'm not certain.

Share this post


Link to post
Share on other sites
Posted (edited)

Yeah, where on earth would I gather information pertaining to bcdedit... Maybe the microsoft resources?

 

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcdedit-command-line-options

 

I think you are confusing bcdedit with bcdboot, which is also not capable of adding any EFI boot entries except for windows boot manager, which is exactly what happens during an update. And I don't mean like a random security fix, I mean the actual build updates.

 

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcdboot-command-line-options-techref-di

 

EDIT: Also, what you're describing is a non-compliant implementation of (U)EFI, which is not what I was saying, I was saying that if windows detects that it has been booted from any place other than \EFI\Microsoft\Boot\bootmgfw.efi, it performs startup repair.

 

EDIT2: And you should be using \EFI\CLOVER\CLOVERX64.efi, the \EFI\BOOT\BOOTX64.efi is provided for the exact reason that windows overwrites it, so that it is the default on the disk when there is no entry for the actual clover location.

Edited by apianti

Share this post


Link to post
Share on other sites
Posted (edited)

hmm. I see confirmation of the issue but not sure I see real advice ;)

 

yes I dual boot macOS and Window10 on same disk. 

for me:

 

MacOS/Clover updates/uses:

/EFI/Clover/CloverX64.efi

/EFI/BOOT/BootX64.efi (copy/dup of above)

 

windows updates/uses

/EFI/Microsoft/boot/bootmgfw.efi

 

they seem to co-exist nicely

 

my BIOS on either my Dell and Lenovo T420 bootlist have Clover as 1st option and Window Manager as 2nd option.

 

I see that clover always gets picked during the boot up ( same for the update process)

sometimes the install process boots up just fine and then Reboots.

 

it is on this 2nd round of booting up the installer things get odd

instead of selecting the macOS install entry (like the previous boot up) to continue the updating (presumable this is set in NVRAM to override the default macOS volume) - it uses the Windows boot option -- unless I intervene. 

 

all is fine if mv /EFI/Microsoft to /EFI/M before the update and then revert after. just a pain in the neck.

 

Edited by tluck

Share this post


Link to post
Share on other sites
Posted (edited)

This is a different issue altogether. I'm assuming you have it set to timeout and automatically boot macOS? Please look at your preboot.log when this happens and see if the selected entry to boot is found because I imagine that it is deciding that the windows entry is somehow what is supposed to be used, probably because it didn't find anything and your windows entry is the first?

 

EDIT: Wait your edit makes me believe that the installer is actually returning a failure code and your firmware is moving on to the next boot entry, it just appears to be a restart.

Edited by apianti

Share this post


Link to post
Share on other sites
Posted (edited)
56 minutes ago, apianti said:

EDIT2: And you should be using \EFI\CLOVER\CLOVERX64.efi, the \EFI\BOOT\BOOTX64.efi is provided for the exact reason that windows overwrites it, so that it is the default on the disk when there is no entry for the actual clover location.

That only happens to you because you're doing something non-standard...  As you may understand, since I don't keep cloverx64.efi around, I'd notice if Windows clobbered my only copy of CloverGUI, which is in \efi\boot\bootx64.efi - and it's never happened.

 

Quote

EDIT: Also, what you're describing is a non-compliant implementation of (U)EFI, which is not what I was saying, I was saying that if windows detects that it has been booted from any place other than \EFI\Microsoft\Boot\bootmgfw.efi, it performs startup repair.

Well, who told you to do that?  I've never booted windows from any place other than \efi\microsoft\boot\bootmgfw.efi, and can't imagine why I would.

Does the Windows entry {bootmgr} in your BCD have path to something other than \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI?  Maybe that's why your \efi\boot\bootx64.efi is getting clobbered.

 

I'm not confusing bcdedit with anything.  This is the output of my "bcdedit /enum all"

Spoiler

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {b8977f44-5ec4-11e9-8663-806e6f6e6963}
                        {bootmgr}
                        {8d98a361-5ed5-11e9-866d-806e6f6e6963}
                        {bee23572-5f6e-11e9-867d-806e6f6e6963}
                        {bee23573-5f6e-11e9-867d-806e6f6e6963}
                        {bee23574-5f6e-11e9-867d-806e6f6e6963}
timeout                 1

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {b1b9296a-4eea-11e8-95da-b81b03b24d21}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 0

Firmware Application (101fffff)
-------------------------------
identifier              {8d98a361-5ed5-11e9-866d-806e6f6e6963}
device                  partition=Y:
description             UEFI: Verbatim 8.07, Partition 1

Firmware Application (101fffff)
-------------------------------
identifier              {b8977f44-5ec4-11e9-8663-806e6f6e6963}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\BOOT\BOOTX64.EFI
description             UEFI OS

Firmware Application (101fffff)
-------------------------------
identifier              {bee23572-5f6e-11e9-867d-806e6f6e6963}
description             Hard Drive

Firmware Application (101fffff)
-------------------------------
identifier              {bee23573-5f6e-11e9-867d-806e6f6e6963}
description             CD/DVD Drive

Firmware Application (101fffff)
-------------------------------
identifier              {bee23574-5f6e-11e9-867d-806e6f6e6963}
description             USB

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \WINDOWS\system32\winload.efi
description             Windows 10
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {eaef4b12-2fa8-11e9-a62b-b0ca1dec8101}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \WINDOWS
resumeobject            {b1b9296a-4eea-11e8-95da-b81b03b24d21}
nx                      OptOut
bootmenupolicy          Legacy

Windows Boot Loader
-------------------
identifier              {eaef4b12-2fa8-11e9-a62b-b0ca1dec8101}
device                  ramdisk=[\Device\HarddiskVolume3]\Recovery\WindowsRE\Winre.wim,{eaef4b13-2fa8-11e9-a62b-b0ca1dec8101}
path                    \windows\system32\winload.efi
description             Windows Recovery Environment
locale                  en-US
inherit                 {bootloadersettings}
displaymessage          Recovery
osdevice                ramdisk=[\Device\HarddiskVolume3]\Recovery\WindowsRE\Winre.wim,{eaef4b13-2fa8-11e9-a62b-b0ca1dec8101}
systemroot              \windows
nx                      OptOut
bootmenupolicy          Legacy
winpe                   Yes

Resume from Hibernate
---------------------
identifier              {b1b9296a-4eea-11e8-95da-b81b03b24d21}
device                  partition=C:
path                    \WINDOWS\system32\winresume.efi
description             Windows Resume Application
locale                  en-US
inherit                 {resumeloadersettings}
recoverysequence        {eaef4b12-2fa8-11e9-a62b-b0ca1dec8101}
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
filedevice              partition=C:
filepath                \hiberfil.sys
bootmenupolicy          Legacy
debugoptionenabled      No

Windows Memory Tester
---------------------
identifier              {memdiag}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\Microsoft\Boot\memtest.efi
description             Windows Memory Diagnostic
locale                  en-US
inherit                 {globalsettings}
badmemoryaccess         Yes

EMS Settings
------------
identifier              {emssettings}
bootems                 No

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

RAM Defects
-----------
identifier              {badmemory}

Global Settings
---------------
identifier              {globalsettings}
inherit                 {dbgsettings}
                        {emssettings}
                        {badmemory}

Boot Loader Settings
--------------------
identifier              {bootloadersettings}
inherit                 {globalsettings}
                        {hypervisorsettings}

Hypervisor Settings
-------------------
identifier              {hypervisorsettings}
hypervisordebugtype     Serial
hypervisordebugport     1
hypervisorbaudrate      115200

Resume Loader Settings
----------------------
identifier              {resumeloadersettings}
inherit                 {globalsettings}

Device options
--------------
identifier              {eaef4b13-2fa8-11e9-a62b-b0ca1dec8101}
description             Windows Recovery
ramdisksdidevice        partition=\Device\HarddiskVolume3
ramdisksdipath          \Recovery\WindowsRE\boot.sdi

 

The entries "{fwbootmgr}", and all "Firmware Application" are exact copies of the EFI boot order list.  If I change the EFI boot order list external to Windows (via bios setup or bcfg), bcdedit then shows me the new content.  Are they taken by bcdedit directly from nvram, or copied into \efi\microsoft\boot\bcd during windows boot?  I don't know.  If I look in the BCD hive in regedit under HKEY_LOCAL_MACHINE, I see the guids for the "Firmware" entries, but don't know where what regedit is showing comes from.  It could be a copy stored in the BCD file.  It could be read on-the-fly from nvram.  It's not a functional impossibility for Windows to read and modify nvram.

Edited by Zenith432

Share this post


Link to post
Share on other sites
Posted (edited)

No, I'm not doing anything non standard, I know how it works. The reason it is not overwriting \EFI\BOOT\BOOTX64.efi is because of the firmware application entries present in the BCD, bcdedit only reads from the BCD for entries. So those entries were either created by you, some other application, or you already had them set when you initially installed windows and bcdboot when initializing a new BCD adds them. I am on the lastest version of windows 10 through the developer preview channel. And this is the output of my bcdedit:

 

Spoiler

C:\WINDOWS\system32>bcdedit /enum all

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
timeout                 1

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {41f2a634-4ded-11e8-8371-f56bc31a9418}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 0

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \WINDOWS\system32\winload.efi
description             Windows 10
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {41f2a636-4ded-11e8-8371-f56bc31a9418}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \WINDOWS
resumeobject            {41f2a634-4ded-11e8-8371-f56bc31a9418}
nx                      OptIn
bootmenupolicy          Standard

Windows Boot Loader
-------------------
identifier              {41f2a636-4ded-11e8-8371-f56bc31a9418}
device                  ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{41f2a637-4ded-11e8-8371-f56bc31a9418}
path                    \windows\system32\winload.efi
description             Windows Recovery Environment
locale                  en-US
inherit                 {bootloadersettings}
displaymessage          Recovery
osdevice                ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{41f2a637-4ded-11e8-8371-f56bc31a9418}
systemroot              \windows
nx                      OptIn
bootmenupolicy          Standard
winpe                   Yes

Windows Boot Loader
-------------------
identifier              {7d97a531-547d-11e5-a131-f9d2080e85a8}
device                  ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{7d97a532-547d-11e5-a131-f9d2080e85a8}
path                    \windows\system32\winload.efi
description             Windows Recovery Environment
locale                  en-US
inherit                 {bootloadersettings}
displaymessage          Recovery
osdevice                ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{7d97a532-547d-11e5-a131-f9d2080e85a8}
systemroot              \windows
nx                      OptIn
bootmenupolicy          Standard
winpe                   Yes

Resume from Hibernate
---------------------
identifier              {41f2a634-4ded-11e8-8371-f56bc31a9418}
device                  partition=C:
path                    \WINDOWS\system32\winresume.efi
description             Windows Resume Application
locale                  en-US
inherit                 {resumeloadersettings}
recoverysequence        {41f2a636-4ded-11e8-8371-f56bc31a9418}
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
filedevice              partition=C:
filepath                \hiberfil.sys
bootmenupolicy          Standard
debugoptionenabled      No

Windows Memory Tester
---------------------
identifier              {memdiag}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\memtest.efi
description             Windows Memory Diagnostic
locale                  en-US
inherit                 {globalsettings}
badmemoryaccess         Yes

EMS Settings
------------
identifier              {emssettings}
bootems                 No

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

RAM Defects
-----------
identifier              {badmemory}

Global Settings
---------------
identifier              {globalsettings}
inherit                 {dbgsettings}
                        {emssettings}
                        {badmemory}

Boot Loader Settings
--------------------
identifier              {bootloadersettings}
inherit                 {globalsettings}
                        {hypervisorsettings}

Hypervisor Settings
-------------------
identifier              {hypervisorsettings}
hypervisordebugtype     Serial
hypervisordebugport     1
hypervisorbaudrate      115200

Resume Loader Settings
----------------------
identifier              {resumeloadersettings}
inherit                 {globalsettings}

Device options
--------------
identifier              {41f2a637-4ded-11e8-8371-f56bc31a9418}
description             Windows Recovery
ramdisksdidevice        partition=\Device\HarddiskVolume5
ramdisksdipath          \Recovery\WindowsRE\boot.sdi

Device options
--------------
identifier              {7d97a532-547d-11e5-a131-f9d2080e85a8}
description             Windows Recovery
ramdisksdidevice        unknown
ramdisksdipath          \Recovery\WindowsRE\boot.sdi

 

Notice no firmware application entries at all? Even though I have windows, clover, and four linux distros all set to boot from my firmware menu, plus the additional ones that show up when a USB is inserted. You say the entries change, but how do you know that they are changing? Are you adding new entries and those entries are then appearing in that output? Why would it be showing boot entries with no application path? You have two USB disks connected when you booted? Neither of which is bootable yet it shows an entry for?

 

EDIT: And I just told you that it is booting from \EFI\BOOT\BOOTX64.efi because I cleared my nvram, I'm not moving the bootmgfw.efi and trying to use it somewhere else. But that's entirely possible to do by changing the BCD, which is allowed by the bcdboot command.

 

EDIT2: To clarify, it does startup repair if the {bootmgr} path is different from the path it is booted, not specifically \EFI\Microsoft\Boot\bootmgfw.efi, that's just the default location.

Edited by apianti

Share this post


Link to post
Share on other sites
Posted (edited)

This has got nothing to do with bcdboot.  The displayorder under my {fwbootmgr} was created by Windows automatically, and it's copied from the same boot order list I see in bios setup.  The non-Windows "Firmware Application" entries in bcdedit were created automatically.  I didn't add them manually.  They're an exact duplicate of what I see in bios setup, and the list in bios setup is created from an automatic firmware scan.  I just did a simple test - boot into bios setup - change the order of the first two entries - then boot Windows.  Then I run bcdedit and I see the displayorder of {fwbootmgr} has changed to be the same as the change I made in bios setup.  It's always acted this way, even with previous motherboard.  I am also sure that if I add or delete entries to the list in bios setup, it will automatically show up in bcdedit, because this has happened before.

Windows version is 10 1809.

Some of the firmware entries don't have specific path, but are a "partition", or just general device type ("hard drive").  It is the same in bios setup.

It is possible that the reason Windows never clobbers my \efi\boot\bootx64.efi is because there is a firmware entry in bcdedit listing this file.  But the firmware added this entry in bios setup from a scan, and it got copied.  I never put it into bcdedit.

Quote

EDIT2: To clarify, it does startup repair if the {bootmgr} path is different from the path it is booted, not specifically \EFI\Microsoft\Boot\bootmgfw.efi, that's just the default location.

the {bootmgr} path can never be different from the path Windows is booted.

Edit: Well, ok if chain-booted from Clover, or by manually selecing a file in bios setup or running from a shell then I guess it can but that's not what you're describing.  In a boot from the EFI boot list, the path to boot is taken from the {bootmgr} entry.

Edited by Zenith432

Share this post


Link to post
Share on other sites

I have no such issue because my AMI UEFI BIOS is tuned to boot /EFI/CLOVER/CLOVERX64.EFI and nothing more.

Clover may chain to \EFI\Microsoft\Boot\bootmgfw.efi to boot Windows and I can update macOS and Windows safely.

 

On 5/8/2019 at 10:07 PM, vector sigma said:

I like the apfs wrapper + AptioMemoryFix and AptioInputFix. Should be better to take those? At the end giving a specific argument to ebuild.sh to download external drivers is just a will for who write that in the Terminal. Please let me know. 

Download external drivers should not be by default. That's all I want.

I may place any drivers into specific places before I create new package.

apfs.efi can be used from Apple.

AptioMemoryfix can be replaced by Clover's OsxAptioFix3Drv.efi (yes, it is good replacement!)

AptioInputFix can be replaced by Clover's AppleKeyFeeder.efi. Actually they needed only for FileVault2 interface.

If the AppleKeyFeeder is not working for some setups it should be reported and fixed.

Share this post


Link to post
Share on other sites
20 hours ago, apianti said:

No, I'm not doing anything non standard, I know how it works. The reason it is not overwriting \EFI\BOOT\BOOTX64.efi is because of the firmware application entries present in the BCD, bcdedit only reads from the BCD for entries. So those entries were either created by you, some other application, or you already had them set when you initially installed windows and bcdboot when initializing a new BCD adds them. I am on the lastest version of windows 10 through the developer preview channel. And this is the output of my bcdedit:

 

  Reveal hidden contents

C:\WINDOWS\system32>bcdedit /enum all

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
timeout                 1

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {41f2a634-4ded-11e8-8371-f56bc31a9418}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 0

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \WINDOWS\system32\winload.efi
description             Windows 10
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {41f2a636-4ded-11e8-8371-f56bc31a9418}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \WINDOWS
resumeobject            {41f2a634-4ded-11e8-8371-f56bc31a9418}
nx                      OptIn
bootmenupolicy          Standard

Windows Boot Loader
-------------------
identifier              {41f2a636-4ded-11e8-8371-f56bc31a9418}
device                  ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{41f2a637-4ded-11e8-8371-f56bc31a9418}
path                    \windows\system32\winload.efi
description             Windows Recovery Environment
locale                  en-US
inherit                 {bootloadersettings}
displaymessage          Recovery
osdevice                ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{41f2a637-4ded-11e8-8371-f56bc31a9418}
systemroot              \windows
nx                      OptIn
bootmenupolicy          Standard
winpe                   Yes

Windows Boot Loader
-------------------
identifier              {7d97a531-547d-11e5-a131-f9d2080e85a8}
device                  ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{7d97a532-547d-11e5-a131-f9d2080e85a8}
path                    \windows\system32\winload.efi
description             Windows Recovery Environment
locale                  en-US
inherit                 {bootloadersettings}
displaymessage          Recovery
osdevice                ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{7d97a532-547d-11e5-a131-f9d2080e85a8}
systemroot              \windows
nx                      OptIn
bootmenupolicy          Standard
winpe                   Yes

Resume from Hibernate
---------------------
identifier              {41f2a634-4ded-11e8-8371-f56bc31a9418}
device                  partition=C:
path                    \WINDOWS\system32\winresume.efi
description             Windows Resume Application
locale                  en-US
inherit                 {resumeloadersettings}
recoverysequence        {41f2a636-4ded-11e8-8371-f56bc31a9418}
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
filedevice              partition=C:
filepath                \hiberfil.sys
bootmenupolicy          Standard
debugoptionenabled      No

Windows Memory Tester
---------------------
identifier              {memdiag}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\memtest.efi
description             Windows Memory Diagnostic
locale                  en-US
inherit                 {globalsettings}
badmemoryaccess         Yes

EMS Settings
------------
identifier              {emssettings}
bootems                 No

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

RAM Defects
-----------
identifier              {badmemory}

Global Settings
---------------
identifier              {globalsettings}
inherit                 {dbgsettings}
                        {emssettings}
                        {badmemory}

Boot Loader Settings
--------------------
identifier              {bootloadersettings}
inherit                 {globalsettings}
                        {hypervisorsettings}

Hypervisor Settings
-------------------
identifier              {hypervisorsettings}
hypervisordebugtype     Serial
hypervisordebugport     1
hypervisorbaudrate      115200

Resume Loader Settings
----------------------
identifier              {resumeloadersettings}
inherit                 {globalsettings}

Device options
--------------
identifier              {41f2a637-4ded-11e8-8371-f56bc31a9418}
description             Windows Recovery
ramdisksdidevice        partition=\Device\HarddiskVolume5
ramdisksdipath          \Recovery\WindowsRE\boot.sdi

Device options
--------------
identifier              {7d97a532-547d-11e5-a131-f9d2080e85a8}
description             Windows Recovery
ramdisksdidevice        unknown
ramdisksdipath          \Recovery\WindowsRE\boot.sdi

 

Notice no firmware application entries at all? Even though I have windows, clover, and four linux distros all set to boot from my firmware menu, plus the additional ones that show up when a USB is inserted. You say the entries change, but how do you know that they are changing? Are you adding new entries and those entries are then appearing in that output? Why would it be showing boot entries with no application path? You have two USB disks connected when you booted? Neither of which is bootable yet it shows an entry for?

 

EDIT: And I just told you that it is booting from \EFI\BOOT\BOOTX64.efi because I cleared my nvram, I'm not moving the bootmgfw.efi and trying to use it somewhere else. But that's entirely possible to do by changing the BCD, which is allowed by the bcdboot command.

 

EDIT2: To clarify, it does startup repair if the {bootmgr} path is different from the path it is booted, not specifically \EFI\Microsoft\Boot\bootmgfw.efi, that's just the default location.

I'm not sure what is going on with your setup apianti but I do know that bcdedit can read and edit firmware variables. displayorder under {fwbootmgr} represents the BootOrder firmware variable and its possible to set BootNext via the bootsequence option. I don't have the command I used on hand but I have set the boot order on an iMac after a Windows installation (EFI mode, not using Boot Camp) using the bcdedit command with the changes being reflected in Startup Disk under Mac OS so it wasn't just changing the BCD store.

 

21 hours ago, apianti said:

Why would it be showing boot entries with no application path?

Those appear to be representation of devices present on his system. My firmware has similar entries. Either they are for CSM (I believe I have CSM disabled on my system though) or they are entries that if the firmware reaches those entries that it checks the \EFI\BOOT\BOOT*.efi (potentially \EFI\Microsoft\Boot\bootmgfw.efi also) paths to try to boot from them, rather than scanning every device on every boot.


I only have Windows installed on this system and this is what my bcdedit lists for firmware entries:

Spoiler

C:\WINDOWS\system32>bcdedit /enum FIRMWARE

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {eace909f-3cb3-11e5-b87a-c28123693819}
                        {eace90a0-3cb3-11e5-b87a-c28123693819}
                        {eace90a1-3cb3-11e5-b87a-c28123693819}
                        {eace90a2-3cb3-11e5-b87a-c28123693819}
                        {eace909e-3cb3-11e5-b87a-c28123693819}
timeout                 1

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume4
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {631bdfec-580c-11e8-9c1a-9d7903c42521}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 0

Firmware Application (101fffff)
-------------------------------
identifier              {eace909e-3cb3-11e5-b87a-c28123693819}
description             ASUS    DRW-20B1LT

Firmware Application (101fffff)
-------------------------------
identifier              {eace909f-3cb3-11e5-b87a-c28123693819}
device                  partition=\Device\HarddiskVolume8
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager

Firmware Application (101fffff)
-------------------------------
identifier              {eace90a0-3cb3-11e5-b87a-c28123693819}
description             Samsung SSD 850 EVO 500GB

Firmware Application (101fffff)
-------------------------------
identifier              {eace90a1-3cb3-11e5-b87a-c28123693819}
description             ST3500320AS

Firmware Application (101fffff)
-------------------------------
identifier              {eace90a2-3cb3-11e5-b87a-c28123693819}
description             WDC WD30EFRX-68EUZN0

 

Share this post


Link to post
Share on other sites
16 hours ago, Zenith432 said:

This has got nothing to do with bcdboot.  The displayorder under my {fwbootmgr} was created by Windows automatically, and it's copied from the same boot order list I see in bios setup.  The non-Windows "Firmware Application" entries in bcdedit were created automatically.  I didn't add them manually.  They're an exact duplicate of what I see in bios setup, and the list in bios setup is created from an automatic firmware scan.  I just did a simple test - boot into bios setup - change the order of the first two entries - then boot Windows.  Then I run bcdedit and I see the displayorder of {fwbootmgr} has changed to be the same as the change I made in bios setup.  It's always acted this way, even with previous motherboard.  I am also sure that if I add or delete entries to the list in bios setup, it will automatically show up in bcdedit, because this has happened before.

Windows version is 10 1809.

Some of the firmware entries don't have specific path, but are a "partition", or just general device type ("hard drive").  It is the same in bios setup.

It is possible that the reason Windows never clobbers my \efi\boot\bootx64.efi is because there is a firmware entry in bcdedit listing this file.  But the firmware added this entry in bios setup from a scan, and it got copied.  I never put it into bcdedit.

the {bootmgr} path can never be different from the path Windows is booted.

Edit: Well, ok if chain-booted from Clover, or by manually selecing a file in bios setup or running from a shell then I guess it can but that's not what you're describing.  In a boot from the EFI boot list, the path to boot is taken from the {bootmgr} entry.

 

What build version? My point is that bcdboot is what initializes the BCD, according to the documentation bcdboot can only set windows boot manager and bcdedit can only read entries from the BCD. Did you ADD an entry and then it appeared in that list? Because changing the order is simply matching the order of variables. Since literally NONE of my five computers display any of these entries, they had to have been created by bcdboot when creating the BCD. I always install windows first, but even my surface pro and stick pc do not show these entries and windows was preinstalled, is the same version, and both have other OSes as well. Sigh... I literally just described to you a situation where windows can be booted from a different location BY DESIGN.

 

3 hours ago, SoThOr said:

I'm not sure what is going on with your setup apianti but I do know that bcdedit can read and edit firmware variables. displayorder under {fwbootmgr} represents the BootOrder firmware variable and its possible to set BootNext via the bootsequence option. I don't have the command I used on hand but I have set the boot order on an iMac after a Windows installation (EFI mode, not using Boot Camp) using the bcdedit command with the changes being reflected in Startup Disk under Mac OS so it wasn't just changing the BCD store.

 

Those appear to be representation of devices present on his system. My firmware has similar entries. Either they are for CSM (I believe I have CSM disabled on my system though) or they are entries that if the firmware reaches those entries that it checks the \EFI\BOOT\BOOT*.efi (potentially \EFI\Microsoft\Boot\bootmgfw.efi also) paths to try to boot from them, rather than scanning every device on every boot.


I only have Windows installed on this system and this is what my bcdedit lists for firmware entries:

  Reveal hidden contents

C:\WINDOWS\system32>bcdedit /enum FIRMWARE

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {eace909f-3cb3-11e5-b87a-c28123693819}
                        {eace90a0-3cb3-11e5-b87a-c28123693819}
                        {eace90a1-3cb3-11e5-b87a-c28123693819}
                        {eace90a2-3cb3-11e5-b87a-c28123693819}
                        {eace909e-3cb3-11e5-b87a-c28123693819}
timeout                 1

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume4
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {631bdfec-580c-11e8-9c1a-9d7903c42521}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 0

Firmware Application (101fffff)
-------------------------------
identifier              {eace909e-3cb3-11e5-b87a-c28123693819}
description             ASUS    DRW-20B1LT

Firmware Application (101fffff)
-------------------------------
identifier              {eace909f-3cb3-11e5-b87a-c28123693819}
device                  partition=\Device\HarddiskVolume8
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager

Firmware Application (101fffff)
-------------------------------
identifier              {eace90a0-3cb3-11e5-b87a-c28123693819}
description             Samsung SSD 850 EVO 500GB

Firmware Application (101fffff)
-------------------------------
identifier              {eace90a1-3cb3-11e5-b87a-c28123693819}
description             ST3500320AS

Firmware Application (101fffff)
-------------------------------
identifier              {eace90a2-3cb3-11e5-b87a-c28123693819}
description             WDC WD30EFRX-68EUZN0

 

 

Why would windows detect itself as a firmware application? That leads me to believe that it is indeed just copying firmware variables when bcdboot creates the BCD. Does your other windows install still exist? Does it say that the other one is there as a firmware application?

 

Also, I'm literally just done. I cannot stand this community anymore. I'm done. Have a great time guys but I'm just done, I don't care at all anymore. Goodbye.

Share this post


Link to post
Share on other sites
57 minutes ago, apianti said:

 

What build version? My point is that bcdboot is what initializes the BCD, according to the documentation bcdboot can only set windows boot manager and bcdedit can only read entries from the BCD. Did you ADD an entry and then it appeared in that list? Because changing the order is simply matching the order of variables. Since literally NONE of my five computers display any of these entries, they had to have been created by bcdboot when creating the BCD. I always install windows first, but even my surface pro and stick pc do not show these entries and windows was preinstalled, is the same version, and both have other OSes as well. Sigh... I literally just described to you a situation where windows can be booted from a different location BY DESIGN.

 

 

Why would windows detect itself as a firmware application? That leads me to believe that it is indeed just copying firmware variables when bcdboot creates the BCD. Does your other windows install still exist? Does it say that the other one is there as a firmware application?

 

Also, I'm literally just done. I cannot stand this community anymore. I'm done. Have a great time guys but I'm just done, I don't care at all anymore. Goodbye.

So it appears my firmware was set to show legacy devices in boot options and adding those additional devices. I disabled that option and now bcdedit shows:

Spoiler

C:\WINDOWS\system32>bcdedit /enum FIRMWARE

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {823d4ef6-7373-11e9-9caf-806e6f6e6963}
                        {eace909f-3cb3-11e5-b87a-c28123693819}
timeout                 1

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume4
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {631bdfec-580c-11e8-9c1a-9d7903c42521}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 0

Firmware Application (101fffff)
-------------------------------
identifier              {823d4ef6-7373-11e9-9caf-806e6f6e6963}
device                  partition=G:
description             UEFI: Lexar USB Flash Drive 1100

Firmware Application (101fffff)
-------------------------------
identifier              {eace909f-3cb3-11e5-b87a-c28123693819}
device                  partition=\Device\HarddiskVolume8
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager

The second \EFI\Microsoft\Boot\bootmgfw.efi is from an old Windows 8 install. When I upgraded to Windows 10 I installed an SSD into my system and installed it there. The OS is still there and it has an additional EFI partition. I can't recall exactly what I did but I believe I may have disconnected all other drives when I installed Windows 10.

 

And to show that bcdedit is showing the boot variables I booted into EFI shell from a USB stick and used "bcfg boot dump". Before disabling legacy boot:

Spoiler

Option: 00. Variable: Boot0000   
  Desc    - Windows Boot Manager
  DevPath - HD(2,GPT,1aca364d-82dd-4f63-ac0e-aa9aa224e877,0xe1800,0x31800)/\EFI\Microsoft\Boot\bootmgfw.efi
  Optional- Y
Option: 01. Variable: Boot0004   
  Desc    - Windows Boot Manager
  DevPath - HD(2,GPT,8429c978-b940-4995-82c2-1981df946ece,0x96800,0x32000)/\EFI\Microsoft\Boot\bootmgfw.efi
  Optional- N
Option: 02. Variable: Boot0008   
  Desc    - UEFI: Lexar USB Flash Drive 1100
  DevPath - PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x5,0x0)/USB(0x3,0x0)/HD(1,MBR,0x00020fa6,0x3f,0x64000)
  Optional- Y
Option: 03. Variable: Boot0005   
  Desc    - Samsung SSD 850 EVO 500GB
  DevPath - BBS(HD,)
  Optional- Y
Option: 04. Variable: Boot0006   
  Desc    - ST3500320AS
  DevPath - BBS(HD,)
  Optional- Y
Option: 05. Variable: Boot0007   
  Desc    - WDC WD30EFRX-68EUZN0
  DevPath - BBS(HD,)
  Optional- Y
Option: 06. Variable: Boot0009   
  Desc    - Lexar USB Flash Drive 1100
  DevPath - BBS(HD,)
  Optional- Y
Option: 07. Variable: Boot0003   
  Desc    - ASUS    DRW-20B1LT
  DevPath - BBS(CDROM,)
  Optional- Y

 

After disabling legacy boot:

Spoiler

Option: 00. Variable: Boot0000   
  Desc    - Windows Boot Manager
  DevPath - HD(2,GPT,1aca364d-82dd-4f63-ac0e-aa9aa224e877,0xe1800,0x31800)/\EFI\Microsoft\Boot\bootmgfw.efi
  Optional- Y
Option: 01. Variable: Boot0008   
  Desc    - UEFI: Lexar USB Flash Drive 1100
  DevPath - PciRoot(0x0)/Pci(0x14,0x0)/USB(0x9,0x0)/USB(0x3,0x0)/HD(1,MBR,0x00020fa6,0x3f,0x64000)
  Optional- Y
Option: 02. Variable: Boot0004   
  Desc    - Windows Boot Manager
  DevPath - HD(2,GPT,8429c978-b940-4995-82c2-1981df946ece,0x96800,0x32000)/\EFI\Microsoft\Boot\bootmgfw.efi
  Optional- N

 

While the name suggests its for BCD it is also able to read and alter boot variables in nvram, in a rather convoluted, obscure, Microsoft manner. It has to make it into \EFI\Microsoft\Boot\bootmgfw.efi somehow for any BCD entries to be relevant so being able to change the UEFI boot variables with bcdedit does make some sense. 

 

I apologize if came off aggressive towards you apianti. It wasn't my intention. I just wanted to add my experience with bcdedit to the conversation. What I meant was I don't understand why if you have Clover and Linux configured in your firmware that it doesn't show in bcdedit because from my experience I would expect to see there. As you can see on my system that "bcdedit /enum FIRMWARE" shows very similar information as "bcfg boot dump" and a change from the firmware settings changed something in bcdedit.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Slice
      OK, 4988 released.
      Now, @vector sigma, what have we do to update translations?
    • By fusion71au
      Clover r4989 ISO compiled with GCC and minimal config.plist compatible for use in VMWare Workstation.
       
      Tested with unlocked Workstation 15 running OSX 10.9 -->10.15 guest in Windows X64 host.
       
      Installation
      1. Download and unzip "EFI_Clover_r4989 for VMware.zip". Mount Clover-v2.4k-4989-X64.iso by double clicking on it.
      2. Mount your VM's EFI System Partition eg in terminal
      sudo diskutil mount disk0s1   3. Copy EFI folder from step 1 into the EFI partition
      4. Shutdown the VM, add bios.bootDelay = "3000" to your VM's vmx file
      5. Reboot your VM, press <F2> to access the VMware Boot Manager and add CLOVERX64.efi to the boot menu.
       
      Substitute your own unique and valid MLB and ROM variables in the /EFI/CLOVER/config.plist (Rt Variables section) to activate iMessage/Facetime on your VM.
    • By fusion71au
      Run Vanilla OS X El Capitan, Sierra, High Sierra or Mojave in VirtualBox 5.x.x on a Windows Host
      Following on from my previous guide on how to create a VMware virtual machine running Vanilla OS X El Capitan in Windows, I’ve decided to write a similar guide for creating a VirtualBox El Capitan VM. 
       
      The virtual machine should be useful for testing El Capitan and also for creating installers for use on a real machine/hackintosh.
       
      There are other tutorials and videos on the net about running OS X on Windows machines using pre-made VMDK disk images but you can never guarantee what else is in there….
       
      I’ve gathered info for this guide from several threads in the Multibooting and Virtualisation section of this forum and also the wider internet eg
       
      @colt2 HOW TO: Create a bootable El Capitan ISO for VMware
      @dsmccombs comment on faking Ivybridge Processor
      @E:V:A http://forum.xda-developers.com/showpost.php?p=55572430&postcount=6
      @Tech Reviews video tutorial https://www.youtube.com/watch?v=t7X07U63lwg.
      VirtualBox Forum: Status of OSX on OSX
       
      Requirements
         Intel PC with four or more CPU cores running Windows 7 X64 or later OS (2 or more cores needed for OS X)    4GB or more RAM (2GB or more will be needed for OS X)    Hard Disk with at least 40GB free for Virtual Machine    Oracle VM VirtualBox v 5.0.34    Install OS X El Capitan app and Mac or Hack to prepare installation iso <-- Now, no longer necessary to have previous access to a Mac or Hack by building the Installer.app from scratch - see post#75    16GB or larger exFAT formatted USB stick to transfer El Capitan iso from Mac/Hack to Host PC  
      Prepare Installation ISO on your Mac or Hack
      1.  On your Mac or Hack, download "Install OS X El Capitan.app" from the App Store into your Applications folder.
      2.  Download and unzip the CECI.tool (attached to this post) into your ~/Downloads folder. The commands in this executable script are shown below for informational purposes.  Note: you will need approx 16GB of free space on your hard disk for the script to complete.
       
       
       
      3.  Open OS X terminal, then run the following commands to execute the script:
      cd downloads chmod +x CECI.tool ./CECI.tool 4.  At the end of the process, you will have an El Capitan iso on your desktop - copy this onto an exFAT formatted USB for use on the PC Host later.
       
       
      Create an El Capitan Virtual Machine in VirtualBox
      1.  Open the VirtualBox program and click the "New" button to create a new VM.
       

       
      2.  Select Mac OS X and Mac OS X 10.11 El Capitan (64 -bit) for Operating System type and version.  I named my Virtual Machine "El_Capitan", then clicked next...
       

       
      3.  Leave the Memory size at the recommended 2048 MB, then click next.
       

       
      4.  Choose to "Create a virtual hard disk now", then click the create button.
       

       
      5.  For the hard disk file type, the default is VDI (VirtualBox Disk Image) but I have selected VMDK for inter-operability with VMWare.  Click next...
       

       
      6.  For Storage on physical hard disk, I have chosen the default Dynamically allocated (grows larger to a set limit as you need more disk space).
       

       
      7.  On the File location and size screen, you can set the location of the new virtual hard disk and its size - I recommend changing disk size to 40GB or larger.  When you click the create button, you will now see your new VM in the VirtualBox main GUI.
       

       
      8.  Click the settings button on the Main Menu to tweak a few settings....
         a.  On the System/Motherboard tab in Boot Order, you can uncheck the Floppy Drive (who has these now?)
       

       
         b.  On the System/Processor tab, you can increase the allocated CPU cores to 2
       

       
         c.  On the Display tab, you can increase the allocated Video Memory to 128MB
       

       
         d.  On the Storage tab, click on the icon of the Optical Drive and select "Choose Virtual Optical Disk File". 
       

       
      Navigate and select the El Capitan ISO we created earlier...
       

       
         e.  Click the OK button to finalise the VM settings.
       
       
      Patch El Capitan vbox configuration file with DMI Settings from a Mac
      1.  From the start menu, type cmd and click run as administrator to open an administrative command prompt. 
       

       
      2.  Choose a Mac Model similar to your host system, then type the following lines, followed by <enter>  after each line.  Make sure you first close all VirtualBox Windows and the VirtualBox program, otherwise any changes you make won't stick...
       
      Eg iMac11,3
      cd "C:\Program Files\Oracle\VirtualBox\" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "iMac11,3" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemVersion" "1.0" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Mac-F2238BAE" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1 MacBookPro11,3
      cd "C:\Program Files\Oracle\VirtualBox\" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "MacBookPro11,3" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemVersion" "1.0" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Mac-2BD1B31983FE1663" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1 Macmini6,2
      cd "C:\Program Files\Oracle\VirtualBox\" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "Macmini6,2" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemVersion" "1.0" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Mac-F65AE981FFA204ED" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1 3.  Optional- For some host systems eg those with Haswell and newer CPUs, you might have to spoof an older CPU to avoid VirtualBox errors.  You can try from one of the following if this happens:

      To spoof Lynnfield i5 750 CPU
      VBoxManage.exe modifyvm "El_Capitan" --cpuidset 00000001 000106e5 06100800 0098e3fd bfebfbff To spoof IvyBridge CPU
      VBoxManage.exe modifyvm "El_Capitan" --cpuidset 00000001 000306a9 04100800 7fbae3ff bfebfbff or
      VBoxManage.exe modifyvm "El_Capitan" --cpuidset 00000001 000306a9 00020800 80000201 178bfbff 4.  Close the command prompt window.
       
       
      Installation of El Capitan
      We are now ready to start the El_Capitan Virtual Machine....
       



       
      Installation should be relatively straight forward, just following the prompts of the OS X installer:
      1.  Select language, agree to legal terms
       

       
      2.  Use Disk Utility from the Utilities Menu to erase and format the virtual hard drive as a single partition GUID Mac OS X Extended.  I named my drive "Macintosh HD" but you can enter whatever you like eg El_Capitan.
       

       
      3.  Quit DU and choose Macintosh HD to install El Capitan on.
      4.  After 20-30 min (depending on how fast your system is), the installation will complete.  At this point, unmount the El Capitan ISO by clicking the Devices menu from the VM window, click Optical Drives, then choose Remove disk from virtual drive.  The VM is now ready to reboot into OS X from the virtual hard drive.
      5.  At the welcome screen, choose your country and keyboard layout.  You can skip transfer information, location services and logging in with your Apple ID if you wish…
      6.  Create a User Account and select your Time Zone.  You can skip sending diagnostics and usage data to Apple….
      7.  Finally, you will arrive at the El Capitan Desktop.
       

       
      8.  Network/internet and audio should work OOB but on my system, the sounds were distorted.  Unfortunately, there is no QE/CI and the VM resolution will be fixed without the ability to dynamically resize the VM window (no VirtualBox additions for OS X guests atm). 
       
       
      Customization with VBoxManage
      1.  You can change the default resolution of 1024*768 (after shutting down the VM) with the VBoxManage command from the Windows Administrative Command Prompt:
      cd "C:\Program Files\Oracle\VirtualBox\" VBoxManage setextradata "El_Capitan" VBoxInternal2/EfiGopMode N (Where N can be one of 0,1,2,3,4,5) referring to the 640x480, 800x600, 1024x768, 1280x1024, 1440x900, 1920x1200 screen resolution respectively.
       
      Update:  For VirtualBox 5.2.x, the command for changing screen resolution has changed...
       
      VBoxManage setextradata "<MyVM>" VBoxInternal2/EfiGraphicsResolution XxY (where X=Horizontal screen resolution, Y=Vertical screen resolution)
      eg
      VBoxManage setextradata "<MyVM>" VBoxInternal2/EfiGraphicsResolution 1280x1024 2.  Adding serials and other SMBIOS details for the System Information Screen
      VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemSerial" "W8#######B6" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBoardSerial" "W8#########1A" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemVendor" "Apple Inc." VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiSystemFamily" "iMac" VBoxManage setextradata "El_Capitan" "VBoxInternal/Devices/efi/0/Config/DmiBIOSVersion" "IM112.0057.03B" A listing of known issues with Mac OS X guests can be found in the VirtualBox Manual - link https://www.virtualbox.org/manual/ch14.html.
       
      Vanilla Mavericks and Yosemite, Snow Leopard from Retail DVD
      The same VM settings for El Capitan will also boot and run vanilla installations of OS X Mavericks and Yosemite .  Attached to this post are installer scripts to create bootable Mavericks (CMI.tool) and Yosemite (CYI.tool) ISOs for VirtualBox and VMware.
       
      With the respective OS X installer apps in the Applications folder, download and run the installer tools using terminal ie
       
      To create a Mavericks ISO on your desktop
      cd downloads chmod +x CMI.tool ./CMI.tool To create a Yosemite ISO on your desktop
      cd downloads chmod +x CYI.tool ./CYI.tool Here is a screenshot of the VM running Mavericks 10.9.5...
       

       
      Finally, those without a Mac/Hack to prepare the install media can purchase a retail Snow Leopard DVD directly from Apple and install OSX 10.6.3 on their virtual machines (Snow Leopard, Lion and Mountain Lion run quite happily in VirtualBox with 1 CPU, 1-2 GB of RAM and the rest of the settings unchanged from above).  Once you update by combo update to SL 10.6.8, you can directly download El Capitan from the App Store for free .
       

       
      UPDATE macOS Sierra 10.12 to 10.12.6: For macOS Sierra, use CSI.tool in post#51.
      UPDATE macOS High Sierra 17A365:  For macOS High Sierra, use CHSI.tool in post#73.
      UPDATE macOS Mojave 18A391:  For macOS Mojave or High Sierra, use macOS_iso_creator.tool on page 4 of thread.
      UPDATE macOS Catalina Beta DP3_19A501i:  For Catalina, @jpz4085 has made an automated batch file to create a Catalina VM in Windows with iMac 14,2 SMBIOS.  You can still use my macOS_iso_creator.tool on page 5 to make an installer ISO to attach to the VM.
       
       
       
      Good luck and enjoy
      CECI.tool.zip
      CYI.tool.zip
      CMI.tool.zip
    • By JackBauer24
      Hello,
       
      I have installed OSx86 10.11 (El Capitan) on April 2016 on my Asus Z170 Deluxe system.
       
      For installation I used this Thread.
       
      I used it a lot and it worked well. Meanwhile I switched to Linux and I use Win10 time to time. So OSX was forgotten. Also it did not boot correctly anymore.
       
      Now I wanted to start with a fresh installation and use OSX more often again. I want to use OSX 10.13 High Sierra. Is it working on my Asus Z170 Deluxe? I have the same Hardware as of April 2016 only the graphics card was updated to a Nvidia GTX1080.
       
      My Hardware in detail: Asus Z-170-Deluxe (Bios 3801), i7-6700k, EVGA GeForce GTX 1080 SC GAMING ACX 3.0, Samsung 950 Pro/M2 NVME 512MB, HDD 4 TB)
      Can I use some of support files from the old thread for the installation (see attachment)? Can I still use  Clover 2.3k r3292 Special Edition v2 ? Or do I need a newer version?
       
      Has someone installed High Sierra successfully on the Asus Z170 Deluxe ?
       
      About some hints where to start I would be thankful.
       
      regards
      JackBauer24
       
      Z170DeluxeFiles.zip
×