Jump to content

SoThOr

Members
  • Content Count

    12
  • Joined

  • Last visited

About SoThOr

  • Rank
    InsanelyMac Protégé
  1. SoThOr

    Clover General discussion

    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.
  2. This was spurred on from a discussion in the Clover General thread. Where there was a debate on bcdedit being able create/read/edit (U)EFI Boot entries. I didn't think it appropriate to post all this information there and somebody may want to make use of this and its likely to get lost in that massive thread. Out of curiosity I decided to see if I could create an EFI entry using bcdedit. What can I say I like a challenge. Whilst is not a documented method by Microsoft, as it turns out in a round about way it IS possible to create an EFI entry using bcdedit and these are the steps I went through to add UEFI Shell located on a USB stick to the EFI entries. Third party software is available that can create and edit UEFI entries from Windows with better support and more features. I'm just making this information available in case those options are unavailable. DISCLAIMER - This is not a supported method. Use at your own risk. I recommend backing up your BCD/Firmware variables/settings beforehand. 1) Copy {bootmgr} entry. C:\Windows\System32>bcdedit /copy {bootmgr} /d "UEFI Shell" The entry was successfully copied to {34e8383c-73a7-11e9-9cb0-94de8078a7b5}. 2) Edit the new entry using the new GUID bcdedit generated in the copy step. a) Set the device and path for UEFI shell on my USB stick. bcdedit /set {34e8383d-73a7-11e9-9cb0-94de8078a7b5} device partition=G: bcdedit /set {34e8383d-73a7-11e9-9cb0-94de8078a7b5} path \EFI\SHELL\SHELLX64.efi b) Clean up some of the stuff that was copied from {bootmgr} (optional as far as I can tell, just makes things tidier in bcdedit) 3) Put the new EFI entry first in boot order. (optional) After completing the steps above, here is what "bcdedit /enum firmware" shows: I shutdown my computer and when I turned my computer back on it booted up into UEFI Shell. After exiting the shell my PC went on to boot Windows. Here is the resulting dump using "bcfg boot dump -v" from that shell: You may notice that the shell shows as "Windows Boot Manager" in the bcdedit output. This I believe is because of the "WINDOWS" at the beginning of the option data that bcdedit added to the EFI Boot entry. I also believe this why bcdedit shows my Windows 8 installation as "Firmware Application" because it has no option data. I don't know how to remove this data using bcdedit nor do I know how the option data, that bcdedit adds, will affect other EFI applications. There might be a way to create the EFI entry without copying the Windows entry but if there is I'm unable to find any documentation on how one would do so. If you use the create command then it just puts it in the BCD and I'm unaware of a way to tell it to create it in EFI instead, other than by doing the above.
  3. SoThOr

    Clover General discussion

    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.
  4. SoThOr

    Clover General discussion

    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: 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: After disabling legacy boot: 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.
  5. SoThOr

    Clover General discussion

    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:
  6. SoThOr

    Clover General discussion

    GUI/Hide will be able to do what you want. If it doesn't then have a look at GUI/Custom/Entries.
  7. SoThOr

    Clover General discussion

    Oh sorry. Yes HideEntries has been replaced by custom entries. I thought you were referring to GUI / Hide where you can hide volumes using the VolumeName/DevicePath. Swapped badges, meaning drive icons are bigger than OS icons? If so you may need to make/find a vol_recovery.icns to use for Recovery.
  8. SoThOr

    Clover General discussion

    Some of what HideEntries does you are now able to do with Custom Entries. I think still has its uses though. If you dont want to use HideEntries you can use this in GUI / Custom / Entries: <dict> <key>Type</key> <string>OSXRecovery</string> <key>Hidden</key> <true/> </dict> You could also change the icon here too. Using Image/ImageData and/or DriveImage/DriveImageData. Different themes have different looking icons. Both standard OSX and Recovery will use the icon for the version of OSX they are (os_lion.icns, os_cougar.icns, os_mav.icns etc) but have different Drive icons (vol_internal_hfs.icns and vol_recovery.icns respectively) however they will fall back to using the same icon (vol_internal.icns) if the theme does not have a separate file for them to use.
  9. SoThOr

    Clover General discussion

    The default path for config.plist is "\EFI\CLOVER\config.plist". If you are trying to set up UEFI booting for the first time then it may be a good idea to get CloverEFI (legacy) to work first. That way you separate issues related to configuration and issues related to your UEFI firmware.
  10. SoThOr

    Clover General discussion

    Any chance you could share a boot.log (or preboot.log)? It is difficult to know what the problem is otherwise.
  11. SoThOr

    Clover General discussion

    Okay, I just wasn't sure if it was just an attempt to fix the issue with the wrong Volume icon or not. So was just making sure. You have checked everything out so all is good You are right there isn't much harm in doing it like that. I'm just a bit of a perfectionist and don't want to make any assumptions we don't have to.
  12. SoThOr

    Clover General discussion

    Yes this was due to me separating legacy and uefi loader types. Should be fixed in r2222. @Pene I'm not sure I like r2220. It assumes too much about the case where SystemVersion.plist is not found and com.apple.recovery.boot\boot.efi is found. It might have been the issue I just fixed(r2222) that was the problem? Maybe if we can't find the the SystemVersion.plist we should use the detection code from main.c:StartLoader(...)?(which you wrote right?) I think we would need to pass LOADER_ENTRY instead of REFIT_VOLUME though. That way we don't have to check all the different paths we can just use Entry->LoaderPath as the boot file to scan for version. It would also reduce the number of places we look for OSversion .
×