Hmm, for some odd reason sudo newfs_hfs -v EFI /dev/disk0s1 does not work properly. It reports
Initialized /dev/rdisk0s1 as a 200 MB case-insensitive HFS Plus volume
But diskutil info then reports
Volume Name: Not applicable (no file system)
It's odd newfs_hfs changes the disk special name from disk0s1 to rdisk0s1 as well.. I don't have Linux and was hoping to avoid setting Linux up on a USB stick just to format the ESP with HFS+.
Still, I can install rEFInd to /dev/disk0s1 with --ownhfs
but all diskutil commands refuse to work. diskutil mount, unmount, rename etc. I can however mount using old UNIX style mount methods.
So it seems newfs_hfs is not compatible with diskutil, and diskutil has no formatting commands, only reformat an existing volume with same format. And that also fails with the newfs_hfs formatted ESP.
However, after all of this, rebooting delay is back in force, and rEFInd does not even work from this newfs_hfs formatted ESP.. After a long delay it boots right back into OSX.
To conclude for now, newfs_hfs is bad, at least for ESP. Do not use it. Now I have to figure out how to restore my ESP, since newfs_msdos has the exact same problems. When I enable debug mode in Disk Utility GUI, it shows my broken ESP, Info shows Can be formatted: no. Perhaps they built protections into OS X 10.9, and that's why newfs_hfs only partially works, just enough to break things.
At least I can install rEFInd back to main boot partition and get back to fast boot times, and the broken ESP does not seem to cause any harm. I think I will have to use a Linux repair USB stick to try to fix it, as Apple's newfs_ utils do not work on the ESP.
Hmm, Windows boot is broken again, after I messed up the ESP.. "No bootable devices found" after choosing Windows from the rEFInd boot menu, even though the number of partitions on the HDD is the same.
Last edit: n808 2013-11-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried recovering ESP from Linux SysRescueCD by formatting it to msdos, then dd back the backup I had taken. No errors doing that, but back in OS X, the GPT still shows it as an HFS+ partition type.
Attempts to use Disk Utility to restore the EFI from an image I created from a USB stick's EFI fail with 'disk0s1 busy', both in regular OS X and when booted from the recovery partition.
Then I downloaded gdisk, and from regular OS X, used it to change the ESP's partition type to 'ef00', renamed it EFI, and rebooted. Finally, Disk Utility now shows exactly what it used to and diskutil works as before, e.g. sudo diskutil mount EFI.
But I still cannot boot to Windows. Attempting this results in "No bootable device - insert boot disk and press any key" error. To fix this, Google searches indicate I need to create a Windows rescue disk and let Windows use its Repair, which I did, but Windows Repair was unable to repair anything, and I still cannot reboot to Windows, even though the partition is there, and seemingly perfectly healthy, never touched by these tests.
Finally, problem solved. I had to create a hybrid MBR and add the Windows partition to this with gdisk, following these instructions: http://nerdr.com/tag/fix-bootcamp-partition-not-booting-mac-and-macbook-pro/
From what I read, at least Windows 7 on Macbooks operate in BIOS mode and needs a hybrid MBR to work. I have Windows 8, and I am not sure if I ever had a hybrid MBR and it got destroyed by these exercises. The only MBR gdisk showed was a protective one with only the EFI partition.
I think I will avoid messing with the ESP from now on ... and either live without rEFInd, use it from USB, or disable hibernation.
Last edit: n808 2013-11-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Chances are one or both of two things has happened:
You've accidentally wiped your hybrid MBR (converting it back to a standard protective MBR), in which case creating a new one with gptsync or gdisk should fix the problem; or...
The Windows boot code from the MBR is missing. In this case, you'll need to either restore it from a backup (if you have one) or use those Windows tools to restore the boot loader to the MBR. I know you said you've tried this, but if you've both reverted from a hybrid MBR to a standard protective MBR and lost the MBR's boot code, then you might need to do this in addition to creating a fresh hybrid MBR.
Alternatively, you could try doing an EFI-mode boot of Windows. This is supposed to be very tricky with Windows 7, but much more do-able with Windows 8 -- but even with Windows 8, the ease of doing an EFI-mode boot supposedly varies from one model of Mac to another. I've not followed the specifics, so I can't really offer any more advice on this matter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You replied while I was updating my post. The hybrid MBR must have been wiped. Not sure how, but restoring it with gdisk fixed the problem, without having to use further tools, so the Windows MBR boot code must have been intact, or restored by the Windows Repair tool, which reported failure to fix system, but perhaps it did a partial fix.
Whew, this has been an exercise that I have learned a whole bunch of new topics from. Thanks for your help, Roderick. If you need me to do more tests for future enhancements to rEFInd, I'll be happy to, now that I know how to recover from mishaps.
I might go back to having rEFInd on its own partition, non ESP, and then see if updating the hybrid MBR with the new Windows partition number is enough to make Windows boot after adding this new partition.
EDIT: That's what I ended up doing. Installed rEFInd on its own 1GB partition with the new --ownhfs option. I placed this partition after the OSX partition, which can be resized, and before the Windows partition, which cannot. Then I fired up gdisk, noticed that the hybrid MBR had been wiped, with only the protective MBR left. So OS X Disk Utility wipes the hybrid MBP when changing the GPT, which is reasonable, since then the hybrid MBR is most likely no longer correct. Re-created the hybrid MBR with the new Windows partition number, wrote to disk and re-booted. Now everything works great: hibernation, rEFInd boot choices (I added memtest86 EFI as well), and fast reboots without delay.
Last edit: n808 2013-11-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Roderick, has there been any further progress on the issue? What do you need to continue? And aside from turning off hibernate feature of OS X, what is the best practice to deal with this issue? Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, in my previous post I said I was lacking the time to do further tests, and that I'd try some things as soon as possible. As it turns out, changing countries with a 9000 km distance means that as soon as possible is not as soon as I'd like to.
Long story short: now I have some time and did some tests. I changed my ESP partition to a HFS+ one and install rEFInd on it, and it still doesn't work! I can't make a new HFS+ partition in the current state of my HDD since I would have to delete some other partitions and I don't have free space elsewhere to back them up.
Also, I've read the rest of this topic before posting, and I saw the reports from n808 that seem to show hibernation work, but there are a few things I don't understand! You say that in order to test, you wait for the system to go to sleep, and then resume it. But from your report, I'm not sure you actually wake up from hibernation (although it seems that your computer sets up everything for hibernation, which is normal on OSX : save the RAM to disk and go to normal sleep, if battery runs out during sleep one can wake up from hibernation). It may be different on newer computers, since I now for example that MacBook Air automatically turn off during their sleep after a set period of time, so the next boot is necessarily from hibernation, maybe other newer laptops do the same. Maybe you are aware of that and take it into account in your report, but what tickles me is this:
"At least I am 99% sure it did, as it took a few seconds longer than normal sleep, and /var/vm/sleepimage was freshly created, just as it did when I temporarily removed rEFInd altogether."
You stand that the boot seemed longer but it seems to be the only difference, whereas when booting from hibernation not only is it longer but there is a kind of loading screen with a status bar loading on top of a blurred capture of the screen as it was upon hibernating. Once again, you may be right, especially since I use an "old" MacBook with an "old" OS X version (10.6 on a MacBook 8,1) and things may be different with newer ones, but since I can't reproduce your success (although I did install on a modified ESP, which might change things) I want to make sure all Ts are crossed!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I did some more tests. The issue doesn't seem to be solved yet but I have found a workaround that, if not yet perfect, is enough in my situation and probably will for a majority of users. As I said I was going to in my previous message I reverted my new HFS small partition to a traditional ESP one (thanks to gdisk ;-) and installed rEFInd there, and except from the foreseen sluggishness there was no progress regarding hibernation. So it seems that whatever one does, the use of rEFInd is not compatible with hibernation.
But all this tampering with the ESP partition got me thinking. I remembered that in my first dual boot setup, rEFInd was installed along with a linux system on an external hard drive. I would select it in a kind of chain boot, by holding the ALT key on the startup of the Mac. The boot sequence would then be: Mac boot code -> detection of ALT key -> list of all available boot medium (OS X, CD/DVD, BIOS-booting system e.g. bootcamp, and last but not least alternate EFI bootloaders such as rEFInd) -> choice of rEFInd -> choice of an OS. So I choose the OS X disk as the boot disk in the System Preferences (which I assume should be the same as blessing a certain file, but I don't know which one), rebooted with the ALT key pressed and… nothing. I changed one more time my ESP partition to HFS+, copied rEFInd it on it WITHOUT BLESSING IT, and rebooted with the ALT key pressed. And there it was, the Apple screen allowing one to choose between the OS X setup and rEFInd (called simply "EFI Boot").
I then did tests to confirm everything was acting as I was expecting and it did: I was able to boot any of my usual rEFInd entry by booting while pressing ALT and selecting "EFI Boot", but also to hibernate normally (or rather, to normally resume from hibernation). The pros of this setup are obvious: regaining hibernation. The cons are a longer boot time if you are booting into an alternate system, since you'll have to wait until the Mac boot code scans your available medias and presents you with the "EFI Boot" option. So this isn't a really good solution if you are mainly using another OS as OS X, but if like me you use 0S X 90+% of the time and only boot to other OSs for some specific tasks, it won't be much of a problem.
As a bonus, it got me thinking about the boot sequence on Macs and I did the following test: turn off my computer by hibernating, and then booting while pressing the ALT key. When doing that, the choice for a boot media never shows up, so the only choice is to resume from hibernation. This means that you don't risk booting into another OS that may temper with your hard drive and leave OS X disoriented when finally resuming from hibernation.
Also, the traditional Mac "gong" is not played. Since it is also played when booting after having blessed rEFInd and I doubt it is a function of rEFInd itself, it may indicate things about the boot sequence and help change rEFInd to offer proper hibernate support on Macs (if that is what the author wants to do, of course, which I don't myself consider a priority since the setup I used did the trick). I think that some Apple code is always executed first and checks what media it should boot from, and if it is the default OS X setup, if there is a hibernation state to resume from, in which case it doesn't play the "gong". But if it is not supposed to boot from the OS X partition, a "gong" is played and boot proceeds without any support of hibernation. I also had the idea that this small code never checks for hibernate status at all and leave it to the OS X bootloader but the following test seems to disprove that: if I hibernate my Mac and press the ALT key on reboot, the computer resumes from hibernation without leaving me the choice of a media to boot from, meaning that hibernation is indeed checked for and has a higher priority than choosing to boot from a different media.
So, as I said, I finally found a setup that works for me. The only case it would pose some really noticeable problem is if one often boots on alternate OSs, but in this case it is likely that they would not care as much for hibernation support in OS X, so it seems to me that this issue, although not solved, can be circumvented, thus not requiring any further development of rEFInd in this direction. That being said, if the author is willing to offer full hibernation support on Macs and needs some investigation done, and since you said you don't own a Mac other than a 32-bits Mac mini, I'm willing to help if I can, as a way of thanking you for this amazing tool. But then again, it seems more likely to me that rEFInd is compliant to boot standards and it is Apple which, as often, can't be bothered to comply. So anyway, if you need some tests done or something be sure to let me know :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Very funny, Simon, that you and I were both trying this same thing today. After reading this thread thoroughly, I also decided to follow Roderick's suggestion to just install rEFInd to a separate HFS+ partition using the "--ownhfs device-file" option to target the new partition (partition name retrieved using "diskutil list").
So...
...a little bootup from an Ubuntu 14.04 USB stick
...some gparted action to make me a nice little 200MB partition
...then some boot back into OS X to format the new partition HFS+ (using Disk Utility)
...an install of rEFInd using "install.sh" with the "--ownhfs" option to target my little 200MB HFS+ partition
...a reblessing of the Mac OS X primary startup disk using standard Apple "Startup Disk" in System Preferences (switching back to the primary Mac OS X startup disk instead of the currently selected 200MB rEFInd partition)
...and finally a hold-down of the Option (Alt) key during restart
...gives me what I consider to be a VERY workable solution that keeps my hibernation intact (crucial for maximizing battery life while maintaining my system state throughout the work week/month/quarter). This solution also enables me to readily switch over to Linux or Windows with a simple reboot while holding down Option (Alt) when I need to get my geek or my game on.
Thanks a bunch to all who participated in this thread. And thanks to Roderick for continuing to foster the conversation to help us OS FREEks continue to try out the latest and greatest in the open source arena without sacrificing the top-notch performance of our primary OS X installations :-)
<o>
--
P.S. Full disclosure. After following the above steps, I couldn't boot Windows: "Missing Operating System". I remembered something about rEFIt having Hybrid MBR synching built in, so I did my Option (Alt) boot, picked rEFInd from my 200MB partition, then picked rEFIt that was still on my primary OSX partition that rEFInd recognized, then tried to boot Windows. It didn't work (stayed on the grey screen with the Windows logo until I hard powered down holding down the power button), but when I rebooted back into rEFInd the second time and tried to boot Windows, it booted fine (phew!).
P.P.S. My ability to boot my early 2011 MacBook pro from a Linux Live USB stick was only made possible by booting into the Windows 8 install first, then selecting Linux from the Windows boot menu. Linux got on the Windows 8 boot menu after I ran Wubi from the Live USB stick in Windows. I've never been able to get a Linux USB stick to boot up either through Apple's boot manager, or through rEFIt, rEFInd, or PLOP boot manager. So I was amazed when the Windows 8 bootloader actually enabled me to overcome that long-standing hurdle. Go figure!
Last edit: Eye Em 2014-05-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, if like me you are annoyed by that second partition that you can't do anything with since it's only 300 Mb and you'd also like to avoid having other users tamper with it, here's how to ask OS X not to mount it at startup using fstab (you can mount it manually) : https://discussions.apple.com/thread/4271735?tstart=0
Last edit: Simon Picard 2014-05-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aha! I found the discussion forum. I knew there had to be one!
OK, I've been experiencing this issue on a Macbook Air 4,1. Today I tried 0.8.0 which probably didn't have anything in itself to fix it, but following a new hint on the website (I'm sure it wasn't there last time I looked) I tried the --ownhfs thing; made a small partition after my main OSX one (that was a mini adventure in itself; Disk Utility was being uncooperative, so it was a joint effort between diskutil and gparted on Linux - side-effect I also seem to have made the Mavericks Recovery partition generally visible, possibly because it's not directly after the OSX system partition any more) and got it going...
... and so far, all seems well. rEFInd seems happy to boot Linux and OSX from its own partition, and OSX at least is, I think, hibernating and recovering from there properly. (Linux doesn't seem to want to hibernate at all but I think that's its own problem.)
And then I found this discussion and caught up.
NB: contra some earlier posts I've left it so that the rEFInd partition is 'blessed' and boots by default. If I wanted to alt-boot I'd not bother with rEFInd at all, and just learn to live with the daily affront to one's dignity of having to choose "Windows" at the alt-boot menu to boot Linux. I have after all been doing that for a while already.
So why again was the advice in this thread to leave the main OSX partition 'blessed' normally and alt-boot to get to rEFInd? It doesn't seem to be necessary for me. (Maybe it was a reason involving Windows, which isn't involved here?)
Other issues arising:
I made the rEFInd partition HFS+ without journalling. Also I haven't tried yet, this should make it read-writable from Linux as well. Doesn't seem to stop it booting.
Booting rEFInd from its own partition, it doesn't on its own detect the OSX install; so it just comes up with the Linux boot options. That seems to be similar to a problem others have reported here, so I added the scan_delay 1 and that seems to fix it; although at the cost of [a second and] seeing the text message saying it's delaying flash up. Can we suppress that text please, as it is only a second?
I was also able to boot OSX via rEFInd by adding a manual boot stanza, which had the side effect of making it last on the list instead of first, but worked.
Oh, I also had to configure rEFInd not to scan its own partition for boot entries, to avoid having a refind entry in the refind screen, which I thought was a bit of unnecessary clutter. :-)
Last edit: Rachel Greenham 2014-05-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"So why again was the advice in this thread to leave the main OSX partition 'blessed' normally and alt-boot to get to rEFInd? It doesn't seem to be necessary for me. (Maybe it was a reason involving Windows, which isn't involved here?)"
It looks as though different versions of OS X (or possibly hardware) behave differently when it comes to hibernation, since both you and n808 report getting it to work by installing rEFInd to its own HFS partition, and you both reported using a newer version as me (I'm running 10.6). So it's good that the answers for users using different system versions are there :)
As for using rEFInd after a ALT-key boot, it is necessary if you are booting Linux through EFI instead of BIOS, in which case it isn't listed in the boot choices (at least in my current setup, although I assume it could be done).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"As for using rEFInd after a ALT-key boot, it is necessary if you are booting Linux through EFI instead of BIOS, in which case it isn't listed in the boot choices (at least in my current setup, although I assume it could be done)."
Yeah; while I boot Linux by EFI stubloader normally, I do leave grub installed as well as backup, as once or twice during Trusty's alpha/beta stages they put out a kernel that didn't work as an EFI stubloader. A side-effect of that is it appearing as "Windows" in alt-boot, and it means I get both an Ubuntu icon and a Tux icon for the grub boot in rEFInd. I just set "max_tags 2" to limit it to two boot icons on the main screen (Mac and first Ubuntu kernel) so others including grub are hidden but still reachable at need.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This version suppresses those messages on startup when the scan_delay is 1. Of course, the drawback is that then you see nothing happen for longer.
Oh, I also had to configure rEFInd not to scan its own partition for boot entries, to avoid having a refind entry in the refind screen, which I thought was a bit of unnecessary clutter. :-)
That should be unnecessary, since rEFInd includes code to exclude its own directory from scanning. Are you sure you don't have two rEFInd installations -- say, one on the ESP and one on the OS X root (/) partition? You could figure this out by installing a new version (like the one pointed to above) and then comparing the version information in the "About rEFInd" screen in the version that launches and the version you get when you launch rEFInd itself. You'll also see different path information when you highlight rEFInd in the two rEFInds if my guess is correct.
If you really have just one rEFInd installation, then there's a bug in the self-exclusion code (or a bug in your EFI that's preventing the code from working). If you're willing to engage in some debugging, I can give you some debugging versions to try to get it working.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's working for me, thanks. Yes if the delay was longer you'd definitely want to know why. :-) Of course if it just detected the OSX install immediately there'd be no issue. ;-)
(I checked btw that it still doesn't do so now I've properly removed the old /EFI on the same partition.)
I've removed my exclusion for the rEFInd partition and this time made sure I fully removed the original /EFI from my main OSX partition, and all seems well. It's not showing me rEFInd on the boot menu now. :-)
Odd effect on installing the upgrade; not a bug but a minor gotcha: When I originally created the rEFInd partition, it had given it a partition number appended after all the others; but since then partitions seem to have been renumbered to be contiguous to their position on the disk, so the ./install --ownhfs /dev/disk0s5 I did originally didn't work on the upgrade; needed to do --ownhfs /dev/disk0s3.
Just a fact of GUID that I hadn't known before I guess.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for pointing out the renumbering issue. It's not really GPT-specific; it was probably done by some partitioning tool that you used along the way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunally I have the same issue with a MacBook Air 13" and openSUSE on dual boot. I didn't do the suspend action. But ReFit works fine. I don't like the option installing in another partition.
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems folks only want Hibernate to allow a full suspend/resume cycle of the same OS to complete (OSX suspends, and then resumes into OSX, with option to boot Linux anew if you like, or resume a suspended Linux). This works ok for me, on a MBPR 10,2 model using rEFInd. I am using manual entries in refind.conf and disabled auto-scans.
However, my use case is to switch between Linux and OSX doing alternate hibernates to switch between them (on a MBPR 10,2). This works fine with Linux -- I can select between different kernels that have their own filesystems, then boot into rEFInd and resume whichever one, after sleeping from any of them -- but once OSX starts, the firmware does not seem to boot anything but OSX (probably, the last one it booted), no matter if rEFInd is blessed or not. There is no chance to boot a different OS anymore; rEFInd never gets run, except (maybe?) on cold boot (which I cannot seem to force; see below)
I am using a separate (from the ESP, but I tried it on the ESP too) HFSX partition to store refind.efi and the Linux kernels (EFI stubs), blessed that dir and file (using the --bootefi flag for "bless") and the machine boots directly into rEFInd with success. When using the OSX /System/Library/CoreServices/ path and creating empty mach_kernel in root (ala --ownhfs), it does not seem to make a difference. I don't think this actually matters except to be visible from eg "Startup Disk" menu in System Preferences. In my tests, the firmware doesn't seem to care about where rEFInd is stored, it just boots whatever is blessed... not using these paths only means you don't see that boot-select icon available (as when holding down Option on machine-start) if the OSX boot.efi is run instead (we do not care about this right? since we boot directly into rEFInd and skip OSX boot.efi, only invoke from boot.efi itself)
So, everything with rEFInd works great... except that after OSX "pmset sleepnow" or "shutdown -s now" the usual rEFInd boot is completely bypassed, so I won't be able to get to Linux without shutting down OSX first. OSX will resume from sleep fine, but there seems to be no way to interrupt this and go to rEFInd. I have tried hibernatemode 1, 3, 25 and 0 and the best I can get it to do is with 25, it will give a progress indicator, it is obviously loading from disk (ie, it shut off power to the memory chips) and somewhat slower (ssd, but still perceptible and addition of the progress indicator). I am wondering if some nvram variables like efi-boot-image, efi-apple-payload0 can be changed here but afraid to brick my system.
Note that a reboot seems to be required after doing "pmset -a" changes, to affect them before use, but it seems inconsistent on this point and needs more testing to see which cases work that way.
I'm wondering if hibernation writes something to nvram which informs the bootloader next time it runs to skip looking for boot.efi and do some special resume code that just uses whatever the last-booted one was without any chance to choose.
There seems to be no way to do this, then.
(1) anyone have this working on a MBPR 10,2 or similar-age from Apple?
(2) anyone have this working on an older-age macbook chipset?
(3) how to skip firmware's check that [seems to] boot last-booted?
(4) how force to really, really go to rEFInd always?
(5) how force hibernation (and cut power to memory)?
(6) anything broken about how I'm doing this?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(5) how force hibernation (and cut power to memory)?
The only way I've found is to sudo pmset -a standbydelay 0, put the system to sleep, and then wait a minute for the RAM image to be written before opening the lid again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, for some odd reason
sudo newfs_hfs -v EFI /dev/disk0s1does not work properly. It reportsBut diskutil info then reports
It's odd newfs_hfs changes the disk special name from disk0s1 to rdisk0s1 as well.. I don't have Linux and was hoping to avoid setting Linux up on a USB stick just to format the ESP with HFS+.
Still, I can install rEFInd to /dev/disk0s1 with --ownhfs
but all diskutil commands refuse to work. diskutil mount, unmount, rename etc. I can however mount using old UNIX style mount methods.
So it seems newfs_hfs is not compatible with diskutil, and diskutil has no formatting commands, only reformat an existing volume with same format. And that also fails with the newfs_hfs formatted ESP.
However, after all of this, rebooting delay is back in force, and rEFInd does not even work from this newfs_hfs formatted ESP.. After a long delay it boots right back into OSX.
To conclude for now, newfs_hfs is bad, at least for ESP. Do not use it. Now I have to figure out how to restore my ESP, since newfs_msdos has the exact same problems. When I enable debug mode in Disk Utility GUI, it shows my broken ESP, Info shows Can be formatted: no. Perhaps they built protections into OS X 10.9, and that's why newfs_hfs only partially works, just enough to break things.
At least I can install rEFInd back to main boot partition and get back to fast boot times, and the broken ESP does not seem to cause any harm. I think I will have to use a Linux repair USB stick to try to fix it, as Apple's newfs_ utils do not work on the ESP.
Hmm, Windows boot is broken again, after I messed up the ESP.. "No bootable devices found" after choosing Windows from the rEFInd boot menu, even though the number of partitions on the HDD is the same.
Last edit: n808 2013-11-15
I tried recovering ESP from Linux SysRescueCD by formatting it to msdos, then dd back the backup I had taken. No errors doing that, but back in OS X, the GPT still shows it as an HFS+ partition type.
Attempts to use Disk Utility to restore the EFI from an image I created from a USB stick's EFI fail with 'disk0s1 busy', both in regular OS X and when booted from the recovery partition.
Then I downloaded gdisk, and from regular OS X, used it to change the ESP's partition type to 'ef00', renamed it EFI, and rebooted. Finally, Disk Utility now shows exactly what it used to and diskutil works as before, e.g. sudo diskutil mount EFI.
But I still cannot boot to Windows. Attempting this results in "No bootable device - insert boot disk and press any key" error. To fix this, Google searches indicate I need to create a Windows rescue disk and let Windows use its Repair, which I did, but Windows Repair was unable to repair anything, and I still cannot reboot to Windows, even though the partition is there, and seemingly perfectly healthy, never touched by these tests.
Finally, problem solved. I had to create a hybrid MBR and add the Windows partition to this with gdisk, following these instructions:
http://nerdr.com/tag/fix-bootcamp-partition-not-booting-mac-and-macbook-pro/
From what I read, at least Windows 7 on Macbooks operate in BIOS mode and needs a hybrid MBR to work. I have Windows 8, and I am not sure if I ever had a hybrid MBR and it got destroyed by these exercises. The only MBR gdisk showed was a protective one with only the EFI partition.
I think I will avoid messing with the ESP from now on ... and either live without rEFInd, use it from USB, or disable hibernation.
Last edit: n808 2013-11-15
Chances are one or both of two things has happened:
gptsyncorgdiskshould fix the problem; or...Alternatively, you could try doing an EFI-mode boot of Windows. This is supposed to be very tricky with Windows 7, but much more do-able with Windows 8 -- but even with Windows 8, the ease of doing an EFI-mode boot supposedly varies from one model of Mac to another. I've not followed the specifics, so I can't really offer any more advice on this matter.
You replied while I was updating my post. The hybrid MBR must have been wiped. Not sure how, but restoring it with gdisk fixed the problem, without having to use further tools, so the Windows MBR boot code must have been intact, or restored by the Windows Repair tool, which reported failure to fix system, but perhaps it did a partial fix.
Whew, this has been an exercise that I have learned a whole bunch of new topics from. Thanks for your help, Roderick. If you need me to do more tests for future enhancements to rEFInd, I'll be happy to, now that I know how to recover from mishaps.
I might go back to having rEFInd on its own partition, non ESP, and then see if updating the hybrid MBR with the new Windows partition number is enough to make Windows boot after adding this new partition.
EDIT: That's what I ended up doing. Installed rEFInd on its own 1GB partition with the new --ownhfs option. I placed this partition after the OSX partition, which can be resized, and before the Windows partition, which cannot. Then I fired up gdisk, noticed that the hybrid MBR had been wiped, with only the protective MBR left. So OS X Disk Utility wipes the hybrid MBP when changing the GPT, which is reasonable, since then the hybrid MBR is most likely no longer correct. Re-created the hybrid MBR with the new Windows partition number, wrote to disk and re-booted. Now everything works great: hibernation, rEFInd boot choices (I added memtest86 EFI as well), and fast reboots without delay.
Last edit: n808 2013-11-16
Roderick, has there been any further progress on the issue? What do you need to continue? And aside from turning off hibernate feature of OS X, what is the best practice to deal with this issue? Thank you.
Hi, in my previous post I said I was lacking the time to do further tests, and that I'd try some things as soon as possible. As it turns out, changing countries with a 9000 km distance means that as soon as possible is not as soon as I'd like to.
Long story short: now I have some time and did some tests. I changed my ESP partition to a HFS+ one and install rEFInd on it, and it still doesn't work! I can't make a new HFS+ partition in the current state of my HDD since I would have to delete some other partitions and I don't have free space elsewhere to back them up.
Also, I've read the rest of this topic before posting, and I saw the reports from n808 that seem to show hibernation work, but there are a few things I don't understand! You say that in order to test, you wait for the system to go to sleep, and then resume it. But from your report, I'm not sure you actually wake up from hibernation (although it seems that your computer sets up everything for hibernation, which is normal on OSX : save the RAM to disk and go to normal sleep, if battery runs out during sleep one can wake up from hibernation). It may be different on newer computers, since I now for example that MacBook Air automatically turn off during their sleep after a set period of time, so the next boot is necessarily from hibernation, maybe other newer laptops do the same. Maybe you are aware of that and take it into account in your report, but what tickles me is this:
"At least I am 99% sure it did, as it took a few seconds longer than normal sleep, and /var/vm/sleepimage was freshly created, just as it did when I temporarily removed rEFInd altogether."
You stand that the boot seemed longer but it seems to be the only difference, whereas when booting from hibernation not only is it longer but there is a kind of loading screen with a status bar loading on top of a blurred capture of the screen as it was upon hibernating. Once again, you may be right, especially since I use an "old" MacBook with an "old" OS X version (10.6 on a MacBook 8,1) and things may be different with newer ones, but since I can't reproduce your success (although I did install on a modified ESP, which might change things) I want to make sure all Ts are crossed!
So I did some more tests. The issue doesn't seem to be solved yet but I have found a workaround that, if not yet perfect, is enough in my situation and probably will for a majority of users. As I said I was going to in my previous message I reverted my new HFS small partition to a traditional ESP one (thanks to gdisk ;-) and installed rEFInd there, and except from the foreseen sluggishness there was no progress regarding hibernation. So it seems that whatever one does, the use of rEFInd is not compatible with hibernation.
But all this tampering with the ESP partition got me thinking. I remembered that in my first dual boot setup, rEFInd was installed along with a linux system on an external hard drive. I would select it in a kind of chain boot, by holding the ALT key on the startup of the Mac. The boot sequence would then be: Mac boot code -> detection of ALT key -> list of all available boot medium (OS X, CD/DVD, BIOS-booting system e.g. bootcamp, and last but not least alternate EFI bootloaders such as rEFInd) -> choice of rEFInd -> choice of an OS. So I choose the OS X disk as the boot disk in the System Preferences (which I assume should be the same as blessing a certain file, but I don't know which one), rebooted with the ALT key pressed and… nothing. I changed one more time my ESP partition to HFS+, copied rEFInd it on it WITHOUT BLESSING IT, and rebooted with the ALT key pressed. And there it was, the Apple screen allowing one to choose between the OS X setup and rEFInd (called simply "EFI Boot").
I then did tests to confirm everything was acting as I was expecting and it did: I was able to boot any of my usual rEFInd entry by booting while pressing ALT and selecting "EFI Boot", but also to hibernate normally (or rather, to normally resume from hibernation). The pros of this setup are obvious: regaining hibernation. The cons are a longer boot time if you are booting into an alternate system, since you'll have to wait until the Mac boot code scans your available medias and presents you with the "EFI Boot" option. So this isn't a really good solution if you are mainly using another OS as OS X, but if like me you use 0S X 90+% of the time and only boot to other OSs for some specific tasks, it won't be much of a problem.
As a bonus, it got me thinking about the boot sequence on Macs and I did the following test: turn off my computer by hibernating, and then booting while pressing the ALT key. When doing that, the choice for a boot media never shows up, so the only choice is to resume from hibernation. This means that you don't risk booting into another OS that may temper with your hard drive and leave OS X disoriented when finally resuming from hibernation.
Also, the traditional Mac "gong" is not played. Since it is also played when booting after having blessed rEFInd and I doubt it is a function of rEFInd itself, it may indicate things about the boot sequence and help change rEFInd to offer proper hibernate support on Macs (if that is what the author wants to do, of course, which I don't myself consider a priority since the setup I used did the trick). I think that some Apple code is always executed first and checks what media it should boot from, and if it is the default OS X setup, if there is a hibernation state to resume from, in which case it doesn't play the "gong". But if it is not supposed to boot from the OS X partition, a "gong" is played and boot proceeds without any support of hibernation. I also had the idea that this small code never checks for hibernate status at all and leave it to the OS X bootloader but the following test seems to disprove that: if I hibernate my Mac and press the ALT key on reboot, the computer resumes from hibernation without leaving me the choice of a media to boot from, meaning that hibernation is indeed checked for and has a higher priority than choosing to boot from a different media.
So, as I said, I finally found a setup that works for me. The only case it would pose some really noticeable problem is if one often boots on alternate OSs, but in this case it is likely that they would not care as much for hibernation support in OS X, so it seems to me that this issue, although not solved, can be circumvented, thus not requiring any further development of rEFInd in this direction. That being said, if the author is willing to offer full hibernation support on Macs and needs some investigation done, and since you said you don't own a Mac other than a 32-bits Mac mini, I'm willing to help if I can, as a way of thanking you for this amazing tool. But then again, it seems more likely to me that rEFInd is compliant to boot standards and it is Apple which, as often, can't be bothered to comply. So anyway, if you need some tests done or something be sure to let me know :)
Very funny, Simon, that you and I were both trying this same thing today. After reading this thread thoroughly, I also decided to follow Roderick's suggestion to just install rEFInd to a separate HFS+ partition using the "--ownhfs device-file" option to target the new partition (partition name retrieved using "diskutil list").
So...
...a little bootup from an Ubuntu 14.04 USB stick
...some gparted action to make me a nice little 200MB partition
...then some boot back into OS X to format the new partition HFS+ (using Disk Utility)
...an install of rEFInd using "install.sh" with the "--ownhfs" option to target my little 200MB HFS+ partition
...a reblessing of the Mac OS X primary startup disk using standard Apple "Startup Disk" in System Preferences (switching back to the primary Mac OS X startup disk instead of the currently selected 200MB rEFInd partition)
...and finally a hold-down of the Option (Alt) key during restart
...gives me what I consider to be a VERY workable solution that keeps my hibernation intact (crucial for maximizing battery life while maintaining my system state throughout the work week/month/quarter). This solution also enables me to readily switch over to Linux or Windows with a simple reboot while holding down Option (Alt) when I need to get my geek or my game on.
Thanks a bunch to all who participated in this thread. And thanks to Roderick for continuing to foster the conversation to help us OS FREEks continue to try out the latest and greatest in the open source arena without sacrificing the top-notch performance of our primary OS X installations :-)
<o>
--
P.S. Full disclosure. After following the above steps, I couldn't boot Windows: "Missing Operating System". I remembered something about rEFIt having Hybrid MBR synching built in, so I did my Option (Alt) boot, picked rEFInd from my 200MB partition, then picked rEFIt that was still on my primary OSX partition that rEFInd recognized, then tried to boot Windows. It didn't work (stayed on the grey screen with the Windows logo until I hard powered down holding down the power button), but when I rebooted back into rEFInd the second time and tried to boot Windows, it booted fine (phew!).
P.P.S. My ability to boot my early 2011 MacBook pro from a Linux Live USB stick was only made possible by booting into the Windows 8 install first, then selecting Linux from the Windows boot menu. Linux got on the Windows 8 boot menu after I ran Wubi from the Live USB stick in Windows. I've never been able to get a Linux USB stick to boot up either through Apple's boot manager, or through rEFIt, rEFInd, or PLOP boot manager. So I was amazed when the Windows 8 bootloader actually enabled me to overcome that long-standing hurdle. Go figure!
Last edit: Eye Em 2014-05-06
Also, if like me you are annoyed by that second partition that you can't do anything with since it's only 300 Mb and you'd also like to avoid having other users tamper with it, here's how to ask OS X not to mount it at startup using fstab (you can mount it manually) :
https://discussions.apple.com/thread/4271735?tstart=0
Last edit: Simon Picard 2014-05-09
Aha! I found the discussion forum. I knew there had to be one!
OK, I've been experiencing this issue on a Macbook Air 4,1. Today I tried 0.8.0 which probably didn't have anything in itself to fix it, but following a new hint on the website (I'm sure it wasn't there last time I looked) I tried the --ownhfs thing; made a small partition after my main OSX one (that was a mini adventure in itself; Disk Utility was being uncooperative, so it was a joint effort between diskutil and gparted on Linux - side-effect I also seem to have made the Mavericks Recovery partition generally visible, possibly because it's not directly after the OSX system partition any more) and got it going...
... and so far, all seems well. rEFInd seems happy to boot Linux and OSX from its own partition, and OSX at least is, I think, hibernating and recovering from there properly. (Linux doesn't seem to want to hibernate at all but I think that's its own problem.)
And then I found this discussion and caught up.
NB: contra some earlier posts I've left it so that the rEFInd partition is 'blessed' and boots by default. If I wanted to alt-boot I'd not bother with rEFInd at all, and just learn to live with the daily affront to one's dignity of having to choose "Windows" at the alt-boot menu to boot Linux. I have after all been doing that for a while already.
So why again was the advice in this thread to leave the main OSX partition 'blessed' normally and alt-boot to get to rEFInd? It doesn't seem to be necessary for me. (Maybe it was a reason involving Windows, which isn't involved here?)
Other issues arising:
I made the rEFInd partition HFS+ without journalling. Also I haven't tried yet, this should make it read-writable from Linux as well. Doesn't seem to stop it booting.
Booting rEFInd from its own partition, it doesn't on its own detect the OSX install; so it just comes up with the Linux boot options. That seems to be similar to a problem others have reported here, so I added the scan_delay 1 and that seems to fix it; although at the cost of [a second and] seeing the text message saying it's delaying flash up. Can we suppress that text please, as it is only a second?
I was also able to boot OSX via rEFInd by adding a manual boot stanza, which had the side effect of making it last on the list instead of first, but worked.
Oh, I also had to configure rEFInd not to scan its own partition for boot entries, to avoid having a refind entry in the refind screen, which I thought was a bit of unnecessary clutter. :-)
Last edit: Rachel Greenham 2014-05-09
"So why again was the advice in this thread to leave the main OSX partition 'blessed' normally and alt-boot to get to rEFInd? It doesn't seem to be necessary for me. (Maybe it was a reason involving Windows, which isn't involved here?)"
It looks as though different versions of OS X (or possibly hardware) behave differently when it comes to hibernation, since both you and n808 report getting it to work by installing rEFInd to its own HFS partition, and you both reported using a newer version as me (I'm running 10.6). So it's good that the answers for users using different system versions are there :)
As for using rEFInd after a ALT-key boot, it is necessary if you are booting Linux through EFI instead of BIOS, in which case it isn't listed in the boot choices (at least in my current setup, although I assume it could be done).
"As for using rEFInd after a ALT-key boot, it is necessary if you are booting Linux through EFI instead of BIOS, in which case it isn't listed in the boot choices (at least in my current setup, although I assume it could be done)."
Yeah; while I boot Linux by EFI stubloader normally, I do leave grub installed as well as backup, as once or twice during Trusty's alpha/beta stages they put out a kernel that didn't work as an EFI stubloader. A side-effect of that is it appearing as "Windows" in alt-boot, and it means I get both an Ubuntu icon and a Tux icon for the grub boot in rEFInd. I just set "max_tags 2" to limit it to two boot icons on the main screen (Mac and first Ubuntu kernel) so others including grub are hidden but still reachable at need.
If you're annoyed by the message about doing a boot scan when you set
scan_delay 1, here's a tentative fix:http://www.rodsbooks.com/refind-bin-0.8.0.6.zip
This version suppresses those messages on startup when the
scan_delayis 1. Of course, the drawback is that then you see nothing happen for longer.That should be unnecessary, since rEFInd includes code to exclude its own directory from scanning. Are you sure you don't have two rEFInd installations -- say, one on the ESP and one on the OS X root (
/) partition? You could figure this out by installing a new version (like the one pointed to above) and then comparing the version information in the "About rEFInd" screen in the version that launches and the version you get when you launch rEFInd itself. You'll also see different path information when you highlight rEFInd in the two rEFInds if my guess is correct.If you really have just one rEFInd installation, then there's a bug in the self-exclusion code (or a bug in your EFI that's preventing the code from working). If you're willing to engage in some debugging, I can give you some debugging versions to try to get it working.
That's working for me, thanks. Yes if the delay was longer you'd definitely want to know why. :-) Of course if it just detected the OSX install immediately there'd be no issue. ;-)
(I checked btw that it still doesn't do so now I've properly removed the old /EFI on the same partition.)
I've removed my exclusion for the rEFInd partition and this time made sure I fully removed the original /EFI from my main OSX partition, and all seems well. It's not showing me rEFInd on the boot menu now. :-)
Odd effect on installing the upgrade; not a bug but a minor gotcha: When I originally created the rEFInd partition, it had given it a partition number appended after all the others; but since then partitions seem to have been renumbered to be contiguous to their position on the disk, so the ./install --ownhfs /dev/disk0s5 I did originally didn't work on the upgrade; needed to do --ownhfs /dev/disk0s3.
Just a fact of GUID that I hadn't known before I guess.
Thanks for pointing out the renumbering issue. It's not really GPT-specific; it was probably done by some partitioning tool that you used along the way.
Unfortunally I have the same issue with a MacBook Air 13" and openSUSE on dual boot. I didn't do the suspend action. But ReFit works fine. I don't like the option installing in another partition.
Regards
It seems folks only want Hibernate to allow a full suspend/resume cycle of the same OS to complete (OSX suspends, and then resumes into OSX, with option to boot Linux anew if you like, or resume a suspended Linux). This works ok for me, on a MBPR 10,2 model using rEFInd. I am using manual entries in refind.conf and disabled auto-scans.
However, my use case is to switch between Linux and OSX doing alternate hibernates to switch between them (on a MBPR 10,2). This works fine with Linux -- I can select between different kernels that have their own filesystems, then boot into rEFInd and resume whichever one, after sleeping from any of them -- but once OSX starts, the firmware does not seem to boot anything but OSX (probably, the last one it booted), no matter if rEFInd is blessed or not. There is no chance to boot a different OS anymore; rEFInd never gets run, except (maybe?) on cold boot (which I cannot seem to force; see below)
I am using a separate (from the ESP, but I tried it on the ESP too) HFSX partition to store refind.efi and the Linux kernels (EFI stubs), blessed that dir and file (using the --bootefi flag for "bless") and the machine boots directly into rEFInd with success. When using the OSX /System/Library/CoreServices/ path and creating empty mach_kernel in root (ala --ownhfs), it does not seem to make a difference. I don't think this actually matters except to be visible from eg "Startup Disk" menu in System Preferences. In my tests, the firmware doesn't seem to care about where rEFInd is stored, it just boots whatever is blessed... not using these paths only means you don't see that boot-select icon available (as when holding down Option on machine-start) if the OSX boot.efi is run instead (we do not care about this right? since we boot directly into rEFInd and skip OSX boot.efi, only invoke from boot.efi itself)
So, everything with rEFInd works great... except that after OSX "pmset sleepnow" or "shutdown -s now" the usual rEFInd boot is completely bypassed, so I won't be able to get to Linux without shutting down OSX first. OSX will resume from sleep fine, but there seems to be no way to interrupt this and go to rEFInd. I have tried hibernatemode 1, 3, 25 and 0 and the best I can get it to do is with 25, it will give a progress indicator, it is obviously loading from disk (ie, it shut off power to the memory chips) and somewhat slower (ssd, but still perceptible and addition of the progress indicator). I am wondering if some nvram variables like efi-boot-image, efi-apple-payload0 can be changed here but afraid to brick my system.
Note that a reboot seems to be required after doing "pmset -a" changes, to affect them before use, but it seems inconsistent on this point and needs more testing to see which cases work that way.
I'm wondering if hibernation writes something to nvram which informs the bootloader next time it runs to skip looking for boot.efi and do some special resume code that just uses whatever the last-booted one was without any chance to choose.
There seems to be no way to do this, then.
(1) anyone have this working on a MBPR 10,2 or similar-age from Apple?
(2) anyone have this working on an older-age macbook chipset?
(3) how to skip firmware's check that [seems to] boot last-booted?
(4) how force to really, really go to rEFInd always?
(5) how force hibernation (and cut power to memory)?
(6) anything broken about how I'm doing this?
Thanks.
So what is the solution for this? Is there any step by step guide? Im on refind 0.8.7.
Any help is appreciated.
The only way I've found is to
sudo pmset -a standbydelay 0, put the system to sleep, and then wait a minute for the RAM image to be written before opening the lid again.