Late 2013 Mac Book Pro Gentoo Frustration

[Brandon]

I continue to get a loader not found error when I select my Linux Kernel and Refind never seems to auto find my Linux Instance. I have compile my kernel using the stub flags correctly.

This is my refind.conf I am currently using.
https://dpaste.de/oHoh

Refind works great with my OSX partition and I have no issues booting into OSX. I have dropped both my initramfs.img and vmlinuz into the /ESP/EFI/ directory.

My disk layout consist of /dev/sda1 EFI
/dev/sda2 OSX
/dev/sda3 OSX
/dev/sda4 Linux ext2 /boot
/dev/sda5 swap
/dev/sda6 / Linux btrfs
/dev/sda7 /home Linux btrfs

Can someone please help me get this working. Thank you for your time and patience with this awesome project.

[Roderick W. Smith]

I have some suggestions:

1. Remove (or disable) the Linux manual boot stanza you've created. Manual boot stanzas tend to cause beginners a lot of trouble, so I recommend avoiding them unless you really need them.
2. If /ESP is where your ESP is mounted, rEFInd searches subdirectories of /ESP/EFI by default, so you'd need to put bootable files in /ESP/EFI/foo or someplace similar, not in /ESP/EFI. I realize you've added an also_scan_dirs directive to refind.conf, but if the partition name is incorrect, this won't work. It's best to put files where rEFInd scans for them by default. The also_scan_dirs directive is intended to assist when you don't have much control over where things go -- for instance, if an OS were to install its boot loader in a non-standard location.
3. If you haven't done so, add the rEFInd ext2fs (or ext4fs) driver to the drivers or drivers_x64 (or drivers_ia32 if you've got a 32-bit EFI) subdirectory of the rEFInd installation directory (where your refind.conf file exists). This should enable rEFInd to detect your kernels in the Linux /boot directory, which you say is on ext2fs.
4. If the preceding step doesn't help, try putting some other known-working EFI file in the same directory as your kernel. An EFI shell or copy of GRUB should work. (rEFInd might remove itself or other files it finds elsewhere as duplicates, though, so don't use anything else that's already showing up in the menu.) The point of this is to verify that rEFInd is actually seeing the directory in which the kernels reside. If not, you can focus on debugging that problem; but if the EFI program you copy shows up in rEFInd's menu, you can be confident that there's something wrong with your kernel -- maybe it doesn't have an EFI stub loader, or maybe its name is wrong.

[Brandon]

So I followed your steps verbatim. I created a dir call foo and dropped the following images.

bash-3.2# ls
initramfs-3.17.8.img vmlinuz-3.17.8 vmlinuz-3.17.8.efi

bash-3.2# pwd
/Volumes/ESP/EFI/foo

When I reboot the system does not see the images. I also have the same located on /dev/sda4 which is the boot partition. It would appear anything Linux related is not being found by refind. I have disable the manual entry as you suggested. I also was not sure how I should go about trying grub2. Do you have a recommendation where I could grab a efi?

Cheers

[Roderick W. Smith]

My suspicion is that you're getting mixed up with mount points. It's easy to get confused and put something a level up or down compared to where it should be. Please review those details. Try typing df in an OS X Terminal window. This will produce output that shows where everything is mounted, as in:

$ df
Filesystem    512-blocks     Used Available Capacity  Mounted on
/dev/disk0s3    97656256 39711096  57433160    41%    /
devfs                225      225         0   100%    /dev
map -hosts             0        0         0   100%    /net
map auto_home          0        0         0   100%    /home
/dev/disk0s1      403266    90650    312616    23%    /Volumes/ESP

This example shows that /dev/disk0s1 (the ESP on this system) is mounted at /Volumes/ESP. Verify that this is the ESP by using diskutil list. You can then check its contents and ensure that bootable files are in /Volumes/ESP/EFI/{somedir}, where {somedir} is just about any string -- rEFInd search almost every subdirectory of EFI on the ESP.

If you check all this and it looks good, please post back with the output of df and diskutil list in OS X, as well as ls -R on your ESP (as in ls -R /Volumes/ESP.

You might also try reading my EFI Boot Loaders for Linux page, which describes GRUB 2 and other EFI boot loaders. Note that Macs have unique boot loader installation requirements; you shouldn't use efibootmgr as described on that set of pages.

[Brandon]

$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage 250.1 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 1.1 GB disk0s4
5: Linux Swap 2.1 GB disk0s5
6: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 214.7 GB disk0s6
7: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 31.4 GB disk0s7
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS BJAMES HD 249.7 GB disk1
Logical Volume on disk0s2
2340BC2D-B6DF-48CA-9886-D4E17D0BB1EA
Unencrypted

Here is the link to my ls -R of the Volume ESP dir. https://dpaste.de/Jjfj

It should be noted when I boot into OSX I have to manually mount the dir /Volumes/ESP and create the dir ESP before I mount the disk. Is this normal?

[Roderick W. Smith]

Having to manually mount the ESP is normal. If you prefer to have it auto-mounted, you can create an /etc/fstab file to handle the task, as described here.

Your ls -R contents look OK, provided the ESP is really mounted at /Volumes/ESP. (That's what df will confirm or deny.)

Here's another diagnostic procedure you might try:

1. Install an EFI shell. See here for some download links, or use the shell binary from rEFIt. You'll probably need a v1 shell, not a v2 shell. Install it, as shell.efi or shellx64.efi, in the EFI/tools directory on your ESP.
2. Reboot into rEFInd. You should see a new EFI shell option on the second row. (Unless you've edited showtools in refind.conf to omit the shell, in which case you should edit that line to include shell as an option.)
3. Launch the EFI shell.
4. Type fs0: in the shell, followed by ls or dir to view a directory.
5. If the files you see don't match those that should be on your ESP, try again with fs1: and so on until you locate your ESP.
6. Type cd EFI\foo to change into the directory that holds the kernel. Note that's a backslash (\), not a forward slash (/), as a directory separator.
7. Type ls or dir to verify the files.
8. Type vmlinuz-3.17.8.efi to launch your kernel. (You can add a root={whatever} specification and initrd=\EFI\foo\initramfs-3.17.8.img to fully boot if you like. The main point here is to be sure that your kernel is executable by the EFI, not that you can fully boot into your Gentoo installation.)

My suspicion at this point is that the shell will respond with a message to the effect that your kernel is unbootable; or perhaps there'll be a problem earlier in the process, like an inability to access the EFI\foo directory. Either way this will help you figure out where to look. If you see an error message and want further help, post the exact message here. (Feel free to take a digital photo and post a link to it, particularly if the message is long.)

If my suspicion is correct, you should review your kernel configuration. Make sure that you compiled it for AMD64 and not for i386, and check again that the stub loader was included. An error on either score will result in an unbootable kernel. (I've made both those mistakes myself!) Also, what command did you use to compile the kernel? I always use make bzImage, but there are other commands that will work. Some others, like make vmlinux, are unlikely to work.

If you can't reach EFI\foo at all, but if you can see other directories, then your filesystem is probably damaged and needs repair. In fact, backing up, creating a new FAT filesystem, and restoring everything is probably the best way to go.

[Brandon]

Ok so I got into the EFI shell and tried to boot the kernel. I got the following vmlinuz-3.17.8.efi is not recognized as a internal or external command.

[Roderick W. Smith]

That supports my hypothesis that there's something wrong with your kernel. Please review your settings, particularly for the architecture and for the EFI stub loader options. You should see something like this in your .config file:

$ grep EFI_STUB .config
CONFIG_EFI_STUB=y
$ grep CONFIG_X86_64 .config
CONFIG_X86_64=y

As I say, there could be other problems, too, like selecting the wrong compilation target.

[Brandon]

Ok I got it to boot!!!!! Now im having a kernel panic because it can not find the rootfs. I am going to try to use the UUID instead of root=/dev/sda6 in the kernel boot stanza.

[Roderick W. Smith]

Do you mind saying what you had to do to get it to boot?

If you're using an initrd, a failure to find the root filesystem sometimes refers to the initrd, not your real root filesystem. This can happen if you type the wrong filename to pass as an initrd= option to the kernel. I've also seen this happen when making a mistake configuring kernel options related to the disk device drivers. Be sure your compiled GPT support into your kernel, too; IIRC, that's not selected by default.

[Brandon]

Something with how I was running genkernel was ignoring my settings in the .config. I ran make and make_modules install and boom it showed up. I am however still getting the kernel panic and I have GPT in the kernel. I am also not using a initrd at all. I only have the kernel. Says please append a correct boot option. sda6 is unknown.

[Roderick W. Smith]

Your ls -R output shows an initrd file. If you're positive you don't need it, then my best guess is that you've omitted a critical disk controller driver or something related. Those can be easy to miss. Getting a successful boot without an initrd is getting harder and harder, too. In any event, it seems likely that this is now a generic Gentoo/kernel-building issue, not a rEFInd or EFI stub loader issue. You're more likely to get good advice over on the Gentoo forums. I recommend going there and posting a link to your kernel .config file along with the exact commands you used to compile it and the exact options you're passing the kernel.

[Brandon]

SO your help did it. I have functional system now. Roderick again thank you for you help with this!. I managed to have my sata controller compiled as a module instead of directly in the kernel.

On another note I am fascinated with this project and I wanted to know if I could help in any way.

Thanks,
Brandon

[Roderick W. Smith]

Check the To-Do list for some thoughts on things that need doing:

http://www.rodsbooks.com/refind/todo.html

Of course, you may have other things to contribute; don't limit yourself to what's published on that page!