[Solved] Various UEFI problems

Fitzwilliam · 2013-06-27 22:28:23

Hi,

I've been away from Arch for a while, and I'm having some trouble getting back into the swing of things. I'm trying to install it to a 64GB SSD on a UEFI motherboard, the ASUS P8Z68-V PRO. Not the latest mobo, I know, but it works fine for Windows. The install went smoothly until I had to install the boot entries. Efibootmgr kept telling me that the disk had a valid GPT partition table but an invalid PMBR; that problem persists even after two formats with gdisk and GParted. I also tried gummiboot, but it kept failing to create the boot entry. I finally managed to get efibootmgr to make the entry despite the invalid PMBR by booting with "efi_no_storage_paranoia", but now my mobo has a problem. It shows the Arch Linux boot entry, but it says that the device is not present, and when I try to boot from it, it goes straight back to the UEFI menu. ;_;

Basically, I am really confused about how to get UEFI to work. I've read the Beginners' and Installation Guides, as well as the pages on SSDs, UEFI, and bootloaders, to no avail. If someone could help me or point me in the direction of instructions, I'd really appreciate it.

Last edited by Fitzwilliam (2013-06-28 21:06:19)

cfr · 2013-06-27 22:42:59

Welcome back.

gummiboot does not create entries in the EFI boot menu and it is not meant to. So it is not surprising if it failed to do so.

Can you post the output of gdisk -l /dev/sdX where X is the appropriate letter for you disk?

Also, post the output of efibootmgr -v.

Fitzwilliam · 2013-06-28 00:37:19

Hey, thanks for the reply! Here are the outputs.

As far as I can tell, this one looks as I meant it to look.

gdisk -l /dev/sdb

GPT fdisk (gdisk) version 0.8.6

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 125045424 sectors, 59.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 694C4EE2-3887-4A1E-96F3-EF9C54FFBE72
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125045390
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  efi
   2         1050624        42993663   20.0 GiB    8300  root
   3        42993664       125045390   39.1 GiB    8300  home

This one is weird. Are all of those dots supposed to be there?

efibootmgr -v

BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0000,0002,0003,0004,0001
Boot0000* Arch Linux	HD(1,800,32000,dc693b21)File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.b.2. .r.o. .q.u.i.e.t. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g...
Boot0001* CD/DVD Drive 	BIOS(3,0,00)AMGOAMNO........o.T.S.S.T.c.o.r.p. .D.V.D.W.B.D. .S.H.-.B.1.2.3.L....................A...........................>..Gd-.;.A..MQ..L.8.R.0.6.G.6.B.E.0.7.2.2.6.5. . . . . . ......AMBO

Thanks again.

cfr · 2013-06-28 01:53:29

The dots are correct. I notice that your boot order includes non-existent entries which seems rather odd, especially since 3 such entries have higher priority than an existing one. Still, that shouldn't be a problem given that your default entry is one of the existent ones.

How many disks do you have? Are you sure that /dev/sdb2 is correct when you actually boot?

I take it you are mounting your ESP at /boot?

Fitzwilliam · 2013-06-28 02:07:36

I have five disks (2x64GB SSDs, 1x3TB HDD, 1x2TB HDD, and 1x1TB HDD) and a BD drive, plus a 4GB flash drive for the installer itself. I have...a lot of media. I'm not sure what you mean about sdb2's being correct when I actually boot. The guide said to plug in the root partition of the drive you installed to when you ran efibootmgr. I know that /dev/sdb is the disk I want to install to (the second SSD), and I know that /dev/sdb2 is the root partition of that drive. Should I give efibootmgr the /boot partition instead? I am mounting it at /boot.

Edit: I hope I'm making sense. I'm trying to be clear, but the jargon is confusing me somewhat.

Last edited by Fitzwilliam (2013-06-28 02:08:49)

WonderWoofy · 2013-06-28 03:11:46

I think what cfr is saying is that from boot to boot there is no reliable way to know that a given disk will be sdb. This is why it has become the standard for udev to create the /dev/disk/by-* stuff so that you can have paths that will ensure that you are getting the disk that you want. Either that or you could use root=UUID=<root-UUID-here> or even better, you can label the partition and use either root=/dev/disk/by-label/<root-label> or root=LABEL=<root-label>.

I did notice that in your efibootmgr entry, you have a very short uuid for the ESP. There is the section (1,800,.....,....) where the fourth section is the UUID of the ESP. Here is what my entry looks like:

# efibootmgr -v
<snip>
Boot0017  Arch Linux (CK Kernel)	HD(1,800,200000,664909aa-c06a-45cb-b67c-9e533c8d057f)File(\EFI\arch\vmlinuz-linux-ck.efi)r.o.o.t.=./.d.e.v./.m.a.p.p.e.r./.v.o.l.g.r.p.0.-.r.o.o.t._.a.r.c.h. .a.d.d._.e.f.i._.m.e.m.m.a.p. .i.n.i.t.r.d.=.\.E.F.I.\.a.r.c.h.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x.-.c.k...i.m.g. .q.u.i.e.t. .a.c.p.i._.o.s.i.=.".!.W.i.n.d.o.w.s. .2.0.1.2.". ...

Notice the numbers after 'HD', where there is an actual valid UUID after the fourth comma. I'm not sure why you are not getting that.

Edit: Honestly, I think it is much easier to use gummiboot. The advantages of using a boot manager far outweight and potential speed gain from a direct boot. My machine, for example, potentially took 12ms longer by using gummiboot on its last boot. This is the amount of time it takes to use gummiboot as a "middleman". When you install gummiboot, it creates an efibootmgr entry for you using the gummiboot command. Can you either reinstall it and let it do its thing, creating an entry, or use (as root) "gummiboot install" and then run "efibootmgr -v" to see what it made?

Last edited by WonderWoofy (2013-06-28 03:15:23)

Fitzwilliam · 2013-06-28 03:20:38

See, I tried using gummiboot after efibootmgr failed the first time. It kept giving me this:

Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/gummiboot/gummibootx64.efi.
Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/BOOT/BOOTX64.EFI.
Failed to create EFI Boot variable entry: No such file or directory

I looked it up, and there's a bug posted on the Arch tracker about this, but the solution is a little above my pay grade. It's been a few years since I used Linux regularly, and the guy is a bit vague about how exactly he fixed it.

WonderWoofy · 2013-06-28 03:28:01

So since you now have gummiboot in the /boot/EFI/boot/bootx64.efi spot, can you now try to boot that particular device itself (like you would do if you are booting in bios mode), but also make sure that bios emulation is either fully disabled, or UEFI is somehow given priority?

Keep in mind that in order for gummiboot to take you to its menu, I am pretty sure you do have to have a minimal configuration for it (like most bootlaoders). This would be the /boot/EFI/loader/loader.conf file with just the "default" line and "timeout 15". You can eventually have whatever timeout you want, but for now we need to make sure something is going to show up.

Fitzwilliam · 2013-06-28 05:48:07

Well, I made the config file, and it still wouldn't work. So, I created an entry for Gummiboot with efibootmgr; it's what the wiki says to do if you get the bug I mentioned. Now, not only does my Arch install still not boot, but also my Windows install can no longer find winload.exe. The Gummiboot entry in my mobo's boot menu still says "drive not present," just like with the last entry. I'm really at my wit's end at this point. Good thing I backed up C:\ before I started this .

Edit: Typo.

Last edited by Fitzwilliam (2013-06-28 05:49:45)

srs5694 · 2013-06-28 16:45:47

First, the efibootmgr errors make it sound like you've got either a defective SSD or a problem with the GPT data structures that "gdisk -l" didn't reveal. I recommend you try to eliminate the second possibility first, by using gdisk's "v" option, or "sgdisk -v /dev/sdb". That will run the GPT fdisk verification features, which detect a number of subtle and not-so-subtle GPT errors. If you find such an error, you can try to correct it, as described here or with help from us (and me in particular, since I wrote GPT fdisk).

If gdisk doesn't show any errors, then my suspicion is that you've got a defective SSD, or perhaps a problem elsewhere in the hardware, firmware, or driver chain between efibootmgr and the SSD. This will be more of a pain to identify and correct, and may well require replacing hardware.

Second, if efibootmgr isn't working, the next thing to try is the bcfg command in an EFI version 2 shell. This is described in the Arch wiki. You'll need to install a suitable shell (booting it from a USB flash drive can work pretty easily). Unfortunately, efibootmgr (or perhaps the kernel code upon which it relies) is not 100% reliable; it works fine on some EFIs, but not on others. The EFI shell's bcfg command seems to be more reliable.

Fitzwilliam · 2013-06-28 17:38:46

I figured it out! First, I had to boot with the "efi_no_storage_paranoia" kernel option. Thin, I ran:

modprobe efivars
mount -t efivarfs none /sys/firmware/efi/efivars
gummiboot update

Gummiboot created an EFI entry without any complaining, and my mobo boots it perfectly. Windows still appears to be borked, but I can work on that. Thanks, everyone, for all of your help.

jasonwryan · 2013-06-28 20:12:35

Nice. Please remember to mark the thread as [Solved] by editing your first post and prepending it to the title.

WonderWoofy · 2013-06-28 20:43:29

If windows is booting via UEFI, then you simply need to make a gummiboot entry that points to the windows *.efi application. It is probably located somewhere like /boot/EFI/microsoft. If it is booting with bios compatibility, you need to have a bios bootloader that can chainload to the windows system partition.

Arch Linux

#1 2013-06-27 22:28:23

[Solved] Various UEFI problems

#2 2013-06-27 22:42:59

Re: [Solved] Various UEFI problems

#3 2013-06-28 00:37:19

Re: [Solved] Various UEFI problems

#4 2013-06-28 01:53:29

Re: [Solved] Various UEFI problems

#5 2013-06-28 02:07:36

Re: [Solved] Various UEFI problems

#6 2013-06-28 03:11:46

Re: [Solved] Various UEFI problems

#7 2013-06-28 03:20:38

Re: [Solved] Various UEFI problems

#8 2013-06-28 03:28:01

Re: [Solved] Various UEFI problems

#9 2013-06-28 05:48:07

Re: [Solved] Various UEFI problems

#10 2013-06-28 16:45:47

Re: [Solved] Various UEFI problems

#11 2013-06-28 17:38:46

Re: [Solved] Various UEFI problems

#12 2013-06-28 20:12:35

Re: [Solved] Various UEFI problems

#13 2013-06-28 20:43:29

Re: [Solved] Various UEFI problems

Board footer