Apple is very good at causing problems for rEFInd with each new OS release. As I haven't yet tried the latest beta, I can't comment on what the latest round of problems are, but at the moment, the best solution is to not run a beta version of macOS.
That said, "it doesn't work" is not very helpful. What precisely does not work? Is rEFInd not appearing any more? (If so, you may have simply encountered a boot coup, which is easily fixed.) Does rEFInd appear but the macOS icon not appear? (If so, I may need to update the list of macOS locations hard-coded in rEFInd -- but knowing where Apple has moved its boot loader would be necessary for me to do this.) Does rEFInd show a macOS icon, but it doesn't launch? (If so, does it show any error messages or other failure symptoms?) Does something else go wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Based on the "update", this sounds like it may be nothing more than a simple boot coup; or possibly Apple has changed the rules for interpreting the boot order and removed the fallback EFI/BOOT/bootx64.efi filename from its standard processing. To better debug this, please try the following:
Boot into a Linux emergency disk, like an Ubuntu installation medium.
Type efibootmgr -v as root (or using sudo) to see the boot order.
Check the BootOrder variable. In a properly functioning system with rEFInd installed, the first BootOrder variable should point to an entry that refers to rEFInd. For instance, if BootOrder is 0000,0080,0081, and if Boot0000 refers to rEFInd, it should work; however, if the rEFInd entry is missing or if the first BootOrder item refers to something other than rEFInd, then you're most likely looking at a boot coup and can fix it as documented on my boot coup page.
If the problem persists, please post more details, including the output of efibootmgr -v and any information on what you've tried. For instance, if you can't create a new rEFInd entry or if it's being ignored.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know much about the EFI boot process -- last time I had boot problems it was the MBR and LILO days. ;-)
My disk configuration is probably relevant. Here it is:
-=> diskutil list
/dev/disk0 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 500.3 GB disk0
1: EFI EFI 314.6 MB disk0s1
2: Apple_APFS Container disk1 342.0 GB disk0s2
3: Microsoft Basic Data BOOTCAMP 158.0 GB disk0s3
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +342.0 GB disk1
Physical Store disk0s2
1: APFS Volume Macintosh HD 295.1 GB disk1s1
2: APFS Volume Preboot 25.1 MB disk1s2
3: APFS Volume Recovery 509.8 MB disk1s3
4: APFS Volume VM 1.1 GB disk1s4
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 GB disk2
1: EFI ElTorito 6.5 MB disk2s1
disk0 is my laptop's HD, with OSX Mojave, Windows 10, and my previously working refind EFI partition on it.
disk1 is a virtual disk on top of disk0 (OSX standard config I think)
disk2 is my refind-flashdrive config'd thumb drive.
Happy to do additional diagnostics if it's helpful for you.
This bug is a nasty one!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've cut some irrelevant stuff from that. The key is the BootOrder line, which identifies two entries as being in the boot order -- Boot0080 is first, and is a Mac boot entry. (It looks like it's on a USB drive -- was this done after you experimented with booting rEFInd from a USB drive?) The second entry is Boot0000, which is the Microsoft Windows boot loader. rEFInd has been removed from the boot list entirely. (Unless Boot0080 is actually the rEFInd USB drive.) The solution, if this is the only problem, is to create a new rEFInd boot entry and move it to the top of the boot order. The easiest way to do this is to re-install rEFInd; however, it can also be done by using efibootmgr in Linux, bless in macOS, or in various other ways. The boot coup documentation covers several ways to recover from a boot coup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed. I think the issue here is that, in addition to a boot coup as usual with a major OSX update, this particular version of OSX either disregards the boot order or resets it upon booting or something similar. Refind-install has no effect. Bless only works if followed by a reboot command, and stops working once OSX boots once, etc.
Consensus seems to be that it's a bug in this beta release of OSX. Looks like a new one is out today -- will try and see if it's fixed and let you know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An OS cannot ignore the BootOrder variable. It's the EFI that uses it to determine which OS to boot, so by the time the OS has control, the BootOrder variable has done its job. That said, once the OS has booted, it can change the BootOrder variable, so your second hypothesis (that the latest macOS is changing the BootOrder variable when it boots) is plausible. If so, the only solution (aside from a bug fix from Apple) would be to leave SIP disabled and write a shutdown script to call bless (or some other tool) to reset rEFInd to be the default just before shutting down (or conceivably at some other time after macOS changes BootOrder).
It's also possible that Apple has released a firmware update with the latest beta. This firmware (EFI) update might ignore BootOrder. Apple's version of EFI has always booted a little strangely, so the possibility that they're going further off the usual EFI path cannot be dismissed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just installed Public Beta 3 and refind behaviour is back to its usual awesome self. A refind-install undid the boot coup as usual and now the mac reliably boots refind from the internal EFI partition as its supposed to. Looks like it was a bug with Public Beta 2 which is now fixed -- that's what we get for running betas!
Thanks for your responsiveness and your great piece of software that the mac eGPU community in particular really depends on!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just wanted to share this small find even tho it might seem like common sense, (and sorry that I am late to this post) This is related to multiboot machines. if you are using Refind as your boot picker and upgraded to OS Mojave (10.13.4) from HFS High Sierra (10.13.6), the boot picker will break and unable to see the APFS container on NVMExpress controller based Macs. Version 11 of reFind states it can see APFS containers but this doesn’t apply to NVMExpress. For a solution, make sure to include the “drivers_x64” folder that comes with your refind download and put it in the EFI/EFI/refind directory. This will allow refind to use the appropriate efi drivers (even tho there is not one named “apfs.efi”) and you will be able to choose the APFS Mac partition on your device. This has been tested on version 10.4 and 11.4 of refind. I have not tested this with beta verions of Mac OS Mojave.
Last edit: Chrisdahfuh 2019-02-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My guess is that what you're seeing isn't a driver problem per se, but an issue with the APFS volume being slow to appear in the EFI's filesystem list. If I'm right, then loading rEFInd's EFI filesystem drivers is just adding enough of a delay to enable the APFS volume to be scanned; or loading the drivers is causing disks to be re-scanned, which kicks the EFI into showing rEFInd the APFS volume. Either way, chances are uncommenting the scan_delay line in refind.conf would do the trick, too. (You can probably set the value to 1 rather than the default of 5.)
As a general rule, I advise against loading EFI filesystem drivers unnecessarily. Doing so slows the process of loading rEFInd and, more importantly, the drivers can cause problems in some cases -- they're all beta quality, and bugs crop up from time to time. In particular, sometimes a driver will cause the system to hang. Thus, I strongly recommend at least trying the scan_delay option before dropping all the drivers in drivers_x64. If scan_delay doesn't work, drop one driver file in drivers_x64, not all of them. I'd suggest using the ext2, ext4, Btrfs, or ReiserFS driver, since these are probably the best tested. The NTFS driver is known to cause problems on some systems, so it should be avoided in most cases. The HFS+ driver might interact weirdly on a Mac, so I'd also avoid it in this situation. (OTOH, rEFInd's HFS+ driver can actually read some volumes that at least some Apple EFIs can't, so it might be useful in a few rare cases.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm working at setting up a triple-boot with Windows 10, Linux Mint 19.1, and Trident which I've posted about here. I struggled through the docs on the rEFInd site, but so much has changed since I last waded into this type of thing, I'm completely lost.
Could someone please take a look at my post and offer advice? Trident was supposed to install rEFInd, but apparently didn't. I don't know why.
A short step-by-step to get from the mess I'm in to a working triple-boot set-up (if that's even possible) would be very much appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I just installed Mojave beta 2 and I've installed again rEFInd and it doesn't work, with beta 1 it goes right. Any suggestion?
Thanks in advance
Same here.
Apple is very good at causing problems for rEFInd with each new OS release. As I haven't yet tried the latest beta, I can't comment on what the latest round of problems are, but at the moment, the best solution is to not run a beta version of macOS.
That said, "it doesn't work" is not very helpful. What precisely does not work? Is rEFInd not appearing any more? (If so, you may have simply encountered a boot coup, which is easily fixed.) Does rEFInd appear but the macOS icon not appear? (If so, I may need to update the list of macOS locations hard-coded in rEFInd -- but knowing where Apple has moved its boot loader would be necessary for me to do this.) Does rEFInd show a macOS icon, but it doesn't launch? (If so, does it show any error messages or other failure symptoms?) Does something else go wrong?
Refind is not appearing, a flashing folder appears.
Looks like a macos bug: http://netkas.org/?p=1472
Based on the "update", this sounds like it may be nothing more than a simple boot coup; or possibly Apple has changed the rules for interpreting the boot order and removed the fallback
EFI/BOOT/bootx64.efifilename from its standard processing. To better debug this, please try the following:efibootmgr -vasroot(or usingsudo) to see the boot order.BootOrdervariable. In a properly functioning system with rEFInd installed, the firstBootOrdervariable should point to an entry that refers to rEFInd. For instance, ifBootOrderis0000,0080,0081, and ifBoot0000refers to rEFInd, it should work; however, if the rEFInd entry is missing or if the firstBootOrderitem refers to something other than rEFInd, then you're most likely looking at a boot coup and can fix it as documented on my boot coup page.efibootmgr -vand any information on what you've tried. For instance, if you can't create a new rEFInd entry or if it's being ignored.Hi Folks:
TL;DR: I found a workaround for this bug:
bless --device /dev/disk2s1 --setBoot --verbose
Don't hold down OPTION at boot time, just let it reboot.
The computer should then boot from the thumb drive, which in my
case discovered my existing refind config and I was good to go.
Confirmed eGPU working in Windows 10 after booting this way. (phew)
Roderick:
I was also able to boot a linux thumb drive and run the diagnostic command you asked for. Here's the output:
I don't know much about the EFI boot process -- last time I had boot problems it was the MBR and LILO days. ;-)
My disk configuration is probably relevant. Here it is:
-=> diskutil list /dev/disk0 (internal): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme 500.3 GB disk0 1: EFI EFI 314.6 MB disk0s1 2: Apple_APFS Container disk1 342.0 GB disk0s2 3: Microsoft Basic Data BOOTCAMP 158.0 GB disk0s3 /dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +342.0 GB disk1 Physical Store disk0s2 1: APFS Volume Macintosh HD 295.1 GB disk1s1 2: APFS Volume Preboot 25.1 MB disk1s2 3: APFS Volume Recovery 509.8 MB disk1s3 4: APFS Volume VM 1.1 GB disk1s4 /dev/disk2 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *2.0 GB disk2 1: EFI ElTorito 6.5 MB disk2s1disk0 is my laptop's HD, with OSX Mojave, Windows 10, and my previously working refind EFI partition on it.
disk1 is a virtual disk on top of disk0 (OSX standard config I think)
disk2 is my refind-flashdrive config'd thumb drive.
Happy to do additional diagnostics if it's helpful for you.
This bug is a nasty one!
Your
efibootmgroutput makes this look like a boot coup:I've cut some irrelevant stuff from that. The key is the
BootOrderline, which identifies two entries as being in the boot order --Boot0080is first, and is a Mac boot entry. (It looks like it's on a USB drive -- was this done after you experimented with booting rEFInd from a USB drive?) The second entry isBoot0000, which is the Microsoft Windows boot loader. rEFInd has been removed from the boot list entirely. (UnlessBoot0080is actually the rEFInd USB drive.) The solution, if this is the only problem, is to create a new rEFInd boot entry and move it to the top of the boot order. The easiest way to do this is to re-install rEFInd; however, it can also be done by usingefibootmgrin Linux,blessin macOS, or in various other ways. The boot coup documentation covers several ways to recover from a boot coup.Indeed. I think the issue here is that, in addition to a boot coup as usual with a major OSX update, this particular version of OSX either disregards the boot order or resets it upon booting or something similar. Refind-install has no effect. Bless only works if followed by a reboot command, and stops working once OSX boots once, etc.
Consensus seems to be that it's a bug in this beta release of OSX. Looks like a new one is out today -- will try and see if it's fixed and let you know.
An OS cannot ignore the
BootOrdervariable. It's the EFI that uses it to determine which OS to boot, so by the time the OS has control, theBootOrdervariable has done its job. That said, once the OS has booted, it can change theBootOrdervariable, so your second hypothesis (that the latest macOS is changing theBootOrdervariable when it boots) is plausible. If so, the only solution (aside from a bug fix from Apple) would be to leave SIP disabled and write a shutdown script to callbless(or some other tool) to reset rEFInd to be the default just before shutting down (or conceivably at some other time after macOS changesBootOrder).It's also possible that Apple has released a firmware update with the latest beta. This firmware (EFI) update might ignore
BootOrder. Apple's version of EFI has always booted a little strangely, so the possibility that they're going further off the usual EFI path cannot be dismissed.Just installed Public Beta 3 and refind behaviour is back to its usual awesome self. A refind-install undid the boot coup as usual and now the mac reliably boots refind from the internal EFI partition as its supposed to. Looks like it was a bug with Public Beta 2 which is now fixed -- that's what we get for running betas!
Thanks for your responsiveness and your great piece of software that the mac eGPU community in particular really depends on!
Thanks for reporting back. It's good to know that this (probably) won't be a problem on the next macOS release!
Just wanted to share this small find even tho it might seem like common sense, (and sorry that I am late to this post) This is related to multiboot machines. if you are using Refind as your boot picker and upgraded to OS Mojave (10.13.4) from HFS High Sierra (10.13.6), the boot picker will break and unable to see the APFS container on NVMExpress controller based Macs. Version 11 of reFind states it can see APFS containers but this doesn’t apply to NVMExpress. For a solution, make sure to include the “drivers_x64” folder that comes with your refind download and put it in the EFI/EFI/refind directory. This will allow refind to use the appropriate efi drivers (even tho there is not one named “apfs.efi”) and you will be able to choose the APFS Mac partition on your device. This has been tested on version 10.4 and 11.4 of refind. I have not tested this with beta verions of Mac OS Mojave.
Last edit: Chrisdahfuh 2019-02-27
My guess is that what you're seeing isn't a driver problem per se, but an issue with the APFS volume being slow to appear in the EFI's filesystem list. If I'm right, then loading rEFInd's EFI filesystem drivers is just adding enough of a delay to enable the APFS volume to be scanned; or loading the drivers is causing disks to be re-scanned, which kicks the EFI into showing rEFInd the APFS volume. Either way, chances are uncommenting the
scan_delayline inrefind.confwould do the trick, too. (You can probably set the value to1rather than the default of5.)As a general rule, I advise against loading EFI filesystem drivers unnecessarily. Doing so slows the process of loading rEFInd and, more importantly, the drivers can cause problems in some cases -- they're all beta quality, and bugs crop up from time to time. In particular, sometimes a driver will cause the system to hang. Thus, I strongly recommend at least trying the
scan_delayoption before dropping all the drivers indrivers_x64. Ifscan_delaydoesn't work, drop one driver file indrivers_x64, not all of them. I'd suggest using the ext2, ext4, Btrfs, or ReiserFS driver, since these are probably the best tested. The NTFS driver is known to cause problems on some systems, so it should be avoided in most cases. The HFS+ driver might interact weirdly on a Mac, so I'd also avoid it in this situation. (OTOH, rEFInd's HFS+ driver can actually read some volumes that at least some Apple EFIs can't, so it might be useful in a few rare cases.)I'm working at setting up a triple-boot with Windows 10, Linux Mint 19.1, and Trident which I've posted about here. I struggled through the docs on the rEFInd site, but so much has changed since I last waded into this type of thing, I'm completely lost.
Could someone please take a look at my post and offer advice? Trident was supposed to install rEFInd, but apparently didn't. I don't know why.
A short step-by-step to get from the mess I'm in to a working triple-boot set-up (if that's even possible) would be very much appreciated.