EFI: multiple gentoo instances conflicting

JumboAg

I'm more interested in WHY this is happening than anything:

I've got an EFI-boot setup on my desktop. I've got several different flavors of Linux, each with their kernel in a common vfat /boot/efi/EFI/${DISTRO} location.

Everyone places nicely with each other (I even have a Win8 environment) except for when I add a SECOND Gentoo environment. When I do that, My system will hang on booting both this new Gentoo AND my original Gentoo if I dont get the kernel for the new environment setup correctly.)

Why on earth is this? They should be completely independent. They dont share a / partition. (They do share a swap partition, but that shouldnt matter). I know its the new kernel.efi because if I remove it, the original Gentoo starts working perfectly. How can a separate EFI environment be impacting a previously OK one? Isnt the whole point of EFI booting to segregate things??

Is this a glitch in my EFI bootloader? Some Gentoo thing?

List of my boot images under /boot/efi/EFI:
gentoo (original KDE environment)
gnometoo (my new Gnome-based Gentoo dev environment)
Microsoft (winblows

redhat (fedora 17)
ubuntu (Kubu)

Other things that might be important:

1) I'm using refind as my efi manager.
2) I dont use grub. I define my kernel boot params within the kernel image itself and use an EFI Stub kernel command line.

srs5694 · Posted: Sat Mar 30, 2013 5:42 pm Post subject:

Please post, between code tags:

The output of "sudo ls -lR /boot/efi/* --hide Microsoft"
The contents of the refind_linux.conf files for both your Gentoo installations.

JumboAg · Posted: Sat Mar 30, 2013 7:11 pm Post subject:

I was hoping you would notice this post ;-)

srs5694 · Posted: Sun Mar 31, 2013 2:40 am Post subject:

I have two thoughts about this.

First, the filenames "3.7.10-gentoo.efi" and "3.6.11-gentoo.efi", which I'm guessing are your Linux kernels, have no special meaning to rEFInd. Therefore, unless you've got manual configurations for them in refind.conf (see below), rEFInd will simply launch them like any other EFI programs. This will launch the kernel, but without the options that the kernel needs to boot, such as the name of the root filesystem and the name of the initrd file. The result is that the system will either not start up completely or that will start up completely only if appropriate options are embedded in the kernel at compile time. This explains why your system is failing to start up, but it fails to explain why deleting one of the kernels causes the other one to start up correctly. Thus, I suspect there's something else to this puzzle.

My second thought is that if you have manual boot stanzas for one or both of these kernels in your refind.conf file, maybe a missing "}" at the end of the first boot stanza could cause a problem like you describe. That said, I haven't tested this hypothesis myself, since it's easier for you to check your own refind.conf, if that's how you've set things up. If you're using manual boot stanzas and you don't see any obvious problem with them, please post that section of your refind.conf file for me to see; I might spot something that's causing problems.

As a general rule, my recommendation for Linux users is to name their kernels vmlinuz* or bzImage*, to place them in the same directory as an init* file with the same version number, and to include a refind_linux.conf file to hold kernel options. The details for all of this appear on the rEFInd Web site, so check there for additional details. Furthermore, if Linux's /boot is on a filesystem that the EFI can read (FAT or, with appropriate drivers, ext2/3/4fs or ReiserFS), you can forego copying the kernel to the ESP. Although manual boot stanzas make sense in some configurations, using rEFInd's auto-detection really is simpler in most cases, since it requires no reconfiguration when you upgrade your kernel, provided you name the new kernel and initrd correctly.

JumboAg · Posted: Sun Mar 31, 2013 2:45 am Post subject:

I appreciate the help and the suggestions.

I have my kernel options configured directly into the kernel using an EFI stub line at compile time.

I think I have stumbled onto a bug that you already fixed. After your original email regarding a .conf file, I went back and looked at the readme into on refind and found no reference to it. I then pulled up refind online and noticed you've been quite busy. I had 0.4.6. I upgraded to 0.6.8 and rebooted (still not using a .conf or renaming anything yet) - and now everything works perfectly.

Regardless of whether I have two Gentoo's or not, a good one will always boot, a bad one wont. They no longer interfere with each other.