dakanji/Dayo is trying to point you to the "Reducing Startup Delays" section of the "The rEFInd Boot Manager: Using rEFInd" page at rodsbooks website.
I didn't realize that rEFInd has an ARM build and that Surface Pro 11 uses an ARM CPU. I think RefindPlus is for Intel only so you can't use that.
That log seems to show that everything is working. Can you get a log for when it doesn't work? I'd have to look at the source code to figure out what options might help. Maybe RefindPlus will have different behavior? It's logs might have more info as well. I think you can replace just the efi file.
Read the config documentation. Is there an option to change the default boot using the config file? If so, then I suppose you could create a command to do the modification.
You can google "VolumeIconUtil" . It might be able to find issues with .VolumeIcon.icns files.
I don't know Windows. Can you run gdisk in a terminal window as Administrator?
The boot restore process is doing legacy/BIOS boot restore, so its not going to affect the EFI boot settings. You have to change EFI boot settings to make it boot legacy BIOS boot by default (select the Windows startup option in Startup Disk preferences panel or hold option key at boot to enter the Startup Manager EFI app, select the Windows option, hold control key and press enter, or use the bless command). Doing any of those three will set the EFI boot nvram variable to the Boot Camp EFI program...
I'm using 10.4.11 on a PowerPC Mac but it should be the same as an Intel Mac. Here's the output when I paste the text (I removed the tabs to be safe): JoeG5:~ joevt$ echo $BASH_VERSION 2.05b.0(1)-release JoeG5:~ joevt$ testit () { > if perl -ne 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then > echo match > else > echo nomatch > fi > } JoeG5:~ joevt$ FirstCmdlineOption=vmlinuz ; testit match JoeG5:~ joevt$ FirstCmdlineOption=bzImage ; testit match JoeG5:~ joevt$ FirstCmdlineOption=kernel...
I'm using 10.4.11 on a PowerPC Mac but it should be the same as an Intel Mac. Here's the output when I paste the text (I removed the tabs to be safe): JoeG5:~ joevt$ echo $BASH_VERSION 2.05b.0(1)-release JoeG5:~ joevt$ testit () { > if perl -ne 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then > echo match > else > echo nomatch > fi > } JoeG5:~ joevt$ FirstCmdlineOption=vmlinuz ; testit match JoeG5:~ joevt$ FirstCmdlineOption=bzImage ; testit match JoeG5:~ joevt$ FirstCmdlineOption=kernel...
The fdisk output in your Boot Info says the EFI partition is marked as the active partition. That seems strange but it might work. xxd the PBR of sda1 to see if it has boot code (before and after you repair boot to see how things get modified). From the output of od, it looks like it does have boot code. xxd output will make it more clear. Also do xxd for the mbr as well. dd if=/dev/sda count=1 | xxd dd if=/dev/sda1 count=1 | xxd dd if=/dev/sda3 count=1 | xxd Normally I would expect the boot code...
Maybe you can show me how you are running it through bash. In my tests, I just copy and paste the text into a Terminal.app window.
I don't know if you can boot legacy BIOS using USB on a 2008 Mac. I would stick with a CD to be sure. Legacy BIOS boot for old Macs is usually limited to internal disks and built-in CD/DVD. BootCamp Assistant.app from a version of macOS that supports your Mac will instruct you to make a CD or USB or something, depending on what that Mac supports.
Isn't sda1 partition 1? I think sda is the entire disk which has the MBR? I would use xxd instead of od to view hex. All those control character names are distracting. parted says sda1 has the boot flag. Does that mean it's the MBR's active partition? The fdisk command should be able to show the partition table of the MBR including which partition is active. sda3 doesn't seem to have any boot code since it's all nul characters. What is the contents of sda1 (list of files)? I think it's just the EFI...
Does the MBR have boot code? This is block 0 of the disk. Is the Linux partition marked as active in the MBR? Does the PBR have boot code? This is block 0 of the partition that is marked active in the MBR. You may need to use the Linux CD to setup legacy boot. Basically, the PBR needs boot code that knows how to load and run legacy GRUB.
Correction: To work in Mac OS X 10.4.11 or 10.5.8, replace -nE with -ne. I have no idea how you got those errors. It's a bash script that uses perl so no reason to try it in perl. Just copy and paste it into Terminal.app. In Mac OS X 10.4.11, perl -v says I have v5.8.6
I haven't looked at the script, but I suspect you want to replace line 1397 with the line I provided. Then you may wish to search for any other occurrances of =~ to see if they also need to be changed. But before doing that, test the replacement to make sure it works with your shell version. testit () { if perl -nE 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then echo match else echo nomatch fi } FirstCmdlineOption=vmlinuz ; testit FirstCmdlineOption=bzImage ; testit FirstCmdlineOption=kernel...
Maybe use perl? if perl -nE 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then
Maybe use perl? if perl -nE 'exit !(/vmlinuz|bzImage|kernel/)' <<< "$FirstCmdlineOption"; then
I think bash in Mac OS X 10.4.11 doesn't like =~ (vmlinuz|bzImage|kernel) You'll need a different comparison method there.
What OS and OS version and shell version are you using? $SHELL --version
Couldn't the LoaderDevicePartUUID variable be marked as volatile instead of non-volatile so it isn't written to NVRAM?
For CHAR8 *Header the simplest check is probably: (*(UINT32 *)Header == FAT_ARCH) For CHAR8 Header[512] the simplest check is probably: (*(UINT32 *)&Header == FAT_ARCH) I believe the proposed check works for either case but is not as easy to read: (*(UINT32 *)&Header[0] == FAT_ARCH)
You need to change the source code to do that.
Install macOS to an external drive and troubleshoot the fusion drive from there.
How much free space does each of your EFI partitions have? I think RefindPlus uses png which takes much less space than bmp.
Did you press Escape in rEFInd to do a rescan? I'm not sure where to go from here. You could try replacing the rEFInd executable with RefindPlus debug version. RefindPlus should work with your current rEFInd config file. You can then enable logging and see what file systems it's detecting or ignoring.
There's documentation at https://www.rodsbooks.com/refind/using.html It says Ordinarily, rEFInd displays tags for OSes it finds on internal hard disks, external hard disks (including USB flash drives, CF disks, and so on), and optical discs. Sometimes, though, the firmware hasn't had time to fully examine these devices by the time rEFInd starts; or you might only insert or plug in the media after rEFInd appears. In these cases, you can press the Esc or Backspace (Delete on Macs) key to have rEFInd...
that's right, my screen is 3440x1440 CSM is active in my BIOS the display mode that the screen presents is 1,024x768 consequently it is the same that appears as the largest supported by rEFInd Where can I find rEFInd Plus? and the same as conventional rEFInd? What if we change my source code to force resolution, in this case disable resolution detection and force it to display in the desired resolution. what do you think? I have the source code and the development kit assembled on my machine I think...
My refind appears with the screen stretched when using my ulrtawid monitor (Odsey G5). I already tried manually configuring nothing else What is the native resolution of the display? 3,440 x 1,440? Check the display's onscreen menu to see what mode it thinks it is receiving. Check the display's onscreen menu to see if it has an option to not stretch lower aspect ratio modes. What PC and GPU are you using? Do you have CSM disabled in BIOS? Does the rEFInd log show a list of supported resolutions?...
Try one of the options at https://mrmacintosh.com/how-to-remove-mac-firmware-password-new-way-if-you-have-a-2018-2020-t2-mac/
Maybe try RefindPlus to see if it behaves better. It has an option for changing the background color. You should be able to temporarily just replace the refind.efi with the refindplus.efi. You might need to make some tweaks to the refind.conf file. https://github.com/dakanji/RefindPlus
If your firmware doesn't have the UEFI USB driver, then you need to build it. On a Mac I would use an existing edk2 build environment such as one setup for building OpenCore, Clover, rEFIndPlus, or rEFInd. You would have to learn about building stuff in edk2 and what commands would best build just the bits you want. I have a small set of UEFI projects at https://github.com/joevt/joevtApps Then you have to load the driver somehow. rEFInd can load drivers but it might not be early enough. This will...
rEFInd can probably work with any serial console device with some setup but there needs to be a UEFI driver for the serial device. There are UEFI serial drivers for PCI serial devices. https://github.com/acidanthera/bugtracker/issues/1954#issuecomment-1042871406 I haven't tried the rEFInd text menu with serial console but I don't see why it couln't work. I don't know if there are any UEFI serial drivers for USB serial devices. Actually, I found this one which might work (but I haven't looked at it):...
I usually use Driver Genius to keep my Windows drivers up to date after installing BootCamp drivers. BootCamp drivers are mainly useful for supporting the features of Apple keyboards and displays. I don't use the BootCamp Control Panel to change the startup device - instead, I'll just hold option key during boot if I need to boot something different.
I guess MBP 2010 is not new enough for UEFI Windows boot so you have to use BIOS (legacy) Windows boot. USB might not be known to legacy boot. You didn't use BootCamp Assistant from the latest version of macOS that is supported by your MBP? That would have all the istructions for doing the Windows install. It will convert your internal disk to GPT/MBR hybrid to allow BIOS (legacy) boot. There may be ways to do UEFI Windows install/boot (maybe using OpenCore) but that might not be the safest or most...
Burn Windows to a DVD?
Any EFI computer can have a EFI Shell installed. It is the EFI Shell that executes the commands in a startup.nsh script. Some PCs have EFI Shell built into their firmware. I've never tried reset –c -fwui on a Mac before. It probably doesn't do anything. I've already provided links to information on how to boot directly to Startup Manager. Just save to nvram Boot variables the EFI path of the Startup Manager app. Of course, the Startup Manager app only exists in EFI firmware of Macs.
I don't think emulating keys is a thing for EFI boot. All you can do is modify nvram variables (the BootOrder and Boot#### and BootNext EFI nvram varibales) For the EFI path to use in the Boot#### nvram variable: you have to figure out what firmware volume the Startup Manager is in (probably the same one used by the bless command for setting legacy BIOS Boot Camp boot - but I don't know if that code applies for newer Macs that don't support legacy BIOS Boot Camp boot - the newer Macs don't have a...
I don't think macOS ever boots directly to the Startup Manager. The Startup Manager doesn't appear unless the user holds the Option key at startup. https://support.apple.com/en-ca/guide/mac-help/mchlp1034/mac https://support.apple.com/en-us/HT201255 Maybe check this thread: https://forums.macrumors.com/threads/updating-a-mac-pro-s-cpu-microcode.2114187/post-28897865
Macs don't have a UEFI BIOS user interface. You can use the bless command to change the default or next UEFI booter app. The booter app might be boot.efi for macOS, or it might be rEFInd or RefindPlus or OpenCore or grub which let you choose any booters that they find or know about. Before the UEFI booter app loads, you can hold the option key to get into the Startup Manager which just lets you choose what to boot next (and optionally change the default boot) similar to rEFInd or RefindPlus or OpenCore....
The second EFI partition doesn't contain anything interesting - except I wonder what's in the bootlog and the Trashes folder? It's a very small bootlog (141 bytes). You can maybe view it's contents like this: cat "/Volumes/EFI 1/BOOTLOG" In the first EFI partition, you can just delete the BOOT and Ubuntu folders. They all have the same date so they're all very likely related. Plus, you have no other OS on your iMac so they are not required. I don't think we need to look at the output of the find...
diskutil list shows no linux partitions on your two disks, therefore there's no reason to keep the linux boot loader in the EFI partition. Next thing to check is the contents of the EFI partitions. The following will mount the partitions, open them in the Finder, and list their contents in Terminal.app. sudo diskutil mount /dev/disk0s1 sudo diskutil mount /dev/disk1s1 open /Volumes/EFI* find /Volumes/EFI* -exec stat -f "%9z %T %R" {} \; At a minimum, you can just move the bootx64.efi file from the...
About the keyboard - I know my Power Mac G5 doesn't accept keys from a USB 2.0 keyboard. It has to be a USB 1.1 keyboard. I don't think your newer iMac should have that problem though. About boot stuff: EFI Boot is where the Linux booter is located (on a EFI partition). Maybe just leave it? Linux itself may be on a partition that is not mounted by macOS. The Startup Disk preferences panel does not list Linux or EFI partitions. Just macOS and Windows. rEFInd or RefindPlus can list most things. View...
Does your iMac have a wired Apple USB keyboard? When you hear the boot chime, hold down the option key and don't let go until you see the boot menu. One of the options should be macOS, unless it's been erased. You could try booting the iMac into target disk mode, then use the MacBook to examine the contents of the iMac's drive. https://support.apple.com/en-ca/guide/mac-help/mchlp1443/mac In either case, you need a keyboard that allows the boot keys to work. What model iMac and MacBook do you hav...
Where's the dosdude apfs patch? It should be in the EFI partition. I moved mine to a seperate HFS+ partition like in the picture. Then I bless it like this in macOS: sudo bless --folder /Volumes/Catalina\ Boot/macOSCatalinaPatcher --file /Volumes/Catalina\ Boot/macOSCatalinaPatcher/ShellX64.efi --setBoot --label "Catalina" This way it will also have the icon and label of my choosing instead of the default icon and "EFI Boot" label.
I suppose it might be interesting to get a dd of the gpt. sudo dd if=/dev/disk0 count=6 > disk0mbrgpt.bin sudo dd if=/dev/disk0 skip=1 count=1 > disk0gptheader.bin sudo dd if=/dev/disk0 skip=2 count=4 > disk0gpttable.bin sudo dd if=/dev/disk0 skip=1 count=5 > disk0gpt.bin xxd -c 128 -e -g 8 disk1gpttable.bin diskutil info -all | grep -i "Partition UUID" You should be able to look at the result to see if there is a third partition. Usually a GPT partition should not include entries for free space....
It looks like free space in the gpt output. I don't think gdisk lists free space, so something weird is happening. See example of free space below. You could try iPartition.app. joevt@Joes-Mac-Pro ~ % sudo gpt -r show /dev/disk1 gpt show: /dev/disk1: Suspicious MBR at sector 0 start size index contents 0 1 MBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B 409640 209977344 210386984 78125000 4 GPT part - 48465300-0000-11AA-AA11-00306543ECAC...
Your RefindPlus is blocking writes to NVRAM from Windows (for certificates). I don't think this is necesary for newer Macs like your 2015 MacBook Pro but I guess it shouldn't cause a problem and may save some wear and tear on the NVRAM. I don't think this blocking is helping RefindPlus to get Windows to boot but I'm not sure. Well, maybe your MacBook Pro isn't so new - it has EFI 1.1 but is able to boot Windows with UEFI? Do the Legacy items work in RefindPlus? Do your disks have hybrid GPT/MBR with...
updated my post. The command is ver. Yes, it does appear they want a version 1 shell but it's difficult to say what about a version 1 Shell they are looking for since most commands should work from any Shell. The version 1 EFI Shell is available at https://github.com/tianocore/edk2/blob/UDK2018/EdkShellBinPkg/FullShell/X64/Shell_Full.efi The version 2 UEFI Shell is available at https://github.com/tianocore/edk2/blob/UDK2018/ShellBinPkg/UefiShell/X64/Shell.efi OpenCore has their own Shell called OpenShell...
rEFInd can start cli tools such as gptsync and gdisk so it might be able to do the same for sas2flash. rEFInd doesn't have a method to add arbitrary tools but it should allow adding them as a main loader using the menuentry command in the conf file. For each shell, get the results of the following commands: ver ver -s
rEFInd can start cli tools such as gptsync and gdisk so it might be able to do the same for sas2flash. rEFInd doesn't have a method to add arbitrary tools but it should allow adding them as a main loader using the menuentry command in the conf file. For each shell, get the results of the following commands: vers vers -s
Did you update the config.conf file with info from your refind.conf file - in case there are any custom settings that you wanted to keep? Did you install RefindPlus debug version to EFI folder? Only the debug version produces a log file and log files can only be written to FAT (msdos) formatted partitions such as the EFI partition. Usually the log file is saved to the same EFI partition as RefindPlus. Log files are named by date. Sort by name or date modified to get the latest log. The log for RefindPlus...
So you can still boot Windows if you don't go through rEFInd? Maybe try RefindPlus to see if the behavior is the same and to check its debug log.
It is unclear what you are talking about. Can you rephrase, using longer sentences and less pronouns? Where are sas2flash.efi and lsi_util.efi from? Is the problem that they cannot be run directly from rEFInd? Or is the problem that they cannot be executed using the shell that is included in rEFInd? "it does run and behave normally (shellx64,Shell_Full)" What is "it"? "the last is what is in 0.13.2,,,, doesn't work" What is "last"? What computer are you using? What version of EFI or UEFI does it...
I had installed the ntfs driver from my RefindPlus fork https://github.com/joevt/RefindPlus (a fork of rEFInd) to a Mac mini 2018. I had some NTFS partitions connected. It crashed during boot but the Mac mini 2018 saves a UEFI panic log with info about loaded UEFI images, registers, and stack trace. At the top of the stack was the NTFS driver image. I used the offsets in the stack trace to find where the problem happened. dwarfdump --lookup 0x416D "${DEBUG_BUILD_FOLDER}"/../../filesystems/ntfs/DEBUG/ntfs.dll.dSYM...
How much testing did you do? I did not test it at all, except to have it loaded by RefindPlus.
Right. The XHCI EFI driver would be most useful for booting from 10 Gbps USB devices (since USB 2.0 is limited to 480 Mb/s and FireWire from the display is limited to 400 Mb/s and FireWire from the Mac Pro is limited to 800 Mb/s). But keyboard and mouse are also useful tests of the driver.
Was it a USB 3.x card? Old Mac Pros don't have a EFI driver built-in for XHCI USB controllers. There is source code available (in edk2, Clover, and OpenCore) but some minor changes need to be made to make it compatible with EFI 1.1 instead of just UEFI 2.x. Even with such changes it may require other tweaks to work with the USB stack of EFI 1.1. Once the driver is working, it can be installed to an EFI partition and loaded by the nvram Driver#### mechanism (loads before the Startup Manager), or it...
It should work so there's no reason for us to try? I believe rEFInd just needs to find the booter on the Preboot volume in the APFS container just like any other macOS that's in an APFS container.
I don't know if it's possible to load winload.efi directly. https://askubuntu.com/questions/1324757/how-to-chainload-winload-efi-exe-from-grub2 https://superuser.com/questions/729264/is-it-possible-to-boot-windows-8-1-without-its-own-bootmanager
Neither of those traces mentions winload.efi or a volume named windows-21H1. Is there supposed to be an accent é in the icon file name? os_légacy.png Shouldn't there be a new line after the loader name like this: loader \windows\system32\winload.efi } Basically, the format should follow the format of the examples that are included in the refind.conf file. If that's not what your actual boot entry looks like, then you should post a copy of the boot entry, or attach the entire refind.conf file.
What's wrong with the boot\vmlinuz-5.13-x86_64 option that rEFInd auto detects? Or do you mean there's nothing wrong with auto-detect; you just want to recreate the option without auto-detect? Can you show the custom menu stanza in your config? The config file has a couple examples: # A sample entry for a Linux 3.13 kernel with EFI boot stub support # on a partition with a GUID of 904404F8-B481-440C-A1E3-11A5A954E601. # This entry includes Linux-specific boot options and specification # of an initial...
I don't think there's anyway to fix this. There is https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf but I don't know if it's enough info to make your own utility. There may be third party utilities but I have no experience with them and I don't know if they can be trusted.
disk5s2 seems to have the correct partition type for disk5s2 so there's nothing GPT fdisk can do for you here. What info is there about disk6? Need full output from diskutil list and diskutil apfs list What does Disk Utility.app -> First Aid say about disk5s2 partition? Select "Show All Devices" in the View menu. Select Container disk6, then click First Aid.
I think we're talking symantics here. Being out of sync implies there's a way to make it in sync so that it will work. But it will always fail. It's not syncing that is required here. It's more like filtering (removing the option that won't work in the case of Big Sur and later, or is redundant in the case of Catalina and earlier). I agree it's a moot point (but maybe there's a case for not doing the filtering for redundant options that can work).
Can you boot BigSur without those two options?
Ok, I read the config.conf info for sync_apfs. Maybe a better name would be group_apfs or consolidate_apfs or filter_apfs because it removes some redundant apfs options or options that might not work. sync_apfs implies that apfs can be out of sync which doesn't make sence for what it does. I don't think sync_apfs and supply_apfs would affect the OP's issue. He did say he tried the Preboot option which is the option that sync_apfs would expose to the user. But maybe some other change in RefindPlus...
He has a Mac mini 2018. Does it require those apfs options?
Try RefindPlus to see if it has the same limitation? Maybe we need a feature to use BootNext method instead of direct StartImage for each scanned EFI option.
You need gdisk_x64.efi in the /EFI/tools folder. You can get it from https://sourceforge.net/projects/gptfdisk/files/gptfdisk/1.0.4/gdisk-binaries/ but it hasn't been updated since then so it will be missing some bug fixes. There might be a bug in rEFInd that may require you to reboot after using gdisk_x64.efi. The bug was fixed in RefindPlus. I don't know if it exists in rEFInd. https://github.com/joevt/RefindPlus/commit/0166aed246f5e11b5b27d5c0f5926ac9fb5124d0
The bug is that it's trying to show a device path at address 0 (null pointer). There probably isn't a device path at address 0. The code should stop trying to interpret a device path when the type/size is weird. It should definitely not try to do anything with a null pointer. But how did that handle 71 get a image device path protocol of null? UEFI Spec v2.8 section 9.2 says it's valid to add a null Loaded Image Device Path Protocol. The Loaded Image Device Path Protocol must be installed onto the...
Obviously a bug in that Shell's version of dh. Use a diferent Shell? Try without -d. Try without -v. Try without -d -v. Maybe they'll work but maybe they won't have all the info to show the problem. Compile your own dh.efi and fix the bug?
BIOS boot on Macs usually only works on the internal hard drive. That is the one that needs partititioning, either with Boot Camp assistant or iPartition.app or gdisk (but the other two might be simpler - they create a Hybrid MBR/GPT add the MBR boot code as well. There's nothing really special in the MBR that can't just be recreated. The partitions point to GPT partitions. The code just loads code from the partition that is marked in tthe MBR as the active partition. The code that lis loaded is...
Windows UEFI is difficult on EFI 1.1 Macs. Probably imposible on EFI 1.1 32 bit Macs. You should be using legacy/BIOS Windows installation. https://everymac.com/mac-answers/windows-on-mac-faq/ Did you use Boot Camp assistant to partition the drive? If you can't use Boot Camp to create the partition then iPartition.app can do it (but you may need to boot macOS from a different drive). Create the partition (Microsoft Basic Data, ExFAT), mark it as Visable in Windows. In Windows Installer you'll choose...
Which edit.efi are you using? The one from rEFIt is FAT (144K) so you couldn't be loading that. There's one from tianocore-edk2-UDK2018/EdkShellBinPkg that is 48416 bytes (not FAT). Maybe edit.efi loads a protocol that makes the edit built-in command work? To be sure, do these commands: 1. cd directory_that_does_not_contains_edit_efi 2. edit to see if the built-in command works. 3. cd directory_that_contains_edit_efi 4. dh -d -v > dh_d_v_beforeloadedit.txt 5. edit.efi to load the edit.efi. Does it...
Regarding fat binaries: they can work on non-apple x86 with enough code to handle them. Or you can split the fat binary into its parts. The FAT binary format is super simple. You could make a script to do it or there's a python script already created for the job https://github.com/snare/efitools but you may want to change the default names of the split files so that the architecture type appears before the .efi extension instead of afterward. I think x86 is the same as ia32. Regarding gdisk: you...
We'll discuss my RefindPlus in the PM. If something related to rEFInd is discovered then we can come back here. One question: did you try a release version? The debug version's stack tracing or leak detection or debug logging could be issues. Regarding rEFInd, did you try gdisk in the shell and check if the devicehandle for the disk containing rEFInd changed? I see in your RefindPlus log that you used gdisk successfully but it was only changing the device handles of a different disk device handle...
Those logs appear to be for RefindPlus. RefindPlus is at https://github.com/dakanji/RefindPlus I did fix one issue with RefindPlus related to gdisk which might affect rEFInd (but I haven't checked) https://github.com/joevt/RefindPlus/commit/0166aed246f5e11b5b27d5c0f5926ac9fb5124d0 Basically, gdisk will invalidate the DeviceHandle of all LoadedImage protocols that were loaded from disk because gdisk causes the DeviceHandle to be disposed and the device gets a new DeviceHandle at a different location...
EFI doesn't run while an OS is running (except some code for nvram and some other stuff in runtime services). Maybe brightness control is an ACPI DSDT/SSDT thing. An EFI boot loader such as Clover or OpenCore that run in EFI can override or add DSDT/SSDT. The brightness control keys could trigger some ACPI event that executes some code in the DSDT/SSDT. Clover and OpenCore are usually used to run macOS on unsupported Macs but I believe at least OpenCore will do DSDT/SSDT modifications for other OSs....
Include the NTFS.efi driver so rEFInd can read files from the Windows 10 instllations (and also their volume names which you can change in Windows). In macOS, copy an icon image, get info on a FAT partition, select the icon in the Get Info window, then paste. This creates a .Volume.icns file in the root directory of the partition. In Windows, copy the icon from the FAT partitition to the root directory of the NTFS partition.
I told you to execute dumpallbootvars. Why did you execute the setbootvar and setdriverorder commands? Don't execute commands until you understand what they do. I added a note to my instructions. zapping the PRAM will clear the Driver* variables. Or you can manually delete them like this: sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:DriverOrder sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Driver0080 sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Driver0081 sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Driver0082...
I told you to execute dumpallbootvars. Why did you execute the setbootvar and setdriverorder commands? Don't execute commands until you understand what they do. I added a note to my instructions. zapping the PRAM will clear the Driver* variables. Or you can manually delete them like this: sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:DriverOrder sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Driver0080 sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Driver0081 sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Driver0082...
I told you to execute dumpallbootvars Why did you execute the setbootvar and setdriverorder commands? Don't execute commands until you understand what they do. I added a note to my instructions. zapping the PRAM will clear the Driver* variables. Or you can manually delete them like this: sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:DriverOrder sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Driver0080 sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Driver0081 sudo nvram -d 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Driver0082...
Use the dumpallbootvars command to check your firmware defined boot options. It will show if a boot-coup occurred.
Yes, I was saying that BootNext could be used for non-firmware defined boot options especially on a Mac where there usually is only one firmware-defined boot option for macOS. This method would exist to use rEFInd to bypass rEFInd for any boot option - firmware defined or not.
Can you post the info for the HP driver? Does the guid of the Hp driver match the NTFS driver that rEFInd includes? You can pipe output from the EFI command to a text file on an EFI partition using command > commandoutput.txt. Or you can create a .nsh script with a set of commands to gather info about your EFI environment. The script should be UTF-16 Little Endian (or UCS-2LE to be more precise). The first two bytes should be two bytes for the UTF-16LE BOM ("\xff\xfe"). Run the script when you make...
I wonder if the log is missing info (if log lines are cached and not flushed after every line)? In that case it would be useful to have the log output to the display. A key to toggle this feature would be useful since outputting to the display would not look pretty. Might be cool to have a feature where the log goes to one display while the main UI remains on the main display.
What's the URL for the theme? Is the theme missing image files for the missing buttons? Compare the images between the theme and rEFInd.
Maybe installation USB only works when Windows is not installed. Maybe if you remove the disk containing Windows, then USB will work. Can you burn a Windows installation DVD? The issue is that old Macs use legacy BIOS to boot Windows instead of UEFI. Legacy BIOS boot is limited on old Macs.
macOS usually only ever has one item in the BootOrder list. Maybe rEFInd could have an option to boot an item using the BootNext method? This would be selectable in the same way that you can choose to boot macOS in single user mode (press one of F2, Tab, Insert, + to get to the sub menu).
Ok, so you're always booting Windows using UEFI. If you boot it without rEFInd then you get audio. There are three ways to skip rEFInd: 1) use Startup Manager (hold the Option Key at boot and select Windows). 2) use Startup Disk system preferences panel in macOS to select Windows. 3) use bless to set Windows as the default or next boot. Which methods do you use? If you boot it from rEFInd then you get no audio. That's strange. Your using a Mac so there's no firmware-defined boot loader. I suppose...
So you're booting Windows in legacy BIOS mode and audio works. But if you boot using Windows in UEFI mode, audio doesn't work? Or are you talking about a different OS? You can use the System Information app in Windows to verify the BIOS Mode (in System Summary at the top). It also has a Sound Device section for listing audio devices. There should be an audio device for the motherboard and each GPU. HDMI audio is provided by the GPU audio device. What GPU is being used for the HDMI display while booted...
On macOS, the EFI partition is usually labeled EFI. I wouldn't use a label for the EFI partition anyway since all the EFI partitions usually have the same name and it wouldn't look like an EFI partition if it was renamed. EFI partitions usually exist only on GPT formatted disks. Each GPT partition has a partition UUID. In macOS, diskutil info disk0s1 will get the UUID for the first partition of the first disk which is usually an EFI partition. It might be nice for rEFInd to be able to use Volume...
gdisk You can install gdisk in macOS. Go to http://www.rodsbooks.com/gdisk/download.html Or use these macOS commands: sudo gpt -r show -l /dev/disk0 sudo gpt -r show /dev/disk0 diskutil list /dev/disk0 for thedisk in /dev/disk0s*; do echo ${thedisk/\/dev\//}; diskutil info $thedisk | egrep 'Volume Name|UUID|Type|Visible|Offset|Size' ; done efibootmgr In macOS, the dumpallbootvars command from the gfxutil.sh script should be sufficient. https://gist.github.com/joevt/477fe842d16095c2bfd839e2ab4794ff...
gdisk You can install gdisk in macOS. Go to http://www.rodsbooks.com/gdisk/download.html Or use these macOS commands: sudo gpt -r show -l /dev/disk0 sudo gpt -r show /dev/disk0 diskutil list /dev/disk0 for thedisk in /dev/disk0s*; do echo ${thedisk/\/dev\//}; diskutil info $thedisk | egrep 'Volume Name|UUID|Type|Visible|Offset|Size' ; done efibootmgr In macOS, the dumpallbootvars command from the gfxutil.sh script should be sufficient. https://gist.github.com/joevt/477fe842d16095c2bfd839e2ab4794ff...
gdisk You can install gdisk in macOS. Go to http://www.rodsbooks.com/gdisk/download.html Or use these macOS commands: sudo gpt -r show -l /dev/disk0 sudo gpt -r show /dev/disk0 diskutil list /dev/disk0 for thedisk in /dev/disk0s*; do echo ${thedisk/\/dev\//}; diskutil info $thedisk | egrep 'Volume Name|UUID|Type|Visible|Offset|Size' ; done efibootmgr In macOS, the dumpallbootvars command from the gfxutil.sh script should be sufficient. https://gist.github.com/joevt/477fe842d16095c2bfd839e2ab4794ff...
gdisk You can install gdisk in macOS. Go to http://www.rodsbooks.com/gdisk/download.html Or use these macOS commands: sudo gpt -r show -l /dev/disk0 sudo gpt -r show /dev/disk0 diskutil list /dev/disk0 for thedisk in /dev/disk0s*; do echo ${thedisk/\/dev\//}; diskutil info $thedisk | egrep 'Volume Name|UUID|Type|Visible|Offset|Size' ; done efibootmgr In macOS, the dumpallbootvars command from the gfxutil.sh script should be sufficient. https://gist.github.com/joevt/477fe842d16095c2bfd839e2ab4794ff...
gdisk You can install gdisk in macOS. Go to http://www.rodsbooks.com/gdisk/download.html Or the following commands: sudo gpt -r show -l /dev/disk0 sudo gpt -r show /dev/disk0 diskutil list /dev/disk0 for thedisk in /dev/disk0s*; do echo ${thedisk/\/dev\//}; diskutil info $thedisk | egrep 'Volume Name|UUID|Type|Visible|Offset|Size' ; done efibootmgr In macOS, the dumpallbootvars command from the gfxutil.sh script should be sufficient. https://gist.github.com/joevt/477fe842d16095c2bfd839e2ab4794ff...
I agree except for one thing: it might be interesting to add the missing ability to create a manual boot stanza that boots a built-in EFI Shell or a firmware PXE boot option in the case where the option does not exist as a bootnum. The stanza could be a guid or a full EFI device path (it may be simpler to just do guid but rEFInd does have the ability to use a full EFI device path). For example, on a Mac, there is the Apple Startup Manager and there's the Boot Camp loader. Maybe there's a Target Disk...
For the firmware_bootnum option, wouldn't it be useful to have a direct flag that causes rEFInd to parse the boot option (to extract the description, EFI device path, and parameters) and execute the image at the specified EFI device path with the paremeters directly? It would be faster than the current method that uses BootNext and Reset. The current non-direct method has the benefit of bypassing rEFInd (if someone wanted to do that for some reason).