Clover General discussion

[vector sigma]

So the fix is to use the one from Clover by skipping duplicated drivers. The change made by Slice per se has nothing to do with the bug. The bug is to copy a duplicated driver

[arsradu]

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

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.

 

[vector sigma]

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

[vector sigma]

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?

[arsradu]

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 May 7, 2019 by arsradu

[vector sigma]

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.

[LockDown]

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?

[Slice]

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.

[arsradu]

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:

 

Which seems to be set up above by this:

 

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 May 8, 2019 by arsradu

[vector sigma]

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 May 8, 2019 by vector sigma
typo

[tluck]

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?

[arsradu]

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 May 9, 2019 by arsradu

[apianti]

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.

[Zenith432]

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.

[apianti]

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:

 

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 May 9, 2019 by apianti

[Zenith432]

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.

[apianti]

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 May 9, 2019 by apianti

[tluck]

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 May 9, 2019 by tluck

[apianti]

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 May 9, 2019 by apianti

[Zenith432]

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 May 9, 2019 by Zenith432

[apianti]

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 May 9, 2019 by apianti

[Zenith432]

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 May 10, 2019 by Zenith432

[Slice]

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.

[SoThOr]

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

 

[apianti]

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.