# [SOLVED] UEFI boot Gentoo

## ManDay

For days I've been trying to get Gentoo to boot from SSD on a Samsung XE700T1A : Here is what happend.

1) At first, I noticed that, after removing windows, purging the SSD and writing a GPT label to the disk, the computer from then on always dropped me into the BIOS-GUI, as if I had pressed "Del", when powering on (regardless of whether a MBR Bootloader was installed or not).

From that, I inferred that it must mean something to the PC if it sees a GPT on its SSD. Given that the HW is UEFI 2.0, it seems reasonable to assume that this has something UEFI - possibly it expects an UEFI bootloader which it does not find.

2) I set up the same GPT with a distinct (sda5) FAT32 "bootable" EFI System Partition and place EFI applications in the {ESP}/EFI/boot/bootx64.efi location. To no effect. The PC still shows me the BIOS-GUI when booting, and when I attempt to explicitly boot from sda, I get an error about no bootable device being found. For that, I've tried the EFIs of ELILO, GRUB2, rEFInd, UEFI Shell, and the kernel itsself with EFI_STUB=y. Meaning the primary problem is that my BIOS appears to ignore the EFI application in the default location.

3) I can UEFI boot UEFI Shell from a USB Stick. From the UEFI Shell, I tried calling ELILO, which I could not get to work. It says "ELILO: ..." and responds to me typing the path of bzImage, followed by Enter - but the response is only that it reboots. What's wrong with ELILO?

```
boot=/dev/sda5

root=/dev/sda1

read-only

default=Gentoo

image=/boot/bzImage

 label=Gentoo

 append=rootfstype=ext3
```

4) I also tried to call the bzImage (or vmlinux) - renamed to ...efi - from the UEFI shell. In both cases, I get an error that the file were not recognized as an executable file by the UEFI Shell. I definitely have EFI_STUB on. Why is bzImage and vmlinux not recognized as executable by UEFI Shell? It appears that the bzImage.efi must not reside in a subdirectory but instead directly 1 level below /EFI (e.g. /EFI/gentoo/bzImage.efi). The kernel then loads but again stops after finding sdb. Somehow, it appears as if it were not trying to execute any init - why?

5) I successfully started grub2-x64.efi from within the UEFI Shell. I can even specifiy

```
linux (hd1,gpt5)/EFI/gentoo/boot/bzImage root=/dev/sda1

boot
```

on the grub command line. The kernel even boots, but then stops (blinking cursor, no response to anything but SysReq) after finding sdb. Curiously, when I SysReq+O, the system freezes after echoing "Power Off". What's wrong here? It turned out that it was a matter of configuring the kernel differently, requiring "Maintain a devtmpfs filesystem to mount at /dev" and "Automount devtmpfs at /dev, after the kernel mounted the rootfs" as described in the handbook for amd64.

As it should be apparent, I'd appreciate any ideas or whatever you may have. 

Thank you in advance,

MDLast edited by ManDay on Fri Oct 05, 2012 4:07 pm; edited 1 time in total

----------

## ManDay

All Problems solved. The crucial points are listed above in green. Eventually, the problem with the UEFI not loading the entry was due to a faulty path to the bootloader/kernel-with-efi-stub.

Turns out that efibootmgr doesn't modify entries, even if you specify   efibootmgr -b .... <args>. So you have to delete the boot entries and recreate them.

----------

## wrc1944

Thanks ManDay,

I'm not sure about "all problems solved," but this is very important information, as I suspect more and more motherboards are going to be using a UEFI bios, in  fact it might eventually become virtually impossible to even find a non-UEFI motherboard. 

(For reference, the info ManDay mentions is on  page is  http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=7 under Code Listing 3.3: Enabling devtmpfs support).

Just to clarify, does this mean if you're installing Gentoo as 32bit (or multi-lib) on a UEFI board you still need to use the amd64 handbook kernel options at Code Listing 3.3?

How is this  going to relate for those trying to dual boot Gentoo (or any Linux distro) on new UEFI hardware with windows 8 pre-installed?  I hope what I've been reading about Microsoft requiring all OEMs to require windows 8 UEFI "secure boot-loader" signing, thus effectively locking out Linux on your own hardware has been overly hyped up.

I'm concerned that this windows 8 UEFI "secure boot-loader" signing move might become a major problem for Linux users, as for most OEMs satisfying Linux is not a major priority. 

At first glance "secure boot-loader signing" with UEFI bios hardware might seem like a great idea, and it appears the Ubuntu people are "signing on" to this concept in their supposed deal with Microsoft, but I'm still worried this might be trouble for linux in general.  

On the other hand, can we assume that by simply enabling the kernel options in the amd64 handbook those doing Linux installs on clean (non-windows 8 ) UEFI bios equipped motherboards will have no problems?

----------

## srs5694

 *wrc1944 wrote:*   

> this is very important information, as I suspect more and more motherboards are going to be using a UEFI bios, in  fact it might eventually become virtually impossible to even find a non-UEFI motherboard.

 

This is already pretty much true. Whether they advertise it or not, most motherboards sold today implement UEFI. The ones that don't make a fuss over it usually have very poor UEFI implementations. (See my Web page on Gigabyte's Hybrid EFI, for instance.)

The good (and bad) news is that the vast majority of UEFI implementations also support BIOS-mode boots. This makes it possible to install everything in BIOS mode, if you so desire. This becomes problematic when installing Windows on a disk that over 2 TiB in size, but aside from that case, a BIOS-mode installation is usually the course of least resistance. OTOH, I say that this is bad news as well as good news because it complicates things. I've seen numerous posts from people who've ended up installing one OS in BIOS mode and another in EFI mode. This sort of thing can cause boot problems, since switching modes must usually be done in the firmware's setup utility, which is awkward at best, and some don't even provide a user option to do this. (I've just added BIOS-mode support to my rEFInd EFI boot manager, though, which might help in some of these cases.) Overall, I'm beginning to think that a clean break with no BIOS compatibility mode would have been better than the confusing and inflexible BIOS compatibility support we've got now.

 *Quote:*   

> Just to clarify, does this mean if you're installing Gentoo as 32bit (or multi-lib) on a UEFI board you still need to use the amd64 handbook kernel options at Code Listing 3.3?

 

I don't know about that, but I advise against a 32-bit installation on a 64-bit UEFI system, at least if you intend to boot in EFI mode. The reason is that EFI provides runtime support services to the OS, but those become unavailable if you run a 32-bit OS on a 64-bit computer. To the best of my knowledge, the only program that's currently affected by this is efibootmgr, which manages the EFI boot loader list. There are ways to get around the absence of this program, but it's better to not have to do this. As a practical matter, Linux's x86-64 support is good enough that there are, IMHO, few reasons to run a 32-bit version of Linux on an x86-64 system any more. (Note that this does not affect your ability to run 32-bit applications, should the need arise.)

 *Quote:*   

> How is this  going to relate for those trying to dual boot Gentoo (or any Linux distro) on new UEFI hardware with windows 8 pre-installed?  I hope what I've been reading about Microsoft requiring all OEMs to require windows 8 UEFI "secure boot-loader" signing, thus effectively locking out Linux on your own hardware has been overly hyped up.

 

This has been discussed to death here and elsewhere. Especially early on, there have been a lot of "Chicken Little" comments on the topic. The truth is much less sinister -- at least for now and on x86/x86-64 hardware. Microsoft's Windows 8 certification requirements include the ability of the user to disable Secure Boot on x86 and x86-64 hardware (but not on ARM), and that's the simplest way to deal with it. The first problem with this approach is that there's no standardized user interface, so to provide detailed instructions on doing it can be difficult. The second problem is that you lose the benefits of Secure Boot -- in other words, you slightly increase your risk of malware getting control of your computer, especially in Windows.

A second approach to the problem is to sign a boot loader, either with Microsoft's key (for $99, IIRC) or with your own (which you must then add to the firmware's key set yourself). Fedora's signing a boot loader with Microsoft's key with Fedora 18. In theory, individuals could sign a boot loader, too, but as of yet I know of no Linux utilities to help out, and if you use a non-Microsoft key, you'd need to add it to the firmware, which has the same issue with non-standardized user interfaces you get with disabling Secure Boot.

In the future, this could all become much worse; absent a clear statement in the UEFI specification that users must be able to disable or otherwise control Secure Boot, Microsoft is free to change their certification requirements in the future. Since all the major PC players want to have a "Windows-certified" sticker on their hardware, this could become a problem if Microsoft switches the requirement that Secure Boot can be disabled to say that it [/i]cannot[/i] be disabled. Even in this worst-case scenario, though, Linux has a strong enough position in the server field that I'm sure non-Windows-certified computers and motherboards will remain available. Being isolated to such a "ghetto," though, will certainly not be a good thing for Linux should it occur. (I'm hoping it won't, of course.)

 *Quote:*   

> On the other hand, can we assume that by simply enabling the kernel options in the amd64 handbook those doing Linux installs on clean (non-windows 8 ) UEFI bios equipped motherboards will have no problems?

 

Since this paragraph immediately follows several in which you ask about Secure Boot, it's not clear to me if you're asking about Secure Boot specifically or about UEFI generally.

I haven't studied the Gentoo handbook recently, but I doubt if it says much about Secure Boot. Certainly there are no kernel options that relate to it. If you need to work around Secure Boot issues, the workarounds won't be particularly kernel-related -- you'll need to disable it in the firmware or play games with signing boot loaders.

If you're asking about UEFI generally, then there are just a few kernel options that are important, like GPT support and another one that gives access to EFI runtime services. Setting these options appropriately is necessary, but far from sufficient, to get a trouble-free Linux installation on an EFI system. Broadly speaking, there are two major obstacles to installing Linux in EFI mode:

OS integration support -- Most distributions have been sluggish to address EFI issues in their installers and support tools. The result is installers that do weird things or that fail completely when presented with an EFI install. The good news for Gentoo users is that Gentoo has always had a less automated installation process, so there's less need for a Gentoo installer with a lot of EFI-specific know-how; that's your job (and the job of documentation authors).

EFI bugs -- Most (probably all) EFI implementations to date are infested with swarms of bugs. I've dealt with just a few of these on my four EFI-based computers and in my role as rEFInd's maintainer. These bugs can make both boot loaders and OS kernels do weird things. For instance, one bug I've encountered causes files to disappear from a boot loader's view, which can produce generic icons or a failure to list a boot option that should be available.

These problems are surmountable, and they're dropping in number and severity as time goes by. The last version or two of Fedora have had tolerable EFI support in their installers, for instance. I'm currently booting several computers exclusively in EFI mode, including the Gentoo box on which I'm typing this. It helps to know what you're doing, though; I've seen far too many forum posts from people who don't know anything about EFI and who get led down the garden path by attempting to apply BIOS principles to an EFI system and/or by blindly following a poorly-designed installer's recommendations. Unfortunately, EFI documentation is pretty hard to find. My own EFI Boot Loaders for Linux Web page attempts to cover some of this territory, especially with respect to boot loaders.

----------

## wrc1944

Thanks much, srs5694,

I appreciate the time you took providing all this great info.

I just ran across this, which makes things look much better: http://news.softpedia.com/news/Linux-Is-Now-Safe-From-Microsoft-s-UEFI-298774.shtml

Related links:

http://www.phoronix.com/scan.php?page=news_item&px=MTIwNDM

http://blog.hansenpartnership.com/easier-way-to-take-control-of-uefi-secure-boot-platform/

----------

## srs5694

I haven't yet read the details, but from the summaries, it sounds like the Linux Foundation is doing basically what Red Hat/Fedora is doing, but presumably in a way to make it usable by all Linux users. OTOH, what little I know suggests that this solution will make it possible to boot any boot loader, which essentially disables Secure Boot, since malware could masquerade as the boot loader. If this is correct, it's only a matter of time before this "pre-bootloader" is abused in this way and blacklisted. This would become a mess, so I'm hoping that I'm missing something.

----------

## Silmano

 *srs5694 wrote:*   

> This would become a mess, so I'm hoping that I'm missing something.

 

You need two basic things to modify UEFI boot:

1) Write access to UEFI partition.

2) Root access to run efibootmgr and add the new bootloader and change the boot order.

If a normal user can access both in your machine, then is an open door to all kinds of trouble. Just secure both and there shouldn't be any problem.

----------

## srs5694

 *Silmano wrote:*   

>  *srs5694 wrote:*   This would become a mess, so I'm hoping that I'm missing something. 
> 
> You need two basic things to modify UEFI boot:
> 
> 1) Write access to UEFI partition.
> ...

 

This assumes a Linux-only system, but Secure Boot is most important on Windows computers and on those that run multiple OSes. On such computers, you can't rely exclusively on Linux security features to prevent mucking with the boot process.

----------

## _______0

you need to add something here:

```
Symbol: CMDLINE_BOOL [=y]
```

----------

