Slice Posted May 8, 2019 Share Posted May 8, 2019 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. 3 Link to comment Share on other sites More sharing options...
arsradu Posted May 8, 2019 Share Posted May 8, 2019 (edited) 12 hours ago, ellaosx said: Hi @arsradu where do you insert USE_APPLE_HFSPLUS_DRIVER in your script? Hi Ella! I'm not using that option. As I said in one of my previous posts, that was a misunderstanding on my side. However, in ebuild.sh, under Options, I can see this: 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 Link to comment Share on other sites More sharing options...
vector sigma Posted May 8, 2019 Share Posted May 8, 2019 (edited) 16 hours ago, Slice said: I think it is better not to use achid drivers. We should not depend on alien project. We have to use only own files and let users use any other drivers downloaded anywhere they want. I like the apfs wrapper + AptioMemoryFix and AptioInputFix. Should be better to take those? At the end giving a specific argument to ebuild.sh to download external drivers is just a will for who write that in the Terminal. Please let me know. Edited May 8, 2019 by vector sigma typo Link to comment Share on other sites More sharing options...
tluck Posted May 9, 2019 Share Posted May 9, 2019 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? Link to comment Share on other sites More sharing options...
arsradu Posted May 9, 2019 Share Posted May 9, 2019 (edited) 2 hours ago, tluck said: Yup - i had to go with "--ext-co" vs (pre) to get a proper build with the expected UEFI drivers. question: i dont recall having this problem before Mojave, but unless I move my /ESP/EFI/Microsoft folder out of the way for an OS update, Clover wants to boot up microsoft in the middle of the update. meaning i download the update package. it creates the boot files in / (root) and then reboots and Clover picks Boot from MacOS Install or something like that. all seems right... I see the usual progress bar and sometimes i get a white flash, but then it reboots. But now instead of restarting with the macOS Install, Clover wants to boot up the Microsoft. so i have to manually pick the Install icon. However, if I rename the Microsoft folder to M, then macOS update works without issue. Is there a better location/name for the EFI/Microsoft folder so it doesnt confuse Clover during a macOS update? I remember having the same issue before... Are you using both Windows and MacOS from the same drive? Or separate drives? If so, which one is set in Bios as primary boot drive? In case they're separate, make sure Bios is set to boot from the MacOS drive. If they're not, well, I'm not sure... I know Windows wants to always be on top. First boot, etc. And it doesn't play well with other operating systems on the same drive. Not even with more than one drive (even if the other ones have no OS or Windows on them). It won't get installed. This is an ancient issue, and for as far as I know, to this day it's still present. In order to get Windows installed on a machine that has multiple drives, you have to unplug all the other drives and only leave the one you want Windows installed on. I'm not sure this issue is with Clover as much as it's with Microsoft itself. But I could be wrong here. Edited May 9, 2019 by arsradu Link to comment Share on other sites More sharing options...
apianti Posted May 9, 2019 Share Posted May 9, 2019 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. 1 1 Link to comment Share on other sites More sharing options...
Zenith432 Posted May 9, 2019 Share Posted May 9, 2019 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. 1 Link to comment Share on other sites More sharing options...
apianti Posted May 9, 2019 Share Posted May 9, 2019 (edited) That's weird because I have installed clover as \EFI\BOOT\BOOTX64.efi and then created a boot entry to \EFI\CLOVER\CLOVERX64.efi. Guess what? Windows updated and now my \EFI\BOOT\BOOTX64.efi is a copy of \EFI\Microsoft\Boot\bootmgfw.efi. It absolutely does this, clear your nvram after a windows update and windows will boot, say something happened to your startup, do a bunch of random nonsense, make you restart and will have set itself as the default pointing to \EFI\Microsoft\Boot\bootmgfw.efi. If masking was the issue then you would have to use the alternate method of launching clover in the first place, unless you already know before hand and install to the disk, boot from a USB, use the EFI shell to set the boot entry. I'm pretty sure you wouldn't be asking a question about why it was happening if you were aware of this. And are you really telling me how to use bcfg or bcdedit? Windows BCD only contains entries pertaining to windows boot manager and does nothing with EFI entries. It is not capable of editing EFI boot entries, however, it can chain load, though it doesn't always work. I just updated my windows like a week ago and my clover like a week before that, here is proof that it does overwrite \EFI\BOOT\BOOTX64.efi: 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 Link to comment Share on other sites More sharing options...
Zenith432 Posted May 9, 2019 Share Posted May 9, 2019 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. Link to comment Share on other sites More sharing options...
apianti Posted May 9, 2019 Share Posted May 9, 2019 (edited) Yeah, where on earth would I gather information pertaining to bcdedit... Maybe the microsoft resources? https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcdedit-command-line-options I think you are confusing bcdedit with bcdboot, which is also not capable of adding any EFI boot entries except for windows boot manager, which is exactly what happens during an update. And I don't mean like a random security fix, I mean the actual build updates. https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcdboot-command-line-options-techref-di EDIT: Also, what you're describing is a non-compliant implementation of (U)EFI, which is not what I was saying, I was saying that if windows detects that it has been booted from any place other than \EFI\Microsoft\Boot\bootmgfw.efi, it performs startup repair. EDIT2: And you should be using \EFI\CLOVER\CLOVERX64.efi, the \EFI\BOOT\BOOTX64.efi is provided for the exact reason that windows overwrites it, so that it is the default on the disk when there is no entry for the actual clover location. Edited May 9, 2019 by apianti Link to comment Share on other sites More sharing options...
tluck Posted May 9, 2019 Share Posted May 9, 2019 (edited) hmm. I see confirmation of the issue but not sure I see real advice yes I dual boot macOS and Window10 on same disk. for me: MacOS/Clover updates/uses: /EFI/Clover/CloverX64.efi /EFI/BOOT/BootX64.efi (copy/dup of above) windows updates/uses /EFI/Microsoft/boot/bootmgfw.efi they seem to co-exist nicely my BIOS on either my Dell and Lenovo T420 bootlist have Clover as 1st option and Window Manager as 2nd option. I see that clover always gets picked during the boot up ( same for the update process) sometimes the install process boots up just fine and then Reboots. it is on this 2nd round of booting up the installer things get odd instead of selecting the macOS install entry (like the previous boot up) to continue the updating (presumable this is set in NVRAM to override the default macOS volume) - it uses the Windows boot option -- unless I intervene. all is fine if mv /EFI/Microsoft to /EFI/M before the update and then revert after. just a pain in the neck. Edited May 9, 2019 by tluck Link to comment Share on other sites More sharing options...
apianti Posted May 9, 2019 Share Posted May 9, 2019 (edited) This is a different issue altogether. I'm assuming you have it set to timeout and automatically boot macOS? Please look at your preboot.log when this happens and see if the selected entry to boot is found because I imagine that it is deciding that the windows entry is somehow what is supposed to be used, probably because it didn't find anything and your windows entry is the first? EDIT: Wait your edit makes me believe that the installer is actually returning a failure code and your firmware is moving on to the next boot entry, it just appears to be a restart. Edited May 9, 2019 by apianti Link to comment Share on other sites More sharing options...
Zenith432 Posted May 9, 2019 Share Posted May 9, 2019 (edited) 56 minutes ago, apianti said: EDIT2: And you should be using \EFI\CLOVER\CLOVERX64.efi, the \EFI\BOOT\BOOTX64.efi is provided for the exact reason that windows overwrites it, so that it is the default on the disk when there is no entry for the actual clover location. That only happens to you because you're doing something non-standard... As you may understand, since I don't keep cloverx64.efi around, I'd notice if Windows clobbered my only copy of CloverGUI, which is in \efi\boot\bootx64.efi - and it's never happened. Quote EDIT: Also, what you're describing is a non-compliant implementation of (U)EFI, which is not what I was saying, I was saying that if windows detects that it has been booted from any place other than \EFI\Microsoft\Boot\bootmgfw.efi, it performs startup repair. Well, who told you to do that? I've never booted windows from any place other than \efi\microsoft\boot\bootmgfw.efi, and can't imagine why I would. Does the Windows entry {bootmgr} in your BCD have path to something other than \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI? Maybe that's why your \efi\boot\bootx64.efi is getting clobbered. I'm not confusing bcdedit with anything. This is the output of my "bcdedit /enum all" Spoiler Firmware Boot Manager --------------------- identifier {fwbootmgr} displayorder {b8977f44-5ec4-11e9-8663-806e6f6e6963} {bootmgr} {8d98a361-5ed5-11e9-866d-806e6f6e6963} {bee23572-5f6e-11e9-867d-806e6f6e6963} {bee23573-5f6e-11e9-867d-806e6f6e6963} {bee23574-5f6e-11e9-867d-806e6f6e6963} timeout 1 Windows Boot Manager -------------------- identifier {bootmgr} device partition=\Device\HarddiskVolume1 path \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI description Windows Boot Manager locale en-US inherit {globalsettings} default {current} resumeobject {b1b9296a-4eea-11e8-95da-b81b03b24d21} displayorder {current} toolsdisplayorder {memdiag} timeout 0 Firmware Application (101fffff) ------------------------------- identifier {8d98a361-5ed5-11e9-866d-806e6f6e6963} device partition=Y: description UEFI: Verbatim 8.07, Partition 1 Firmware Application (101fffff) ------------------------------- identifier {b8977f44-5ec4-11e9-8663-806e6f6e6963} device partition=\Device\HarddiskVolume1 path \EFI\BOOT\BOOTX64.EFI description UEFI OS Firmware Application (101fffff) ------------------------------- identifier {bee23572-5f6e-11e9-867d-806e6f6e6963} description Hard Drive Firmware Application (101fffff) ------------------------------- identifier {bee23573-5f6e-11e9-867d-806e6f6e6963} description CD/DVD Drive Firmware Application (101fffff) ------------------------------- identifier {bee23574-5f6e-11e9-867d-806e6f6e6963} description USB Windows Boot Loader ------------------- identifier {current} device partition=C: path \WINDOWS\system32\winload.efi description Windows 10 locale en-US inherit {bootloadersettings} recoverysequence {eaef4b12-2fa8-11e9-a62b-b0ca1dec8101} displaymessageoverride Recovery recoveryenabled Yes isolatedcontext Yes allowedinmemorysettings 0x15000075 osdevice partition=C: systemroot \WINDOWS resumeobject {b1b9296a-4eea-11e8-95da-b81b03b24d21} nx OptOut bootmenupolicy Legacy Windows Boot Loader ------------------- identifier {eaef4b12-2fa8-11e9-a62b-b0ca1dec8101} device ramdisk=[\Device\HarddiskVolume3]\Recovery\WindowsRE\Winre.wim,{eaef4b13-2fa8-11e9-a62b-b0ca1dec8101} path \windows\system32\winload.efi description Windows Recovery Environment locale en-US inherit {bootloadersettings} displaymessage Recovery osdevice ramdisk=[\Device\HarddiskVolume3]\Recovery\WindowsRE\Winre.wim,{eaef4b13-2fa8-11e9-a62b-b0ca1dec8101} systemroot \windows nx OptOut bootmenupolicy Legacy winpe Yes Resume from Hibernate --------------------- identifier {b1b9296a-4eea-11e8-95da-b81b03b24d21} device partition=C: path \WINDOWS\system32\winresume.efi description Windows Resume Application locale en-US inherit {resumeloadersettings} recoverysequence {eaef4b12-2fa8-11e9-a62b-b0ca1dec8101} recoveryenabled Yes isolatedcontext Yes allowedinmemorysettings 0x15000075 filedevice partition=C: filepath \hiberfil.sys bootmenupolicy Legacy debugoptionenabled No Windows Memory Tester --------------------- identifier {memdiag} device partition=\Device\HarddiskVolume1 path \EFI\Microsoft\Boot\memtest.efi description Windows Memory Diagnostic locale en-US inherit {globalsettings} badmemoryaccess Yes EMS Settings ------------ identifier {emssettings} bootems No Debugger Settings ----------------- identifier {dbgsettings} debugtype Serial debugport 1 baudrate 115200 RAM Defects ----------- identifier {badmemory} Global Settings --------------- identifier {globalsettings} inherit {dbgsettings} {emssettings} {badmemory} Boot Loader Settings -------------------- identifier {bootloadersettings} inherit {globalsettings} {hypervisorsettings} Hypervisor Settings ------------------- identifier {hypervisorsettings} hypervisordebugtype Serial hypervisordebugport 1 hypervisorbaudrate 115200 Resume Loader Settings ---------------------- identifier {resumeloadersettings} inherit {globalsettings} Device options -------------- identifier {eaef4b13-2fa8-11e9-a62b-b0ca1dec8101} description Windows Recovery ramdisksdidevice partition=\Device\HarddiskVolume3 ramdisksdipath \Recovery\WindowsRE\boot.sdi The entries "{fwbootmgr}", and all "Firmware Application" are exact copies of the EFI boot order list. If I change the EFI boot order list external to Windows (via bios setup or bcfg), bcdedit then shows me the new content. Are they taken by bcdedit directly from nvram, or copied into \efi\microsoft\boot\bcd during windows boot? I don't know. If I look in the BCD hive in regedit under HKEY_LOCAL_MACHINE, I see the guids for the "Firmware" entries, but don't know where what regedit is showing comes from. It could be a copy stored in the BCD file. It could be read on-the-fly from nvram. It's not a functional impossibility for Windows to read and modify nvram. Edited May 9, 2019 by Zenith432 Link to comment Share on other sites More sharing options...
apianti Posted May 9, 2019 Share Posted May 9, 2019 (edited) No, I'm not doing anything non standard, I know how it works. The reason it is not overwriting \EFI\BOOT\BOOTX64.efi is because of the firmware application entries present in the BCD, bcdedit only reads from the BCD for entries. So those entries were either created by you, some other application, or you already had them set when you initially installed windows and bcdboot when initializing a new BCD adds them. I am on the lastest version of windows 10 through the developer preview channel. And this is the output of my bcdedit: Spoiler C:\WINDOWS\system32>bcdedit /enum all Firmware Boot Manager --------------------- identifier {fwbootmgr} displayorder {bootmgr} timeout 1 Windows Boot Manager -------------------- identifier {bootmgr} device partition=\Device\HarddiskVolume2 path \EFI\Microsoft\Boot\bootmgfw.efi description Windows Boot Manager locale en-US inherit {globalsettings} default {current} resumeobject {41f2a634-4ded-11e8-8371-f56bc31a9418} displayorder {current} toolsdisplayorder {memdiag} timeout 0 Windows Boot Loader ------------------- identifier {current} device partition=C: path \WINDOWS\system32\winload.efi description Windows 10 locale en-US inherit {bootloadersettings} recoverysequence {41f2a636-4ded-11e8-8371-f56bc31a9418} displaymessageoverride Recovery recoveryenabled Yes isolatedcontext Yes allowedinmemorysettings 0x15000075 osdevice partition=C: systemroot \WINDOWS resumeobject {41f2a634-4ded-11e8-8371-f56bc31a9418} nx OptIn bootmenupolicy Standard Windows Boot Loader ------------------- identifier {41f2a636-4ded-11e8-8371-f56bc31a9418} device ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{41f2a637-4ded-11e8-8371-f56bc31a9418} path \windows\system32\winload.efi description Windows Recovery Environment locale en-US inherit {bootloadersettings} displaymessage Recovery osdevice ramdisk=[\Device\HarddiskVolume5]\Recovery\WindowsRE\Winre.wim,{41f2a637-4ded-11e8-8371-f56bc31a9418} systemroot \windows nx OptIn bootmenupolicy Standard winpe Yes Windows Boot Loader ------------------- identifier {7d97a531-547d-11e5-a131-f9d2080e85a8} device ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{7d97a532-547d-11e5-a131-f9d2080e85a8} path \windows\system32\winload.efi description Windows Recovery Environment locale en-US inherit {bootloadersettings} displaymessage Recovery osdevice ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{7d97a532-547d-11e5-a131-f9d2080e85a8} systemroot \windows nx OptIn bootmenupolicy Standard winpe Yes Resume from Hibernate --------------------- identifier {41f2a634-4ded-11e8-8371-f56bc31a9418} device partition=C: path \WINDOWS\system32\winresume.efi description Windows Resume Application locale en-US inherit {resumeloadersettings} recoverysequence {41f2a636-4ded-11e8-8371-f56bc31a9418} recoveryenabled Yes isolatedcontext Yes allowedinmemorysettings 0x15000075 filedevice partition=C: filepath \hiberfil.sys bootmenupolicy Standard debugoptionenabled No Windows Memory Tester --------------------- identifier {memdiag} device partition=\Device\HarddiskVolume2 path \EFI\Microsoft\Boot\memtest.efi description Windows Memory Diagnostic locale en-US inherit {globalsettings} badmemoryaccess Yes EMS Settings ------------ identifier {emssettings} bootems No Debugger Settings ----------------- identifier {dbgsettings} debugtype Serial debugport 1 baudrate 115200 RAM Defects ----------- identifier {badmemory} Global Settings --------------- identifier {globalsettings} inherit {dbgsettings} {emssettings} {badmemory} Boot Loader Settings -------------------- identifier {bootloadersettings} inherit {globalsettings} {hypervisorsettings} Hypervisor Settings ------------------- identifier {hypervisorsettings} hypervisordebugtype Serial hypervisordebugport 1 hypervisorbaudrate 115200 Resume Loader Settings ---------------------- identifier {resumeloadersettings} inherit {globalsettings} Device options -------------- identifier {41f2a637-4ded-11e8-8371-f56bc31a9418} description Windows Recovery ramdisksdidevice partition=\Device\HarddiskVolume5 ramdisksdipath \Recovery\WindowsRE\boot.sdi Device options -------------- identifier {7d97a532-547d-11e5-a131-f9d2080e85a8} description Windows Recovery ramdisksdidevice unknown ramdisksdipath \Recovery\WindowsRE\boot.sdi Notice no firmware application entries at all? Even though I have windows, clover, and four linux distros all set to boot from my firmware menu, plus the additional ones that show up when a USB is inserted. You say the entries change, but how do you know that they are changing? Are you adding new entries and those entries are then appearing in that output? Why would it be showing boot entries with no application path? You have two USB disks connected when you booted? Neither of which is bootable yet it shows an entry for? EDIT: And I just told you that it is booting from \EFI\BOOT\BOOTX64.efi because I cleared my nvram, I'm not moving the bootmgfw.efi and trying to use it somewhere else. But that's entirely possible to do by changing the BCD, which is allowed by the bcdboot command. EDIT2: To clarify, it does startup repair if the {bootmgr} path is different from the path it is booted, not specifically \EFI\Microsoft\Boot\bootmgfw.efi, that's just the default location. Edited May 9, 2019 by apianti Link to comment Share on other sites More sharing options...
Zenith432 Posted May 10, 2019 Share Posted May 10, 2019 (edited) This has got nothing to do with bcdboot. The displayorder under my {fwbootmgr} was created by Windows automatically, and it's copied from the same boot order list I see in bios setup. The non-Windows "Firmware Application" entries in bcdedit were created automatically. I didn't add them manually. They're an exact duplicate of what I see in bios setup, and the list in bios setup is created from an automatic firmware scan. I just did a simple test - boot into bios setup - change the order of the first two entries - then boot Windows. Then I run bcdedit and I see the displayorder of {fwbootmgr} has changed to be the same as the change I made in bios setup. It's always acted this way, even with previous motherboard. I am also sure that if I add or delete entries to the list in bios setup, it will automatically show up in bcdedit, because this has happened before. Windows version is 10 1809. Some of the firmware entries don't have specific path, but are a "partition", or just general device type ("hard drive"). It is the same in bios setup. It is possible that the reason Windows never clobbers my \efi\boot\bootx64.efi is because there is a firmware entry in bcdedit listing this file. But the firmware added this entry in bios setup from a scan, and it got copied. I never put it into bcdedit. Quote EDIT2: To clarify, it does startup repair if the {bootmgr} path is different from the path it is booted, not specifically \EFI\Microsoft\Boot\bootmgfw.efi, that's just the default location. the {bootmgr} path can never be different from the path Windows is booted. Edit: Well, ok if chain-booted from Clover, or by manually selecing a file in bios setup or running from a shell then I guess it can but that's not what you're describing. In a boot from the EFI boot list, the path to boot is taken from the {bootmgr} entry. Edited May 10, 2019 by Zenith432 Link to comment Share on other sites More sharing options...
Slice Posted May 10, 2019 Share Posted May 10, 2019 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. 1 Link to comment Share on other sites More sharing options...
SoThOr Posted May 10, 2019 Share Posted May 10, 2019 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 Link to comment Share on other sites More sharing options...
apianti Posted May 10, 2019 Share Posted May 10, 2019 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. 1 Link to comment Share on other sites More sharing options...
SoThOr Posted May 10, 2019 Share Posted May 10, 2019 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. Link to comment Share on other sites More sharing options...
apianti Posted May 11, 2019 Share Posted May 11, 2019 (edited) 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 May 11, 2019 by apianti 1 Link to comment Share on other sites More sharing options...
SoThOr Posted May 11, 2019 Share Posted May 11, 2019 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. Link to comment Share on other sites More sharing options...
apianti Posted May 11, 2019 Share Posted May 11, 2019 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. Link to comment Share on other sites More sharing options...
SoThOr Posted May 11, 2019 Share Posted May 11, 2019 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. Link to comment Share on other sites More sharing options...
apianti Posted May 11, 2019 Share Posted May 11, 2019 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. Link to comment Share on other sites More sharing options...
Logician Posted May 11, 2019 Share Posted May 11, 2019 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"? Link to comment Share on other sites More sharing options...
Recommended Posts