I have rEFInd running on two Mac Mini 2018s, both with a Windows and a Mac partition. Everything works fine until the power cord is pulled from the machine (which I assume resets the SMC). After pulling the power, the Mac side will boot into a white screen for a few minutes and when it finally gets to the login page, entering the password freezes the machine. Any idea on what's causing this issue?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you're saying that, after pulling the power cord, rEFInd appears normally but macOS boots to a white screen and ultimately freezes, then that sounds like a macOS issue, not a rEFInd issue, and you should ask about it on a Mac forum.
That said, uncontrolled shutdowns like you describe are best avoided whenever possible; they wreak all manner of havoc with filesystems. In a worst-case scenario, they can result in a filesystem that's so damaged that it's virtually unrecoverable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This only happens with rEFInd installed. Here's a bit more information. I install refind and attempt to boot into my Windows partition as well as my Mac partition. Both work without issues. Restarting and shutting down the machine does not cause any issues either. I'd then shut the machine down and proceed to pull the power cord after everything turns off (it is not an abrupt or uncontrolled shutdown). From there I'd plug the power cord back in and proceed to boot into the Mac partition. Doing this causes the Mac side to boot into a white screen for a few minutes and when it finally gets to the login screen, entering the password causes it to freeze. The Windows side continues to work without any issues.
That being said, I'm not entirely convinced that this is an issue with MacOS because reinstalling rEFInd does resolve the issue until the next time I unplug. Basically every time I unplug, I'd have to reinstall rEFInd to get around the problem. I've also tried wiping the entire drive and starting from scratch, but I still run into this problem. Perhaps the problem is caused by the new T2 chip? I know that the SMC functions are now embedded into the T2 chip now and pulling the power cord on Mac Minis resets the SMC so could that be related to what's causing my issue? Any thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is bizarre. I don't own a computer with Apple's T2 chip, so I have no way of experimenting with this myself. The first thing I'd try, though, is experimenting with the Secure Boot settings:
It's conceivable that this setting is somehow interacting badly with rEFInd under the specific circumstance of the computer having been unplugged. That seems like a long shot, but it's the only idea I have at the moment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your input. I've already tried fiddling around with the Secure Boot setting but it didn't help. Does rEFInd create any logs that I can look at?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After experiencing a problem similar to that reported by the OP (Jeff), I recently spent a fair amount of time trying to troubleshoot this problem. Broadly speaking, the primary symptom is an inability to fully boot into macOS from rEFInd after certain power/SMC-related events on T2 Macs. I've summarized the results below.
Tests and findings:
1) Tests were performed using both the latest binaries from refind-bin-0.11.4.zip as well as hand-built-with-TianoCore/UDK2018 versions using refind-src-0.11.4.tar.gz. Additionally, the problem was originally observed on a machine that was using 0.11.2 binaries.
2) The problem affects all T2 Macs. I have access to multiple MacBook Pro/Air and Mac mini models from 2018, and even one iMac Pro. The problem occurs on all of them, and does not affect the dozen or so non-T2 Macs I've tested.
3) Secure Boot is not a factor here, as rEFInd will not load at all on a T2 Mac unless Secure Boot is set to No Security. I can also confirm that SIP being enabled or disabled has no effect on this problem.
4) For a T2-equipped Mac mini or iMac Pro, sitting unplugged from the mains for several minutes (even following a proper shutdown) will trigger the problem. This doesn't happen with the MacBook Pros/Airs, likely because they have an internal battery. However, holding the power button for several seconds to power off the computer will trigger the issue on any T2 Mac. It doesn't matter what context the Mac is in when it is hard-powered off like this, either; you can be sitting in macOS, Windows, or even in the rEFInd screen itself.
5) The hard-power off or power deprivation event is merely the trigger. The underlying cause here is that on T2 Macs, even when every security feature is disabled (Secure Boot, SIP, FileVault 2, etc.), rEFInd can not find or use a boot loader on the APFS volume called Macintosh HD. There is still a file located at /Volumes/Macintosh HD/System/Library/CoreServices/boot.efi, but rEFInd will not auto-detect it, and if you try to create a manual boot stanza that points to it, selecting that entry will fail with a pile of APFS-related errors (see attached photo).
What does work to boot macOS using rEFInd on these T2 Macs is the Preboot volume in the APFS container. rEFInd happily auto-detects boot.efi on Preboot, even when it's buried inside a GUID-named folder (which it is on these Macs), and the boot passes along to the macOS on the Macintosh HD as expected. It makes perfect sense to me that Preboot is so accessible, because the whole point of the Preboot volume is to make your boot loader readable even on a Mac which has had its Macintosh HD volume encrypted with FileVault 2. Which brings us to...
6) The thing that happens to T2 Macs running rEFInd which have been hard-powered off (or power deprived for several minutes) is that when you subsequently select Boot macOS from Preboot in rEFInd, they boot (eventually) into the special login screen that FileVault 2 uses to unlock your hard disk. My observations of this problem may seem a little different from those of the OP, but I suspect that this is because he is neither using a brightly-colored custom rEFInd banner image nor any non-local user accounts. Here's the sequence that I observe:
a) on a T2 Mac that has been rebooted after a triggering power event, I select Boot macOS from Preboot from the menu;
b) the rEFInd menu and the details of my custom banner image immediately disappear, but the screen remains the background color of my custom banner image (in my case, this is a deep blue) and nothing appears to be happening;
c) approximately one minute and 50 seconds pass in this state, sitting at the blank custom-banner-image-colored screen;
d) the screen finally goes black, and the Apple logo and progress bar appear, signaling that we are booting;
e) when the login box appears, it is clear to me that I'm in the FileVault login screen. These machines are authenticating against a directory service, so my login options are set to “Display login window as: Name and password” in the Users & Groups prefpane, and thus I expect to see both username and password entry boxes here. Instead, I only see the username of the local Admin account and a password entry box (see attached photo). If my computer were only using local accounts and set at the default “Display login window as: List of users” setting, I might not have noticed the difference between this and a normal login screen.
f.1) if I type in Admin's password, it is accepted, but the screen then freezes solid. No mouse, no keyboard, no motion of any kind. This matches part of OP's description of his problem (my guess is that this FileVault 2 login box takes the password and tries to pass it off to the mechanism that unlocks the encrypted disk, which fails hard because the disk is not in fact encrypted).
f.2) if I do not type in Admin's password, and just let it sit there, after about a minute an additional message appears at the bottom of the screen (see attached photo) "If you're having a problem entering your password, press and hold the power button on your Mac to shut it down. Then press it again to start up in the Recovery OS." For me, this seems a significant clue as to the role that the power button and/or SMC is playing in this issue; more speculation on that later. At this point, if I click the on-screen Restart or Shut Down buttons here, when I boot back into rEFInd and select macOS, I eventually end up right back here. I can do that several times in a loop, if I want to.
g) if, in either of the f.x) scenarios above, I hard-power the machine off by holding the power button for several seconds, and then power it back on, and then again select macOS from the rEFInd menu, I once again see the roughly 2-minute-long blank-blue screen, but this time it will then boot directly into the Reset Password utility in Recovery (see attached photo). I haven't actually gone through with the password reset at this point, though, because here's the best part: if you simply choose Restart or Shut Down from the Apple menu here...
h) the next time you boot into rEFInd and select macOS, everything is back to normal! The screen goes black immediately, the Apple logo comes up, and you boot right into macOS as expected.
The above sequence is 100% repeatable on every T2 Mac I've tried it with. All of my concentrated testing was done with Macs running macOS 10.14.5, although I originally observed it under earlier versions of 10.14 (and maybe even 10.13.6, in the case of the iMac Pro).
Conclusions and coping strategies:
For anyone who is just using rEFInd on a single personal T2-equipped Mac, the good news is that there's no need to reinstall rEFInd or perform any other such heroics to restore normal functionality. When, after a hard-power off or power deprivation event, you start to experience the 2-minute-banner-screen-hang when you select macOS, all you need to do is reboot into Recovery (reboot holding Command-R), and then reboot again. \<rampant speculation>This will reset whatever stupid flag/state/nvram bit is being set by/for the SMC that is causing the problem. \</rampant speculation> However, until you do boot into Recovery (either by using the key combo as noted above, or by hard-powering off again from the FileVault login screen and then powering back on and selecting macOS), you will be stuck in the loop and unable to boot into macOS. Note that you don’t have to actually do anything in while in Recovery — you merely need to boot into it once and then reboot, and you’re golden — until the next time somebody hard-powers off or unplugs your Mac.
For me, supporting several hundred dual-booting lab and classroom machines in public spaces, this is a real doozy. I would be more than happy to perform any additional testing and/or arrange to loan out a 2018 Mac mini if there’s any chance that doing so could help in isolating and fixing the problem.
I think there is a significant difference between the way in which rEFInd interacts with the Preboot loader and the way that Apple’s built-in boot manager does it. At various points in the problem sequence listed above, if you reboot holding the Option key (which brings up Apple’s own built-in boot manager) and choose the Macintosh HD, you can break the loop and boot right into macOS without a hiccup. For example, if you start at the f.2) point in the sequence above, the following loop is infinitely repeatable:
What you're describing is exactly what's happening to the Mac minis in my environment. I've done a fair but of testing myself and have basically come to the same conclusion as you. Fortunately for me, I only have 2 Mac minis with the new T2 chip so my scenario is not nearly as difficult to manage. That being said, this seems like it could be a big issue going forward (since all new Macs will have the T2 chip) but at least we have more data to go off of now. Perhaps @srs5694 could look further into this problem.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I Have the same issue on a MacMini 2018 Core i7 Hexa Core. It only happens with Refind installed.
BTW, this is not necessary to boot in recovery mode to restore normality. Once booting with the "Alt" key pressed and selecting to boot the macosx from the internal boot manager corrects whatever gets wrong and the next boot with refind works again.
Does anyone tracked down the root cause?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Boot ROM code contains the Apple Root CA public key, which is used to verify that the iBoot bootloader is signed by Apple’s private key before allowing it to load.
So basically what I get from that is.. 1. Boot Rom authenticates Apple's iBoot Signature with a built in Apple Root CA public key. Apple's iBoot bootloader is signed by Apple's Private Key. 2. IBoot then authenticates kernel and kernel extension cache signature.
Whats the question then?
Question 1
So according to this boot process Apple authenticates its iBoot bootloader. Is it possible Refind causes a bug in this authentication process? Is it possible the Mac is still checking for the Apple Private key in Refind's Bootloader but it fails to provide it? It still lets Refind boot because the Security Utility Option was set to No Security, but then the Mac OS boot portion of the process sees this fail, causing the Mac OS to prevent a user from logging in, claiming it will require a password reset?
**Question 2 **
If question 1 is not the case, then is it when I unplug the power cable, I am inadvertently removing the T2 kernel cache signature from the boot up process, causing this bug to happen? How do we prevent this?
I have the same issue, I've always just reset to apple and re-installed rEFind, though letting it restart after entering recovery works. Has there been any progress on preventing this issue? I have an iMac Pro.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sadly, this issue was the end of rEFInd in our environment. I ended up homebrewing a solution similar to Twocanoes' Boot Runner, and that solution is also slowly fading away as our Intel Macs age out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Given that APFS and FileVault are joined at the hip, it might be that not triggering APFS issues, possibly what booting via Apple's StartManager does, avoids the issues.
I wonder whether anyone has tested this with RefindPlus as APFS handling items were added there and it should load APFS volumes closer to what StartManager does.
PS: On APFS/FileVault, the Partition Type GUID for their containers are the same. An APFS and FileVault container are apparently largely the same thing ... at least as far as Apple is concerned.
Last edit: dakanji 2024-04-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have rEFInd running on two Mac Mini 2018s, both with a Windows and a Mac partition. Everything works fine until the power cord is pulled from the machine (which I assume resets the SMC). After pulling the power, the Mac side will boot into a white screen for a few minutes and when it finally gets to the login page, entering the password freezes the machine. Any idea on what's causing this issue?
Thanks!
If you're saying that, after pulling the power cord, rEFInd appears normally but macOS boots to a white screen and ultimately freezes, then that sounds like a macOS issue, not a rEFInd issue, and you should ask about it on a Mac forum.
That said, uncontrolled shutdowns like you describe are best avoided whenever possible; they wreak all manner of havoc with filesystems. In a worst-case scenario, they can result in a filesystem that's so damaged that it's virtually unrecoverable.
Hello Roderick,
This only happens with rEFInd installed. Here's a bit more information. I install refind and attempt to boot into my Windows partition as well as my Mac partition. Both work without issues. Restarting and shutting down the machine does not cause any issues either. I'd then shut the machine down and proceed to pull the power cord after everything turns off (it is not an abrupt or uncontrolled shutdown). From there I'd plug the power cord back in and proceed to boot into the Mac partition. Doing this causes the Mac side to boot into a white screen for a few minutes and when it finally gets to the login screen, entering the password causes it to freeze. The Windows side continues to work without any issues.
That being said, I'm not entirely convinced that this is an issue with MacOS because reinstalling rEFInd does resolve the issue until the next time I unplug. Basically every time I unplug, I'd have to reinstall rEFInd to get around the problem. I've also tried wiping the entire drive and starting from scratch, but I still run into this problem. Perhaps the problem is caused by the new T2 chip? I know that the SMC functions are now embedded into the T2 chip now and pulling the power cord on Mac Minis resets the SMC so could that be related to what's causing my issue? Any thoughts?
That is bizarre. I don't own a computer with Apple's T2 chip, so I have no way of experimenting with this myself. The first thing I'd try, though, is experimenting with the Secure Boot settings:
https://support.apple.com/en-us/HT208330
It's conceivable that this setting is somehow interacting badly with rEFInd under the specific circumstance of the computer having been unplugged. That seems like a long shot, but it's the only idea I have at the moment.
Thanks for your input. I've already tried fiddling around with the Secure Boot setting but it didn't help. Does rEFInd create any logs that I can look at?
I have the same issue and already set secure boot off. Any idea?
I have not been able to get around this issue. As far as I know, there isn't a fix available.
After experiencing a problem similar to that reported by the OP (Jeff), I recently spent a fair amount of time trying to troubleshoot this problem. Broadly speaking, the primary symptom is an inability to fully boot into macOS from rEFInd after certain power/SMC-related events on T2 Macs. I've summarized the results below.
Tests and findings:
1) Tests were performed using both the latest binaries from refind-bin-0.11.4.zip as well as hand-built-with-TianoCore/UDK2018 versions using refind-src-0.11.4.tar.gz. Additionally, the problem was originally observed on a machine that was using 0.11.2 binaries.
2) The problem affects all T2 Macs. I have access to multiple MacBook Pro/Air and Mac mini models from 2018, and even one iMac Pro. The problem occurs on all of them, and does not affect the dozen or so non-T2 Macs I've tested.
3) Secure Boot is not a factor here, as rEFInd will not load at all on a T2 Mac unless Secure Boot is set to No Security. I can also confirm that SIP being enabled or disabled has no effect on this problem.
4) For a T2-equipped Mac mini or iMac Pro, sitting unplugged from the mains for several minutes (even following a proper shutdown) will trigger the problem. This doesn't happen with the MacBook Pros/Airs, likely because they have an internal battery. However, holding the power button for several seconds to power off the computer will trigger the issue on any T2 Mac. It doesn't matter what context the Mac is in when it is hard-powered off like this, either; you can be sitting in macOS, Windows, or even in the rEFInd screen itself.
5) The hard-power off or power deprivation event is merely the trigger. The underlying cause here is that on T2 Macs, even when every security feature is disabled (Secure Boot, SIP, FileVault 2, etc.), rEFInd can not find or use a boot loader on the APFS volume called Macintosh HD. There is still a file located at /Volumes/Macintosh HD/System/Library/CoreServices/boot.efi, but rEFInd will not auto-detect it, and if you try to create a manual boot stanza that points to it, selecting that entry will fail with a pile of APFS-related errors (see attached photo).
What does work to boot macOS using rEFInd on these T2 Macs is the Preboot volume in the APFS container. rEFInd happily auto-detects boot.efi on Preboot, even when it's buried inside a GUID-named folder (which it is on these Macs), and the boot passes along to the macOS on the Macintosh HD as expected. It makes perfect sense to me that Preboot is so accessible, because the whole point of the Preboot volume is to make your boot loader readable even on a Mac which has had its Macintosh HD volume encrypted with FileVault 2. Which brings us to...
6) The thing that happens to T2 Macs running rEFInd which have been hard-powered off (or power deprived for several minutes) is that when you subsequently select Boot macOS from Preboot in rEFInd, they boot (eventually) into the special login screen that FileVault 2 uses to unlock your hard disk. My observations of this problem may seem a little different from those of the OP, but I suspect that this is because he is neither using a brightly-colored custom rEFInd banner image nor any non-local user accounts. Here's the sequence that I observe:
a) on a T2 Mac that has been rebooted after a triggering power event, I select Boot macOS from Preboot from the menu;
b) the rEFInd menu and the details of my custom banner image immediately disappear, but the screen remains the background color of my custom banner image (in my case, this is a deep blue) and nothing appears to be happening;
c) approximately one minute and 50 seconds pass in this state, sitting at the blank custom-banner-image-colored screen;
d) the screen finally goes black, and the Apple logo and progress bar appear, signaling that we are booting;
e) when the login box appears, it is clear to me that I'm in the FileVault login screen. These machines are authenticating against a directory service, so my login options are set to “Display login window as: Name and password” in the Users & Groups prefpane, and thus I expect to see both username and password entry boxes here. Instead, I only see the username of the local Admin account and a password entry box (see attached photo). If my computer were only using local accounts and set at the default “Display login window as: List of users” setting, I might not have noticed the difference between this and a normal login screen.
f.1) if I type in Admin's password, it is accepted, but the screen then freezes solid. No mouse, no keyboard, no motion of any kind. This matches part of OP's description of his problem (my guess is that this FileVault 2 login box takes the password and tries to pass it off to the mechanism that unlocks the encrypted disk, which fails hard because the disk is not in fact encrypted).
f.2) if I do not type in Admin's password, and just let it sit there, after about a minute an additional message appears at the bottom of the screen (see attached photo) "If you're having a problem entering your password, press and hold the power button on your Mac to shut it down. Then press it again to start up in the Recovery OS." For me, this seems a significant clue as to the role that the power button and/or SMC is playing in this issue; more speculation on that later. At this point, if I click the on-screen Restart or Shut Down buttons here, when I boot back into rEFInd and select macOS, I eventually end up right back here. I can do that several times in a loop, if I want to.
g) if, in either of the f.x) scenarios above, I hard-power the machine off by holding the power button for several seconds, and then power it back on, and then again select macOS from the rEFInd menu, I once again see the roughly 2-minute-long blank-blue screen, but this time it will then boot directly into the Reset Password utility in Recovery (see attached photo). I haven't actually gone through with the password reset at this point, though, because here's the best part: if you simply choose Restart or Shut Down from the Apple menu here...
h) the next time you boot into rEFInd and select macOS, everything is back to normal! The screen goes black immediately, the Apple logo comes up, and you boot right into macOS as expected.
The above sequence is 100% repeatable on every T2 Mac I've tried it with. All of my concentrated testing was done with Macs running macOS 10.14.5, although I originally observed it under earlier versions of 10.14 (and maybe even 10.13.6, in the case of the iMac Pro).
Conclusions and coping strategies:
For anyone who is just using rEFInd on a single personal T2-equipped Mac, the good news is that there's no need to reinstall rEFInd or perform any other such heroics to restore normal functionality. When, after a hard-power off or power deprivation event, you start to experience the 2-minute-banner-screen-hang when you select macOS, all you need to do is reboot into Recovery (reboot holding Command-R), and then reboot again. \<rampant speculation>This will reset whatever stupid flag/state/nvram bit is being set by/for the SMC that is causing the problem. \</rampant speculation> However, until you do boot into Recovery (either by using the key combo as noted above, or by hard-powering off again from the FileVault login screen and then powering back on and selecting macOS), you will be stuck in the loop and unable to boot into macOS. Note that you don’t have to actually do anything in while in Recovery — you merely need to boot into it once and then reboot, and you’re golden — until the next time somebody hard-powers off or unplugs your Mac.
For me, supporting several hundred dual-booting lab and classroom machines in public spaces, this is a real doozy. I would be more than happy to perform any additional testing and/or arrange to loan out a 2018 Mac mini if there’s any chance that doing so could help in isolating and fixing the problem.
I think there is a significant difference between the way in which rEFInd interacts with the Preboot loader and the way that Apple’s built-in boot manager does it. At various points in the problem sequence listed above, if you reboot holding the Option key (which brings up Apple’s own built-in boot manager) and choose the Macintosh HD, you can break the loop and boot right into macOS without a hiccup. For example, if you start at the f.2) point in the sequence above, the following loop is infinitely repeatable:
Take rEFInd out of the loop, and it quickly changes:
I hope this information is helpful, and I’m sure I’ve left things out, so please ask any questions you may have.
Last edit: The Machead 2019-06-06
What you're describing is exactly what's happening to the Mac minis in my environment. I've done a fair but of testing myself and have basically come to the same conclusion as you. Fortunately for me, I only have 2 Mac minis with the new T2 chip so my scenario is not nearly as difficult to manage. That being said, this seems like it could be a big issue going forward (since all new Macs will have the T2 chip) but at least we have more data to go off of now. Perhaps @srs5694 could look further into this problem.
I Have the same issue on a MacMini 2018 Core i7 Hexa Core. It only happens with Refind installed.
BTW, this is not necessary to boot in recovery mode to restore normality. Once booting with the "Alt" key pressed and selecting to boot the macosx from the internal boot manager corrects whatever gets wrong and the next boot with refind works again.
Does anyone tracked down the root cause?
I am experiencing the same in in my environment. Using 11.4 Refind, 2018 Mac Minis running Mojave 10.14.5.
According to Apple there is an authentication process of the boot loader. I attached link and screenshots below: https://www.apple.com/mac/docs/Apple_T2_Security_Chip_Overview.pdf
The Boot ROM code contains the Apple Root CA public key, which is used to verify that the iBoot bootloader is signed by Apple’s private key before allowing it to load.
So basically what I get from that is.. 1. Boot Rom authenticates Apple's iBoot Signature with a built in Apple Root CA public key. Apple's iBoot bootloader is signed by Apple's Private Key. 2. IBoot then authenticates kernel and kernel extension cache signature.
Whats the question then?
Question 1
So according to this boot process Apple authenticates its iBoot bootloader. Is it possible Refind causes a bug in this authentication process? Is it possible the Mac is still checking for the Apple Private key in Refind's Bootloader but it fails to provide it? It still lets Refind boot because the Security Utility Option was set to No Security, but then the Mac OS boot portion of the process sees this fail, causing the Mac OS to prevent a user from logging in, claiming it will require a password reset?
**Question 2 **
If question 1 is not the case, then is it when I unplug the power cable, I am inadvertently removing the T2 kernel cache signature from the boot up process, causing this bug to happen? How do we prevent this?
Really hoping something can be done about this. We are starting to implement T2 Machines in my workplace. I have also went ahead and shared this problem over at stackexchange here quoting some of the issues described in this post.
https://apple.stackexchange.com/questions/371426/t2-chip-on-2018-mac-mini-causes-booting-mac-os-bug-after-unplugging-power
Last edit: Chrisdahfuh 2019-10-01
I have the same issue, I've always just reset to apple and re-installed rEFind, though letting it restart after entering recovery works. Has there been any progress on preventing this issue? I have an iMac Pro.
Sadly, this issue was the end of rEFInd in our environment. I ended up homebrewing a solution similar to Twocanoes' Boot Runner, and that solution is also slowly fading away as our Intel Macs age out.
Given that APFS and FileVault are joined at the hip, it might be that not triggering APFS issues, possibly what booting via Apple's
StartManagerdoes, avoids the issues.I wonder whether anyone has tested this with RefindPlus as APFS handling items were added there and it should load APFS volumes closer to what StartManager does.
PS: On APFS/FileVault, the Partition Type GUID for their containers are the same. An APFS and FileVault container are apparently largely the same thing ... at least as far as Apple is concerned.
Last edit: dakanji 2024-04-28