help with multi-boot setup on macbook pro
An EFI boot manager utility
Status: Beta
Brought to you by:
srs5694
Menu
▾
▴
I am trying to coerce an mbpro (mid 2011) into triple booting macos, windows 7 and debian 6; after spending an inordinate amount of time things "mostly" work, but not fully, and I have a couple of problems with refind...
Disk is hybrid, using 5 partitions (windows uses 2, as I keep os and data separate); ntfs for windows and ext4 for linux - see later on for full disk geometry dumps.
(I know hybrid disks are evil, but I use windows my main os, and that's the only option available currently for multiboot)
Refind 0.31 is installed to the EFI ESP; default boot is to windows (achieved, after blessing refit while in macos, by booting into windows an using the bootcamp helper tool) and refind is summoned by holding the ALT key while booting.
I have set "scanfor" in refind.conf to:
internal,hdbios,external,biosexternal,optical
and copied shell.efi into refind/tools.
Problems I have:
1. windows 7 is not picked up by refind. Can I set up a manual stanza for it?
2. refind does not show the button for the "shell"
3. refind shows itself (EFI/refind/refind_x64.efi) as one of the OS available to boot
4. refind gives an "Unsupported while scanning the root directory" error message
5. (most likely not related to refind) can not boot debian via refind -> grub-efi (so far I managed only to boot it via super-grub2 on a cd)
Any help would be welcome.
Thanks
Gaetano
--- Disk Info ---
GPT view:
Logical sector size: 512 bytes
Disk identifier (GUID): 341A0AA8-EB3A-A14A-9DAF-E3DA65CAA46B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 269788 sectors (131.7 MiB)
Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI
2 409640 98065887 46.6 GiB AF00 Mac
3 98328576 412901375 150.0 GiB EF00 Windows
4 412902630 832825662 200.2 GiB 0700 Data
5 832827392 976769023 68.6 GiB 0700 Linux
MBR view:
Disk size is 976773168 sectors (465.8 GiB)
MBR disk identifier: 0x0000125F
MBR partitions:
Number Boot Start Sector End Sector Status Code
1 1 409639 primary 0xEE
2 409640 98065887 primary 0xAF
3 * 98328576 412901375 primary 0x07
4 412902630 832825662 primary 0x07
One more thing: Concerning your inability to boot Windows 7, does rEFIt detect it? If not, it could be that it's got an unusual boot signature that neither program understands. I could add it, but I'll need a copy of the boot disk's boot sector. E-mail me for help on getting that, if you need it.
Wow, fast answer turnaround - and on sundays!
I investigated a bit more:
it turns out I had installed the shell.efi file in /EFI/refind/tools. I moved it to /EFI/tools after rereading the docs one more time
looking at the refind version number, I found out that it sill said 0.3.0... So, from that initial refind menu, I chose to load EFI/refind/refind_x64.efi, and lo and behold, I got something completely different:
This makes me think that the actual refind being run is the old version I had previously installed. And begs the question: in the documentation of refind, which is btw quite complete and makes for an extremely interesting read, there is little trace of upgrade procedures. Does macos actually create a hidden copy of the currently blessed bootloader? I think I did not re-run the bless command after upgrading refit...
Last thing about point 5: I do manage to drop into a grub command prompt from refind, so I think it's not a refind problem at play there. In fact I think that grub works fine as well, since playing around with modprobde to load efi_gop I succesfully get to see a kernel booting log - complete with final panic message. The error is "no filesystem could mount root: tried" (and no trace of fs types). At first I thought it might be some missing drivers for the mac hw (and I recompiled the initird.img following the instructions found at http://mennucc1.debian.net/macbook_linux_efi.html), but reading your site it occurred to me that it might be caused by the protective mbr not spanning the correct blocks at the beginning of the disk...
OK, this sounds like most of your problems are solved by 0.3.1; now you just need to get it to start! My knowledge of what the "bless" utility does is still a bit incomplete, but I've found that:
For this reason, I prefer to do my rEFInd upgrades from Linux, although the initial installation uses OS X and "bless".
I ran across a claim that "bless" works by referring to files by inodes rather than filenames. This is rather low-level stuff and could account for some weird behavior, such as continuing to use a file after it's been deleted. (I've seen that, too, after I deleted rEFIt.)
Linux boot problems relating to an inability to find the root filesystem can have any number of causes, including (but probably not limited to):
You can of course rule out LVM/RAID problems if you're not using those features -- and your disk data suggests that you're not. Driver problems are unlikely if you're using a distribution-provided kernel and initial RAM disk. Therefore, I'd suggest focusing on the initrd and kernel options specifications in grub.cfg.
You could also try installing a completely different boot loader. (You can do this in parallel with GRUB 2; just be sure not to overwrite any GRUB 2 files on your ESP.) If you copy your options from your GRUB 2 configuration and they're causing the problem, this won't help; but both ELILO and GRUB Legacy have much simpler configuration file formats, so they're likely to be easier to hand-tweak. The EFI stub loader is very easy to get working with rEFInd, but Debian doesn't yet provide a kernel with this support enabled, AFAIK, so it will be hard to get working in your situation, at least unless/until you're up and running well enough to compile your own kernel.
Small update: I tried installing elilo, kernel and initrd to the ESP. I get an error as well, about the kernel image not being found - short of me having gotten wrong the elilo conf, this seems to point to a problem with initrd not having enough drivers... maybe it misses gpt support?
A message to the effect that the kernel could not be found suggests a problem with ELILO. Perhaps you've got a typo or some other error in elilo.conf, or maybe it's an ELILO bug. (FWIW, I've never gotten ELILO to work on my Mac Mini, but it's an elderly 32-bit model, and I've seen references to ELILO working on other Macs, so my problems may be model-specific.)
I've found that Fedora's patched GRUB Legacy works reasonably well on my Mac Mini. I've got versions converted to tarballs here:
http://www.rodsbooks.com/efi-bootloaders/grub_legacy.html
Another option is to use the kernel's EFI stub loader. The trouble is that this will require you to compile and install a kernel for your system, and if you can't boot into that system, this task could be challenging. If you can boot in BIOS mode, you can do it as you normally would. If not, you'll need to use another computer, and ideally one that's identically configured. The initial RAM disk generation is likely to be a challenge even then, though.
One more question: the linux partition is number 5 (and not even visible in the mbr).
I guess linux can boot from partitions above nr. 4 when in bios/gpt mode, as I can boot to it when using a cd-rom for the bootloader, but I was wondering if this might pose any problem...
If I could edit the protective mbr by hand, I could maybe change it this way:
mbr1: esp+macos gpt partitions
mbr2: windows os
mb3: windows data
mbr4: linux
I am bit loath to do this, as editing mbr by hand scares me (don't want to break again booting windows, I'm now quite proficient at getting it back, but I already spent too much time doing that) and I'm not even sure it's gonna help...
Linux ignores the hybrid side of a hybrid MBR, so all you need in the hybrid MBR is the Windows partition and any shared-data partitions you have (it looks like #4 qualifies for you). It's also possible to set up a hybrid MBR that includes any arbitrary partitions from the GPT side on the MBR side (not to exceed the limit of 3, of course). My gdisk program (http://www.rodsbooks.com/gdisk/) can do this, if it's necessary.
FWIW, the way I suggest setting up a complex hybrid MBR, if it must be done, is to put Windows (or any other partitions that must be accessible via MBR) at the end of the disk. That way, the 0xEE protective partition will protect all the other partitions from harm. Unfortunately, the gptsync program that most people use to create hybrid MBRs is too simplistic to do this; you'll have to use gdisk, or maybe something else if another tool can do it. (You could also do it "by hand," but that's creating rather too great a possibility of introducing user errors.)
Reviving an old thread with info someone else might find useful:
a) "ghost efi 0.3.0"
about having an olde version of refind "somewhere" on board: even though I have upgraded refind many times (always keeping it in the ESP partition), the mac would often revert to loading the old 0.3 version (eg. after resetting nvram + pram).
I have finally found out where it was stored: in the Macosx partition. The command used to find it: "bless --info /".
It seems that you can have different blessed bootloaders on different partitions, and the blessed loader on the macosx partition takes precedence over the one on esp whenever nvram is reset or when booting using weird key combos.
I can also confirm that blessing works by inode, as moving/renaming away the old refind efi file would not change much.
Maybe this info can be added to the doc page about installing refind by hand?
Last but not least: a question: I have now no blessed bootloader on the macosx disk. Is this a good idea or should I just bless again the original boot efi in system lib?
b) "booting linux in efi mode"
- dumped debian in favor of ubuntu 12.10 to get modern kernel and proper drivers
- no way to get direct refind => kernel boot, as video card(s) would get very very messy state, and refind does not allow enough flexibility to have them set up pre-kernel-loading
- the grub2 config generated by ubuntu installer would not boot at all
- got a "quite clean" grub config off the web, which disables radeon video card, sets up properly the intel card (I want my linux to save power, not to run games)
- everything seems to work at last, except booting linux is not 100% stable (at random it crashes instead of starting)
- even survived 2 kernel upgrades :-D
My configuration:
. refind + conf on ESP
. grub2 + conf on ESP, boots kernel + initrd from the linux disk
. do not need to have correct fs driver for efi to be able to read linux partition
. when upgrading kernel from linux side, new kernel and initrd are generated, but the actual grub config is not touched. This makes me feel safe that upgrades will not screw me over. Downside: I have to manually edit the grub config to point to new kernel image
. ESP mounted by default in linux as /boot/EFI to make it practical to edit stuff on it
Nest steps: upgrade linux disk to ext4 - but I need to be sure that I add ext4 support to both kernel and grub at the same time...