Jump to content
ErmaC

Clover General discussion

22,506 posts in this topic

Recommended Posts

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

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

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

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

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

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

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

No, I'm just generally irritated by the fact that I research things, say what is going on, people say some nonsense, I provide documentation/evidence, no one reads it, and then says the same things without any evidence to the contrary of what I said. For instance, I am in windows 10, plugged in an ubuntu installer and ran these commands, at no point did I restart:

 

Spoiler

C:\WINDOWS\system32>bcdboot C:\Windows /s F: /f UEFI /p /d
Boot files successfully created.

C:\WINDOWS\system32>bcdedit /enum all

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {ddc6602b-7388-11e9-be05-806e6f6e6963}
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            {459d8026-7384-11e9-be04-d0509976b8c9}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 0

Firmware Application (101fffff)
-------------------------------
identifier              {ddc6602b-7388-11e9-be05-806e6f6e6963}
device                  partition=F:
description             UEFI: PNY USB 2.0 FD 0.00

Windows Boot Loader
-------------------
identifier              {41f2a636-4ded-11e8-8371-f56bc31a9418}
device                  ramdisk=[unknown]\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=[unknown]\Recovery\WindowsRE\Winre.wim,{41f2a637-4ded-11e8-8371-f56bc31a9418}
systemroot              \windows
nx                      OptIn
bootmenupolicy          Standard
winpe                   Yes

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \WINDOWS\system32\winload.efi
description             Windows 10
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {85b68803-7385-11e9-8525-80c21444cd72}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \WINDOWS
resumeobject            {459d8026-7384-11e9-be04-d0509976b8c9}
nx                      OptIn
bootmenupolicy          Standard

Windows Setup
-------------
identifier              {7254a080-1510-4e85-ac0f-e7fb3d444736}
device                  ramdisk=[C:]\$WINDOWS.~BT\Sources\SafeOS\winre.wim,{459d8028-7384-11e9-be04-d0509976b8c9}
bootstatdevice          partition=C:
custom:11000083         partition=C:
path                    \windows\system32\winload.efi
description             Windows Rollback
locale                  en-US
bootstatfilepath        \$WINDOWS.~BT\Sources\SafeOS\bootstat.dat
inherit                 {bootloadersettings}
restartonfailure        Yes
osdevice                ramdisk=[C:]\$WINDOWS.~BT\Sources\SafeOS\winre.wim,{459d8028-7384-11e9-be04-d0509976b8c9}
custom:21000152         partition=C:
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

Windows Boot Loader
-------------------
identifier              {85b68803-7385-11e9-8525-80c21444cd72}
device                  ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{85b68804-7385-11e9-8525-80c21444cd72}
path                    \windows\system32\winload.efi
description             Windows Recovery Environment
locale                  en-US
inherit                 {bootloadersettings}
displaymessage          Recovery
osdevice                ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{85b68804-7385-11e9-8525-80c21444cd72}
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

Resume from Hibernate
---------------------
identifier              {459d8026-7384-11e9-be04-d0509976b8c9}
device                  partition=C:
path                    \WINDOWS\system32\winresume.efi
description             Windows Resume Application
locale                  en-US
inherit                 {resumeloadersettings}
recoverysequence        {85b68803-7385-11e9-8525-80c21444cd72}
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              {459d8028-7384-11e9-be04-d0509976b8c9}
description             Windows Setup
ramdisksdidevice        partition=C:
ramdisksdipath          \$WINDOWS.~BT\Sources\SafeOS\boot.sdi

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

Device options
--------------
identifier              {85b68804-7385-11e9-8525-80c21444cd72}
description             Windows Recovery
ramdisksdidevice        partition=\Device\HarddiskVolume5
ramdisksdipath          \Recovery\WindowsRE\boot.sdi

 

Magically.... I have a firmware application for the usb! BOOTX64.efi does not get overwritten. However, if I clean the USB and perform the same command. BOOTX64.efi is written, back to original output of bcdedit with no firmware applications, if I then overwrite BOOTX64.efi and then run the same command again, BOOTX64.efi is overwritten.

 

EDIT: And that is called the prestige. Good night!

 

EDIT2: I forgot to say don't do this as you can destroy your whole installation.

 

Edited by apianti

Share this post


Link to post
Share on other sites
On 5/10/2019 at 5:33 AM, apianti said:

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 agree with the part about the Windows BCD having nothing to do with EFI entries. The next part is where I think we start to disagree. It is unclear what you are referring to as "it" but Windows IS capable of editing EFI Boot entries and it IS possible to do this via bcdedit. Perhaps bcdboot was what you were referring to and if that is the case then I think I would agree with you but that was not mentioned until after the above quoted message. 

 

On 5/10/2019 at 7:47 AM, apianti said:

 bcdedit only reads from the BCD for entries.

bcdedit does read from EFI boot entries if you use either "ALL" or the "FIRMWARE" options for the /enum argument (or at minimum a cache copy of the entries that is created at boot). As pointed out in my previous posts my firmware likes to add extra Boot#### variables other than ones added manually or by installers and they appear with the bcdedit /enum FIRMWARE command. My evidence given in my previous post.

 

Maybe I am interpreting what you said incorrectly but these the reasons I decided to add my 2 cents.


Anyway, I think this is straying from what your initial point was. That using Clover at \EFI\BOOT\BOOTX64.efi is unsafe as Windows or potentially any other OS or bootloader could overwrite that file. Which I agree entirely.

 

I think I shall go back to lurking now.

Share this post


Link to post
Share on other sites
9 minutes ago, SoThOr said:

I agree with the part about the Windows BCD having nothing to do with EFI entries. The next part is where I think we start to disagree. It is unclear what you are referring to as "it" but Windows IS capable of editing EFI Boot entries and it IS possible to do this via bcdedit. Perhaps bcdboot was what you were referring to and if that is the case then I think I would agree with you but that was not mentioned until after the above quoted message. 

 

bcdedit does read from EFI boot entries if you use either "ALL" or the "FIRMWARE" options for the /enum argument (or at minimum a cache copy of the entries that is created at boot). As pointed out in my previous posts my firmware likes to add extra Boot#### variables other than ones added manually or by installers and they appear with the bcdedit /enum FIRMWARE command. My evidence given in my previous post.

 

Maybe I am interpreting what you said incorrectly but these the reasons I decided to add my 2 cents.


Anyway, I think this is straying from what your initial point was. That using Clover at \EFI\BOOT\BOOTX64.efi is unsafe as Windows or potentially any other OS or bootloader could overwrite that file. Which I agree entirely.

 

I think I shall go back to lurking now.

 

No, actually neither is capable of creating EFI entries in the way you think. They both can create one entry, the one pointed to by {bootmgr} (previously bcdedit could only modify the entry but it seems that it creates it now as well if needed). The firmware entries are added by bootmgfw.efi to the BCD that is passed into the system for usage (through the registry) and to prevent not having a default loader has some setting to replace BOOTX64.efi (while apparently not properly enumerating the rest of the firmware entries). I'm going to turn off my notifications now. Because I am serious, I am not enjoying doing this anymore.

Share this post


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

 

No, actually neither is capable of creating EFI entries in the way you think. They both can create one entry, the one pointed to by {bootmgr} (previously bcdedit could only modify the entry but it seems that it creates it now as well if needed). The firmware entries are added by bootmgfw.efi to the BCD that is passed into the system for usage (through the registry) and to prevent not having a default loader has some setting to replace BOOTX64.efi (while apparently not properly enumerating the rest of the firmware entries). I'm going to turn off my notifications now. Because I am serious, I am not enjoying doing this anymore.

 

I didn't claim that bcdedit could create EFI boot entries. I said it could read and edit them. I realize bcdedit is a tool created for managing the Windows BCD however Microsoft has added the ability to read and modify EFI Boot entries also. I am not confusing BSD entries and EFI entries either. It might not be very well documented that it is able to modify EFI Boot entries but it can and I have used it previously to make modifications to EFI Boot entries.

 

Out of curiosity I tried to see if bcdedit could create EFI Boot entries and I managed to find a way to create EFI boot entries using bcdedit. It's a little bit of a hack but it is possible. Rather than posting here I decide to start a new thread. If anyone is interested they can read more about how here.

Share this post


Link to post
Share on other sites

Siiiiiiiiiiiiiiiiiiiiiiiiiiiiigggggggggggggggggghhhhhhhhhhhhhhhh...................... You missed my point, it is not reading the EFI entries. It is reading the BCD from the registry, which was populated with firmware entries by bootmgfw.efi on boot. If I go into the registry and look at the BCD I have firmware entries there, yet none of them are displayed in bcdedit /enum all. Also as I said it can create one entry {bootmgr}, I'm pretty sure what you describe in the other topic is a bug (just like the enumeration one I am saying there is) not to mention that yes it includes the option data which can cause undefined behavior in whatever you created when launched... If it was able to create actual entries then you would be able to add an entry that is simply a firmware application, you cannot do this. The only way to edit EFI entries is to use the windows API. Windows applications and drivers can't even read or write nvram variables without a special certificate from microsoft (that you must request and provide reasons why you need to use nvram), and additionally being signed, having two special attributes, being run as an administrator or the system and that user has to have a special privilege. What you have described is actually an easy way for a rootkit to be installed, which completely defeats the purpose of all their restrictions on nvram access.

Share this post


Link to post
Share on other sites

I have two MacOS installations -- is there a way to specify per-volume "config.plist" files so that a different configuration is automatically loaded without manually loading a new config in Options?  E.g., "config.plist" is tied to "High Sierra" and config2.plist is tied to "Mojave"?

Share this post


Link to post
Share on other sites

This is just wrong idea.

All patches in config.plist are os version specific. No need to have different configs.

Or you want to have different GUI themes before choosing an OS?! Christmas for High Sierra and NewYear for Mojave?

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

Announcements

  • Similar Content

    • By surfermax
      buon giorno 
      spero tu mi possa aiutare ,perche' non riesco piu' a far partire i miei 2 ssd 850 samsung sui quali highsierra funzionava perfettamente da 1 anno e non ce' maniera di farlo ripartire .unica cosa e' che riesco ad arrivare alla console dell'istaller e ho tentato varie volte di ripristinare da una time machine che ho salvato su un altro disco usb .
      il mio sistema e' un asus p5qd turbo ed e7500 dual core . grafica gtx1050 chr funzionava con accelerazione e webdriver nvidia .audio voodoo 282. e boot clover che e' sempre stato il 5103 che poi  ho aggiornato a 5120 proprio il giorno prima che succedesse il fattaccio .quel giorno ho aggiornato dal sito apple la comboupdate 10.13 .6 da 10.13.4 .e qui al riavvio boom niente diski in clover nn li visualizzava piu .ora sciacciando f3 visualizzo il preboot e lssd con highsierra aggiornato ma arrivato alla console andava in reset loop .
      a questo punto riesco a ripartire togliendo l'accelerazione .e installando i nuovi webdriver di nvidia aggiornati all 10.13.6 .
      al riavvio non parte piu' con accelerazione e sempre problema in clover dei diski ma riuscivo a partire con f3 e preboot .
      ora decido di installare da time machine e tornare alla versione 10.13.4 del giorno prima ..e al riavvio niente piu dischi ne preboot .sono fermo a questo punto ..riesco solo a far partire installer ma nn so i comandi da dare in terminal per aggiustare le cose . ho anche linux su un altro notebook. ti ringrazio anticipatamente per l'aiuto .
    • By pink101
      So, here's what i think clover do when it patch ati framebuffer, first it read a cached kext, then it search the original hex value of the connector, then it changed the value with the new one. Is it correct? now, here's what i find confusing... let's say that i want to patch AMD7000Controller.kext, in that kext, i want to patch "AJI" framebuffer with a new value, so clover try to find the hex value of "AJI" connector then replace it with the new one, simple right? but when i search the AMD7000Controller binary file for other framebuffer, some of them didn't exist in the binary, for example, i tried to patch "Ramen" framebuffer, from various source, it said that:
      Ramen (6) @ 0xeba70 LVDS, HDMI, DP, DP, DP, DP 020000000001000039050108000000002001050600000000 000800000402000000010200000000001000030500000000 000400000403000000010343000000001102010100000000 000400000001000000010431000000002103040300000000 000400000403000000010563000000001204020200000000 000400000001000000010651000000002205040300000000 So i open a hex editor and search for:
      020000000001000039050108000000002001050600000000000800000402000000010200000000001000030500000000000400000403000000010343000000001102010100000000000400000001000000010431000000002103040300000000000400000403000000010563000000001204020200000000000400000001000000010651000000002205040300000000 but, it turns out that hex editor couldnt find that hex value in AMD7000Controller,

       
      most of the framebuffer exist in the AMD7000Controller, but some doesnt, If this is the case, then, where does clover find the original framebuffer to be patched? am i missing something?
       
       
    • By tluck
      Lenovo T460 macOS with Clover Guide
      Latest Release on GitHub (July 2020) Updated to Clover r5120 Updated Lilu based kexts - Lilu, ALC, WEG Added AirportBrcmFixup.kext
        Various Tweaks over Last months The main branch in my github repo is a complete Clover ESP (/EFI) bundle and kext pack for the Lenovo T460. The current file bundle seems to work on Sierra, HighSierra, Mojave and Catalina. There is an OpenCore branch in the repo as an alternative to Clover. This guide was developed for a Clover implementation. But the thread has evolved to include discussion of both Clover and Opencore for these systems: T460 and T470 family of ThinkPads.
       
      Full Clover file set - config.plist etc. Includes all custom kexts Includes custom DSDT/SSDT scripts and patches Utility scripts The zip bundles are posted to GitHub: https://github.com/tluck/Lenovo-T460-Clover/releases
      Caveat: The T460 systems used here was configured with: i5-6300U, Intel HD Graphics 520, 1920x1080 touch screen. If you have a different system model, then extract the ACPI files and use the included scripts to create a set of files consistent with your system type and BIOS version. See below for details.
      Credits: RehabMan, Shmilee, vusun123, TimeWalker, Mieze from which, much of their work and help is/was was used to get the T460 to this point.
      Devices and aspects working:
      Ethernet -  Intel I219LM is enabled via IntelMausiEthernext.kext WiFi/BT - substitute the Intel WiFi/BT with a compatible Broadcom or Atheros chip Audio - ALC293 codec implemented via AppleALC.kext (the old AppleHDA_ALC293 and CodecCommander kexts are not needed) PS2 - ClickPad + TrackPoint + all 3 buttons - using a modified VoodooPS2Controller to support new layouts - and added some custom Fn key maps based on 440/450 dsdt USB - implemented via custom SSDT + USBInjectAll kext. All USB3/USB2 ports are intel-based and work -  3 external USB and internal Camera, BT, etc  Sleep/Wake - the sleepwatcher package and custom sleep/wake scripts are used to help with sleep/wake for BT and PS2 devices. Note: have not tried to implement the SD card reader - no driver found.
      ACPI Files
      New Installation - Steps and Details
      Part 1 - OS Installation
      Part 2- Post OS Installation and Setup
      Notes on Custom Kexts
       
    • By tlefko
      News
      In light of the recent WWDC, we will begin testing the functionality of our EFI on macOS 11 for this device with the latest developer preview Version Info
      Features and Overview
      Now Compatible with 10.15.6 Please leave feedback with issues or w/o Comitted to Updating up to OS 11 Multitouch Trackpad Support 4K @60 Hz Fixed Bluetooth and Wifi Stability Issues Preformance and Power Management Additional Patches for 4K Display updated for 15.6 rev 1 Sleep Wake is functional for some models ----if screen glitches on wake or reopen lid. If this is a bother just disable sleep. This is issue is resolved in Big Sur Bugs
      Some models may experience screen split in half. If so disable. USB devices eject (external) No Internal Mic What Works
      Everything minus sleep issue above, internal microphone. (audio is fine, headphones / usb mic fine, just not laptop mic) POST
      run sudo pmset -a hibernatemode 0
      Description
      This esentially an ultra-simplistic version that is stable without the use of a deploy or complicated file installations and copies. You can easily view all the DSDT patches along with configuration files for the bootloader as they are all documented clearly in the files. This does include a copy of Clover, which of course I do not contribute to and am only responsible for the provided files, patches, and kext placements This guide provides a working setup with little knowledge of the topic and without "optimization" (because often they can break things). But, it is fully functional and preforms properly and is stable.
      Unsupported Wifi
      Make sure you are using DW1560 or 1820a for wifi or else there is a risk of KP. If not using remove BRCM kexts from CLOVER>kexts>other Styling
      This guide is designed to be literally as thorough as possible to appeal all types of users. It does not cover complex topics like undervolting etc etc only to provide a completely functional system
      Notes
      Never tested USB C except for charging, USB, works great (not sure about DispOut) 4K model has sleep wake issues occasionally, 1080P is fully functional BIOS
      Disable Secure Boot Disable Vt-d Recommended: Clean Install (Preinstall steps)
      Format a USB (16GB) as Journaled and then proceed to download the latest Catalina Installer Patcher Application. Download the latest Catalina installer from within the Patcher App, and select to download a new copy and install to your USB device Download the clover configurator application and mount the EFI of the USB partition, then copy the contents of the Files linked above to A new EFI Folder (that you create) within the EFI partition. ** This is because the App Store installers will often not download a full installer, just an truncated version that downloads the installer files from the interent while installing. Thus, they're not bootable from a USB as they're not complete. That is why you should use this method to make sure the installer is usable for bootable media.
      Boot From USB
      Use f9, copy EFI folder to efi partition of your usb. after installation complete copy EFI to your ssd. Boot Entry Setup
      Reccomend using windows to find a tool to add a UEFI bios entry to boot EFI/Boot/bootx64 Credits
      @MaLd0n for DSDT Patches and support (HUGE SHOUTOUT) Original Kexts Authors Clover Headphones and Audio
      All audio from speakers should work perfectly along with Bluetooth and USB audio Finished!
      Congratulations, there really aren't any more steps that are required. Feel free to contact me with any questions.
      Donations
      Send me a coffee lefkotyler@gmail.com
      EFI Catalina.zip
       
      **for latest releases and faster replies please refer to GitHub https://github.com/tlefko/HP-ENVY-13-2020-Catalina
×