# Gentoo will not boot with EFI

## Lovot

I tried everything, and I can not get Gentoo to boot with EFI. All of EFI related ***************** is enabled in the kernel, the kernel functions perfectly on non-EFI systems, but no matter what I do:

1 When switching from EFI-VGA to radeondrmfb, the boot process freezes. Every. Single. Time. nomodeset gets past this problem, but when this setting is used with non-EFI systems, it seems to prevent the radeon drivers from functioning since KMS is disabled, so this doesn't seem like an actual solution, just a way to uncover problem 2.

2 The kernel can't find it's root filesystem, I even drew it a map. The UUID is correct, and it boots properly on non-UEFI systems.

I tried booting the kernel with the root filesystem's ID embedded in the kernel as outlined here: https://wiki.gentoo.org/wiki/EFI_stub_kernel, and when that didn't work, I embedded the initramfs in the kernel, and directly booted the kernel instead of going through GRUB, this did not work because of problem 1, and problem 2 persists when booting via GRUB, so I doubt GRUB is at fault here.

On a desktop I always have the option to use legacy boot, but on a laptop the legacy boot option does not work, for SOME REASON they didn't think it was important to have full legacy support on laptops. The laptops I have are basically unusable because of this.

Things to note: /boot, /, /usr, and /var are located on separate btrfs filesystems, which isn't a problem with legacy boot.

[Moderator edit: minor cleanup. -Hu]

----------

## Roman_Gruber

 *Quote:*   

> Things to note: /boot, /, /usr, and /var are located on separate btrfs filesystems, which isn't a problem with legacy boot.

 

Lets assume EFI => UEFI

Than boot has to be vfat and not btrfs

Which bootloader do you use?

When you use grub, do you see the grub2 bootprompt?, grub boot menu?

How is your partiton layout

How is your bootloader config

lspci -kk; upload your kernel.config so others can have a loook into

--

I assume you already read gentoo wiki / gentoo handbook and tried those

--

Personal opinion.

Keep boot at ext2 for grub1 on mbr boxes, vfat on uefi boxes. keep the partition layout for uefi boxes as suggested by the gentoo wiki.

No need for btrfs on boot anyway, rarely in use, no benefit, except issue / troubles. use what the mayority uses, thats ext2 for older boxes, vfat for uefi boxes (windows world => fat32)

--

Some are using other bootloaders, maybe try those too.. 

--

My way is to install a binary distro and reuse the bootloader and hack in my gentoo startup menu by hand. Works the fastest! You can nuke later the binary distro or keep it. ... up to you. Lazy approach ! Grub2 syntax is kinda easy, and you do not have a need to update the bootloader anyway.

----------

## Lovot

 *Roman_Gruber wrote:*   

>  *Quote:*   Things to note: /boot, /, /usr, and /var are located on separate btrfs filesystems, which isn't a problem with legacy boot. 
> 
> Lets assume EFI => UEFI
> 
> Than boot has to be vfat and not btrfs
> ...

 

1 The ESP, which either contains a bootloader, or a kernel has to be vfat, and properly marked, everything else can be whatever. I know this works because I previously had Arch working on the exact same machines with a similar partitioning scheme, and the setup I have actually loads the kernel, it just screws up after that. the kernel/initramfs should have the drivers needed to access the btrfs filesystems, otherwise legacy boot would fail. I boot the install on a desktop with very similar hardware, change things, then try to boot on the laptop again, since the desktop has complete legacy boot support, there are no problems booting on it, in case anyone was wondering.

2 i tried both grub2 (with the boot menu and everything), and direct boot via EFI (if the kernel is labelled bootx64.efi, and placed in ESP/EFI/Boot/, it can be booted directly by the BIOS), both methods had the exact same problem.

3 partition layout is mostly irrelevant since it works with legacy. I think I tried putting it all on one ext4 filesystem once to see if btrfs, or the partitioning scheme were the problem, it was not. but here it is: 

    /dev/sda1 : BIOS GRUB (required for legacy boot, and flagged accordingly)

    /dev/sda2 : ESP (required to boot on UEFI systems, flagged accordingly)

    /dev/sda3 : boot (btrfs, unflagged since it can't be booted directly, GRUB has no problems accessing it though)

    /dev/sda4 : / (btrfs)

    /dev/sda5 : /usr (btrfs)

    /dev/sda6 : /var (btrfs)

bootloader config is standard, booting the kernel with no bootloader at all had the exact same issues, so this is 100% a kernel/UEFI problem.

one laptop still has Arch on it, here's the output of 'lspci -kk' when running Arch, I also use the GRUB Arch installed to boot the gentoo install on this laptop, the direct boot setup is on the other laptop, but since they have nearly identical hardware, anything that works on one will work on the other:

```

# lspci -kk

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex

   Subsystem: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8650G]

   Subsystem: Lenovo Device 397c

   Kernel driver in use: radeon

   Kernel modules: radeon

00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio Controller

   Subsystem: Lenovo Device 397c

   Kernel driver in use: snd_hda_intel

   Kernel modules: snd_hda_intel

00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port

   Kernel driver in use: pcieport

   Kernel modules: shpchp

00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port

   Kernel driver in use: pcieport

   Kernel modules: shpchp

00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 09)

   Subsystem: Lenovo Device 397c

   Kernel driver in use: xhci_hcd

   Kernel modules: xhci_pci

00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode]

   Subsystem: Lenovo Device 397c

   Kernel driver in use: ahci

   Kernel modules: ahci

00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11)

   Subsystem: Lenovo Device 397c

   Kernel driver in use: ohci-pci

   Kernel modules: ohci_pci

00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11)

   Subsystem: Lenovo Device 397c

   Kernel driver in use: ehci-pci

   Kernel modules: ehci_pci

00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11)

   Subsystem: Lenovo Device 397c

   Kernel driver in use: ohci-pci

   Kernel modules: ohci_pci

00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11)

   Subsystem: Lenovo Device 397c

   Kernel driver in use: ehci-pci

   Kernel modules: ehci_pci

00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 16)

   Subsystem: Lenovo Device 397c

   Kernel modules: i2c_piix4

00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (rev 01)

   Subsystem: Lenovo Device 397c

   Kernel driver in use: snd_hda_intel

   Kernel modules: snd_hda_intel

00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11)

   Subsystem: Lenovo Device 397c

00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge (rev 40)

00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 0

00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 1

00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 2

00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 3

   Kernel driver in use: k10temp

   Kernel modules: k10temp

00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 4

00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 5

01:00.0 Ethernet controller: Qualcomm Atheros QCA8172 Fast Ethernet (rev 10)

   Subsystem: Lenovo Device 3806

   Kernel driver in use: alx

   Kernel modules: alx

02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)

   Subsystem: Lenovo Device 3218

   Kernel driver in use: ath9k

   Kernel modules: ath9k

```

kernel config: 

http://pastebin.com/6Z4eKnHM

was too big for the forum, but not quite so large that pastebin would require money to hold on to it.

----------

## Roman_Gruber

 *Quote:*   

>  it just screws up after that.

 

Please specify

 *Quote:*   

> 3 partition layout is mostly irrelevant since it works with legacy. I think I tried putting it all on one ext4 filesystem once to see if btrfs, or the partitioning scheme were the problem, it was not. but here it is: 

 

No comment ...

 *Quote:*   

> bootloader config is standard, booting the kernel with no bootloader at all had the exact same issues, so this is 100% a kernel/UEFI problem.
> 
> 

 

No, Its more a misconfiguration of kernel incommand line, or using proper kernel paramter in your bootloader

When you want to use the "bios" to load your stuff, you have to implement everything in your kernel, including kernel command line options, initramfs, microcode ...

----------

## Lovot

 *Quote:*   

> Please specify

 

    The screw ups were specified in the original post: the transition from EFI VGA to radeondrmfb causes the boot process to freeze, unless nomodeset is passed to the kernel by the bootloader, nomodeset prevents the radeon drivers from functioning because it disables KMS, which is bad. If nomodeset is used to bypass the original problem, the second problem shows itself: the kernel is unable to find/mount the root filesystem, and it drops down to busybox, this is definitely not a bootloader problem because the configuration works fine with legacy boot. 

    Let me make this clear: no problems come up when using legacy boot with this exact same HDD. The uuids, the drivers, everything needed for legacy boot is loaded into the kernel, and everything I could find in the handbook/wiki has been loaded for EFI boot. After the kernel is loaded, there should be no difference, but there clearly is. My partitioning scheme has absolutely nothing to do with this, i even checked the uuid busybox claims to be looking for against blkid to ensure it was trying to load some non-existent partition. And again, Arch is able to boot using the same partitioning scheme on the same machine with no issues, and the same arguments passed to the kernel by the bootloader. There is some component missing from my Gentoo kernel, and I have not been able to find that missing component using the handbook, or wiki.

 *Quote:*   

> No, Its more a misconfiguration of kernel incommand line, or using proper kernel paramter in your bootloader

 

Post the ones you use for UEFI boot on a machine running radeon drivers. The kernel is passed the same stuff with legacy boot or EFI boot, on one it works, on the other it doesn't. 

```

menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-b07fcece-e7e0-4901-b46d-510f93294759' {

   load_video

   if [ "x$grub_platform" = xefi ]; then

      set gfxpayload=keep

   fi

   insmod gzio

   insmod part_gpt

   insmod btrfs

   set root='hd0,gpt3'

   if [ x$feature_platform_search_hint = xy ]; then

     search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  8e4c3e66-2d9f-4de0-bd57-c13789c1a199

   else

     search --no-floppy --fs-uuid --set=root 8e4c3e66-2d9f-4de0-bd57-c13789c1a199

   fi

   echo   'Loading Linux 4.7.5-gentoo ...'

   linux   /vmlinuz-4.7.5-gentoo root=UUID=b07fcece-e7e0-4901-b46d-510f93294759 rw 

   echo   'Loading initial ramdisk ...'

   initrd   /initramfs-genkernel-x86_64-4.7.5-gentoo

}

```

 *Quote:*   

> When you want to use the "bios" to load your stuff, you have to implement everything in your kernel, including kernel command line options, initramfs, microcode ...

 

In my original post I clearly stated that I embedded the entire initramfs, and the root filesystem's ID inside kernel as the wiki page I posted specified. This did not change anything. I posted the configuration as well if you have any more configuration questions.

----------

## Ant P.

 *Quote:*   

> 
> 
> ```
> CONFIG_AGP=y
> 
> ...

 

These do nothing on a PCI-Express system.

 *Quote:*   

> 
> 
> ```
> CONFIG_DRM_I915=y
> 
> ...

 

It's highly unlikely you have an Intel GPU on a system with an AMD fam15h CPU.

 *Quote:*   

> 
> 
> ```
> CONFIG_FB_CMDLINE=y
> 
> ...

 

These are ancient vesa framebuffer drivers and support options. The only thing that should be enabled in this entire submenu on a modern system is efifb and/or simplefb.

 *Quote:*   

> 
> 
> ```
> CONFIG_DRM_VMWGFX=y
> 
> ...

 

These are drivers for running the kernel from inside a VM and using a USB-to-VGA adapter.

 *Quote:*   

> 
> 
> ```
> CONFIG_DUMMY_CONSOLE=y
> 
> ...

 

That doesn't look intentional, unless you were trying to get a blank display.

Disable most/all of these unless you can justify the need for them, then try again.

Lastly, build the one display driver you *are* using (radeon) as a module. This will rule out missing firmware.

----------

## chithanh

Assuming you have firmware for radeon built correctly into your kernel. If not, then the boot process may hang for 60 seconds per missing firmware file.

Handover from efifb to radeon kms sometimes works and sometimes doesn't. I suggest to disable CONFIG_FB_EFI in case of problems.

If you require console output during early boot, you can use CONFIG_FB_SIMPLE and CONFIG_X86_SYSFB but if not, better leave these two disabled too.

----------

## Lovot

Interestingly, chithanh, and Ant P., your suggestions enabled me to successfully direct boot via EFI on the desktop, BUT the laptops refuse to cooperate. 

Firstly, it appears device scanning works differently on each UEFI system, the desktop only understands the /dev/sdxx format, so unless "root=/dev/sda4" is embedded in the kernel, the desktop will drop to busybox. I figured this out by examining busybox's /dev directory when used on the desktop vs when it's on the laptop: on the desktop /dev/disk does not exist at all, however on the laptop /dev/disk/by-id is present. The laptops have refused any attempts to direct it to the correct root filesystem thus far. I suspect my kernel's disk scanning capabilities are severely impaired when booting with EFI. I have no idea why this would be, but it's the cause of this particular problem.

Secondly, the radeon drivers work perfectly on the desktop, if it is built as a module it just gives me a black screen though. Unfortunately the drivers continue to have issues with the laptops, the dektop and laptops have different video cards, even though the desktop has an A10 APU, just like the laptops, the laptops have an Radeon HD 8650G GPU based on the Richland architecture, which I can't find on the radeon wiki page, while the desktop has a R7. I included the firmware for several current architectures in an attempt to cover my bases when I first got the radeon drivers running, but I can't be sure if I have the correct firmware loaded for the laptops since Richland isn't on the wiki. I may have to dig around in the firmware directory after I get some sleep to see if I can find anything marked as Richland in there.

----------

## Buffoon

You can use PARTUUID, it will work.

----------

## Lovot

 *Buffoon wrote:*   

> You can use PARTUUID, it will work.

 

Just tried that again, in case a typo caused it to fail the first time 

```
root=PARTUUID=string-of-characters-here
```

It was definitely the correct PARTUUID too, the ability to scan partition uuids seems to be missing, or inactive. Would that feature need to be specially included in a genkernel ramdisk?

----------

## Ant P.

PARTUUID is a scheme the kernel understands natively, and doesn't need any help from initramfs or udev.

What does blkid say?

----------

## Lovot

 *Ant P. wrote:*   

> PARTUUID is a scheme the kernel understands natively, and doesn't need any help from initramfs or udev.
> 
> What does blkid say?

 

this is what's in the kernel, i obtained the id with gdisk:

```
CONFIG_CMDLINE="root=PARTUUID=3DF48DCF-F41B-444E-B16C-995A86865D23"
```

this is blkid:

```
/dev/sda4: LABEL="Lap-Gentoo-Core" UUID="b07fcece-e7e0-4901-b46d-510f93294759" UUID_SUB="90bad75a-e773-47fa-a39a-c0cd90f1cf97" TYPE="btrfs" PARTLABEL="Lap-Gentoo-Core" PARTUUID="3df48dcf-f41b-444e-b16c-995a86865d23"
```

unless it's case sensetive, the partuuids are a perfect match.

----------

## v_andal

 *Lovot wrote:*   

> 
> 
> Secondly, the radeon drivers work perfectly on the desktop, if it is built as a module it just gives me a black screen though.

 

My desktop has AMD card and Intel Card. I've tried to use only AMD card and was getting black screen. After I've enabled both cards in kernel things started to work.

----------

## Lovot

I pinned the first problem, the GPU in the laptops apparently uses the  ARUBA microcode, which was not included in the pile of microcode i originally included in the kernel, so that's solved. Still no luck with the root filesystem, but that's one down. I probably would have never noticed without your help chithanh, thanks!Last edited by Lovot on Thu Oct 06, 2016 11:07 pm; edited 1 time in total

----------

## Lovot

OK, got around the root filesystem problem, the only change was plugging the drive into the internal SATA port instead of using a SATA>USB converter. This is very strange since the Arch installs were able to boot from USB on these laptops, and the Gentoo drive was able to boot from USB on the desktop. When I got dropped into busybox on Laptop2, I noticed that /dev/ had no drives in it, and Laptop1, only had /dev/sdaX, dispite 2 HDDS being attached. i was only able to check /dev/ on Laptop2 after the radeon problem was solved, which is how I got the idea to connect the drive internally. I would still like to know why USB HDDs are not being scanned when booting from UEFI, since that's how I usually do backups and maintenance.

----------

## Ant P.

That sounds like something you might need a rootwait or rootdelay=5 in the boot line for.

----------

## Lovot

 *Ant P. wrote:*   

> That sounds like something you might need a rootwait or rootdelay=5 in the boot line for.

 

I modded my built in command line to this, it doesn't wait for the root device to show, it skips directly to busybox. What did I do wrong?

```
CONFIG_CMDLINE="root=PARTUUID=3df48dcf-f41b-444e-b16c-995a86865d23 rootwait rw rootflags=defaults,autodefrag,compress=lzo rootfstype=btrfs"
```

----------

## Roman_Gruber

USB / UEFI - BIOS Implementations are not the same for every hardware platform. USB is not USB for every platform, different controllers, different firmware, different bugs, different versions. Different UEFI - Bios.

Than I read USB -> SATA converter, which just implies an external usb drive case. These are buggy in general, have issues. Slow to boot up, buggy drivers, do not report smart values sometimes.

The net is full with bug reports regarding external USB "generic" cases

Than you mention arch linux ... did you checked the initramfs, the implemented kernel parameters in use?

As the other guy already suggested a delay for your bootlaoder, so the drive may get ready or is ready after that time delay. Or using busybox whatever so the drive can be used properly.

 *Quote:*   

> When I got dropped into busybox on Laptop2, I noticed that /dev/ had no drives in it, 

 

Missing support for hardware, just that simple, or no hardware present

 *Quote:*   

> only had /dev/sdaX, dispite 2 HDDS being attached. 

 

ehm

should be usually

ide or sata based optical drive

internal HDD

and than as you mentioned the external usb case. so probably the usb driver not loaded for the external case ...

 *Quote:*   

> I would still like to know why USB HDDs are not being scanned when booting from UEFI, since that's how I usually do backups and maintenance.
> 
> USB is not USB
> 
> Just that simple
> ...

 

----------

## Lovot

 *Roman_Gruber wrote:*   

> USB / UEFI - BIOS Implementations are not the same for every hardware platform. USB is not USB for every platform, different controllers, different firmware, different bugs, different versions. Different UEFI - Bios.
> 
> Than I read USB -> SATA converter, which just implies an external usb drive case. These are buggy in general, have issues. Slow to boot up, buggy drivers, do not report smart values sometimes.
> 
> The net is full with bug reports regarding external USB "generic" cases
> ...

 

it's a STARTECH converter (looks like the actual chip is from JMicron, most likely a JMB355), the only time there is any trouble when using it is booting Gentoo with UEFI, but not Arch, or Linux Mint with UEFI on the same machines with the same converter. The desktop will even boot the exact same Gentoo kernel with legacy boot without issue, but with UEFI boot, /dev is only partially populated, as in /dev/sdax is present, but not /dev/disk, and PARTUUIDs don't work. Placing /dev/sda4 in the built in command line results in a normal boot on this machine. Since the drive is detected on boot, but /dev/disk has not been created yet, it looks like the kernel is trying to boot before it's done getting /dev populated, which is why I added rootwait:

 *Quote:*   

> rootwait	[KNL] Wait (indefinitely) for root device to show up.
> 
> 			Useful for devices that are detected asynchronously
> 
> 			(e.g. USB and MMC devices).

 

rootwait should prevent the kernel from dropping in to busybox when it can't find the root device, since it's supposed to wait indefinitely for it to show up, but it doesn't. this means I have somehow screwed up the built in kernel command line.

Oh, and the BIOS has no trouble finding the ESP when it's on the other side of the converter, neither does GRUB. This indicates all of the machines support this converter quite well.

----------

## Lovot

just found out that /dev/ isn't completely populated when booting from the internal SATA interface either, nor do PARTUUIDs work. I can't be the only person that these things don't work for.

----------

