gummibootx64.efi won't boot

pgoetz · 2015-01-17 09:37:00

I've been using gummiboot successfully on a number of systems (e.g. as in this example), but recently ran into a problem on a supermicro server with an SSD boot drive. The installation goes smoothly, and the boot entry shows up in the system's firmware, but the system always boots into an interface allowing me to choose either booting the UEFI shell or into the firmware; i.e. it's not actually booting. I confirmed this by booting into the system UEFI shell and running gummibootx64.efi by hand:

boot into UEFI shell
mark -r to identify all potential boot devices (in this case fs0)
fs0:
cd EFI
cd gummiboot
gummibootx64.efi

takes me to what is basically a firmware prompt. My guess is this might have something to do with the entry files in /boot/loader/entries, and points to my confusion about how gummiboot actually uses these files. So far I've just made such a file; e.g.

[root@ibis entries]# cat arch1.conf
title     Arch Linux1
linux     /vmlinuz-linux
initrd    /initramfs-linux.img
options   root=/dev/sdc3 rw ipv6.disable=1

and it's worked. Now that it's not working, I'm not sure how to debug this, given that I don't understand exactly how gummiboot decides which one of these to use if there are several (in this particular case, though, I only have one and it's still not working).

I am able to UEFI boot from a USB Arch installer device, so UEFI booting is working in general.

Any thoughts on how to debug this?

Head_on_a_Stick · 2015-01-17 10:03:32

What is the content of /boot/loader/loader.conf?

pgoetz · 2015-01-17 11:15:18

I don't have one set up. My understanding is that loader.conf is used to configure a gummiboot splash screen menu on boot. All the installations I've done using gummiboot so far just boot into a single OS, so I haven't bothered with loader.conf, and (with this exception) the systems boot fine anyway.

Head_on_a_Stick · 2015-01-17 11:43:02

That's funny 'cos I didn't know it would boot without one...

Create one & see if that fixes it:

default arch1
timeout 3

The timeout makes the menu show up and this gives an option to boot ijnto the EFI shell.

There may be a problem with using /dev/sdc as the root identifier -- try using the UUID (or PARTUUID) instead.

Also, is /boot (along with the kernel image & initramfs) mounted at the EFI system partition?

pgoetz · 2015-01-17 11:54:29

Thanks, those are some great suggestions. I'm not quite sure what you mean by "is /boot (along with the kernel image & initramfs) mounted at the EFI system partition?", but yes /boot is a FAT32 EF00 labeled partition mounted under / by default and contains kernel/init-ramfs images.

Come to think of it, this system has 50(!) disks, so it very well might be the case that someone somewhere is getting confused about /dev/sdc -- I'll try using the UUID or PARTUUID instead.

Head_on_a_Stick · 2015-01-17 12:40:19

pgoetz wrote:

I'm not quite sure what you mean by "is /boot (along with the kernel image & initramfs) mounted at the EFI system partition?"

When you were installing the system, did you run these commands:

# mount /dev/sd<x><a> /mnt
# mkdir /mnt/boot
# mount /dev/sd<x><b> /mnt/boot

Where <x>=target drive letter and <a>&<b>=root & EFI system partition numbers.
https://wiki.archlinux.org/index.php/Be … partitions

If you chroot into your unbootable system, you can see the mountpoints using:

lsblk -f

My output for this gives:

empty@Arch ~ % lsblk -f
NAME   FSTYPE LABEL  UUID                                 MOUNTPOINT
sda                                                       
├─sda1 vfat          9669-102D                            /boot
├─sda2 ext4          dc7b15ff-6725-4918-b0fd-4bfcc5560ffa /
├─sda3                                                    
├─sda4 ext4   Debian 191c641f-66ed-47fc-9adb-df2b189ed367 /debian
└─sda5 swap          7fac1c92-59df-40c9-b602-49cba7b5110d [SWAP]

As you can see /boot has the EFI system partition (sda1) as the mountpoint

With gummiboot, only files in the ESP can be parsed.

pgoetz · 2015-01-17 22:50:30

Oh yeah; yes, I definitely did this. I think this is my 20th or so Arch install, if you count virtual machines. <:)

I'll try your other suggestions next week. I won't have access to the machine until Tuesday.

Last edited by pgoetz (2015-01-18 11:58:04)

Arch Linux

#1 2015-01-17 09:37:00

gummibootx64.efi won't boot

#2 2015-01-17 10:03:32

Re: gummibootx64.efi won't boot

#3 2015-01-17 11:15:18

Re: gummibootx64.efi won't boot

#4 2015-01-17 11:43:02

Re: gummibootx64.efi won't boot

#5 2015-01-17 11:54:29

Re: gummibootx64.efi won't boot

#6 2015-01-17 12:40:19

Re: gummibootx64.efi won't boot

#7 2015-01-17 22:50:30

Re: gummibootx64.efi won't boot

Board footer