[SOLVED] EFI system partition fails to boot

gizzard · 2014-08-02 19:45:56

Help! I was booting with UEFI and grub without any problems until I moved the entire system from one case to another, which necessitated clearing the CMOS and unplugging all the hard drives. Now, I cannot see any grub entries in my BIOS boot menu. Motherboard is an Asrock H77m with the most recent BIOS.

I can boot using a LiveUSB and still see all the original partitions intact:

root@archiso ~ # lsblk
NAME			TYPE
sda			disk
-sda1			part
-sda2			part
--vol_ssd_1-root	lvm
--vol_ssd_1-var		lvm
--vol_ssd_1-home	lvm
sdb			disk
-sdb1			part
--vol_sd_160-recordings	lvm
sdc			disk
-sdc1			part
--vol_wd_640-movies	lvm
--vol_wd_640-workspace	lvm
sdd			disk
-sdd1			part	/run/archiso/bootmnt
-sdd2			part
loop0			loop	/run/archiso/sfs/root-image
loop1			loop
-arch_root-image	dm
loop2			loop
-arch_root-image	dm

There is one SSD (sda) and two HDD (sdb and sdc), and all were using LVM partitions, except for the EFI system partition on /dev/sda1 which is still intact:

root@archiso ~ # parted /dev/sda
(parted) p
Model: ATA ST240FP0021 (scsi)
Disk /dev/sda: 240GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: pmbr_boot

Number	Start	End	Size	File system	Name		Flags
1	1049kB	269MB	268MB	fat32		EFI System	boot
2	269MB	240GB	240GB			Linux LVM	lvm

gdisk also shows that MBR is protective and GPT is present on /dev/sda

I mounted all the partitions, entered chroot, and reinstalled grub using a new bootloader ID. In doing so, the new ID appears in the BIOS boot menu but it still does not boot from the /dev/sda1 partition.

If I boot to the UEFI Shell v2.0, here's what map shows (I am truncating the UUIDs somewhat):

FS: Alias(s):HD5b0b:;BLK1: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x1,0x0)/HD(1,MBR,0x371d28ba,0xf8,0xf800)
BLK3: Alias(s):PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x1,0x0)/HD(1,MBR,0x00000000,0x1,0x1bf244af)
BLK5: Alias(s):PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x2,0x0)/HD(1,GPT,0x585bc...,0x800,0x12a1968f)
BLK7: Alias(s):PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x4,0x0)/HD(1,GPT,0xb40a5b...,0x800,0x4a857a8f)

I'm trying really hard to just repair grub without reinstalling the entire system, but I'm not sure what to do next. I think BLK3 refers to the SSD disk and the UUID (?) with a trail of zeros seems fishy to me.

Last edited by gizzard (2014-08-06 22:28:25)

jasonwryan · 2014-08-02 20:23:11

Use efibootmgr to (re)create your boot entries: https://wiki.archlinux.org/index.php/UE … pace_Tools

Not an Installation issue, moving to NC...

gizzard · 2014-08-02 21:11:28

jasonwryan wrote:

Use efibootmgr to (re)create your boot entries: https://wiki.archlinux.org/index.php/UE … pace_Tools

Thanks for the suggestion. I followed these instructions and was able to put another UEFI entry in the BIOS menu but it still did not boot from that partition.

The original bootloader was in /boot/EFI/arch_grub_ssd/grubx64.efi:

[root@archiso /]# findmnt /boot
TARGET SOURCE FSTYPE OPTIONS
/boot /dev/sda1 /vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
[root@archiso /]# efibootmgr -c -d /dev/sda -p 1 -l /EFI/arch_grub_ssd/grubx64.efi -L "arch_test"
BootCurrent: 0006
Timeout: 1 seconds
BootOrder, 0004, 0003, 0001, 0002
Boot0001 Hard Drive
Boot0002 USB
Boot0003* UEFI: Generic Flash Disk 8.07
Boot0004* arch_test

In the UEFI Shell 2.0, should there be a FS:0 entry for the /dev/sda1 partition? The only FS I see is the LiveUSB boot partition.

gizzard · 2014-08-03 03:47:59

I am at my wit's end trying to fix this problem. I can boot to UEFI using the LiveUSB just fine. I have created a boot entry for grub on /dev/sda1 using efibootmgr and I removed extraneous ones using bcfg from the UEFI shell.

THe boot partition seems to be ok (this is after booting the LiveCD):

root@archiso ~ # gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.8
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
Found valid GPT with protective MBR: using GPT
Command (? for help): p
Disk /dev/sda: 468862128 sectors, 223.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): B5067552-...
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 468862094
Partitions will be aligned on 2048-sector boundaries
Toal free space is 2014 sectors (1007.0 KiB)
Number Start (sector)   End (sector   Size   Code   Name
  1    2048   526335   256.0 MiB   EF00   EFI System
  2  526336   468862094   223.3 GiB   8E00   Linux LVM

I did the following to reinstall grub and re-run grub-mkconfig:

root@archiso ~ # mount /dev/mapper/vol_ssd-root /mnt
root@archiso ~ # mount /dev/sda1 /mnt/boot
root@archiso ~ # mount /dev/mapper/vol_ssd-var /mnt/var
root@archiso ~ # arch-chroot /mnt /bin/bash
[root@archiso /]# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck --debug    <----- this creates /boot/EFI/arch_grub/grubx64.efi
[root@archiso /]# grub-mkconfig -o /boot/grub/grub.cfg

This will create "arch_grub" in the boot menu, but upon reboot grub is never started and the bios simply skips the disk altogether. I have tried connecting to different sata ports as well as unplugging every other hard drive in case power was the issue. It's odd that I can access the drive just fine (when booting from the USB), it's just the EFI partition that is not accessed when booting alone. Questions:
1. Am I missing something in the process to reinstall grub in the chroot environment?
2. If this process is correct, why is there no FS:1 entry for /dev/sda1 in the UEFI shell?
3. Would it be easier to just wipe the /dev/sda1 partition, recreate the FAT32 filesystem, and follow the beginner's guide installation process? I guess I wouldn't need to pacstrap and everything again since the entire root is still there on the LVM. I really don't want to reinstall everything just because I can't get the bootloader to work.

Looks like similar problems have been reported before: https://bbs.archlinux.org/viewtopic.php?id=182395

jasonwryan · 2014-08-03 04:20:41

I've not used grub with UEFI: it seems unnecessarily complicated: before recreating the FS, try using gummiboot or refind, both are much simpler to set up and use (IMO).

loqs · 2014-08-03 12:36:47

gizzard wrote:

The original bootloader was in /boot/EFI/arch_grub_ssd/grubx64.efi

efibootmgr -c -d /dev/sda -p 1 -l /EFI/arch_grub_ssd/grubx64.efi -L "arch_test"

[root@archiso /]# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck --debug    <----- this creates /boot/EFI/arch_grub/grubx64.efi

The path seems to have changed from arch_grub_ssd to arch_grub was that intentional?

Head_on_a_Stick · 2014-08-03 13:20:18

If you're using efibootmgr, why not just point it at vmlinuz-linux rather than the loader:

# efibootmgr -c -d /dev/sda -p 1 -l /vmlinuz-linux -L "arch_test" -u "root=/dev/sda2 rw initrd=/initramfs-linux.img"

You may need to alter the "root=" path, I am unfamiliar with LVM

gizzard · 2014-08-03 16:47:51

Thanks so much for the suggestions, this is a great community

loqs wrote:

The path seems to have changed from arch_grub_ssd to arch_grub was that intentional?

Yes, when I reinstalled grub I used a new label to distinguish the new one from the old one.

Head_on_a_Stick wrote:

If you're using efibootmgr, why not just point it at vmlinuz-linux rather than the loader:
# efibootmgr -c -d /dev/sda -p 1 -l /vmlinuz-linux -L "arch_test" -u "root=/dev/sda2 rw initrd=/initramfs-linux.img"
You may need to alter the "root=" path, I am unfamiliar with LVM

I tried

efibootmgr -c -d /dev/sda -p 1 -l /vmlinuz-linux -L "arch_test" -u "root=/dev/mapper/vol_ssd_1-root rw initrd=/initramfs-linux.img"

No luck. The arch_test option appears in the boot menu but the bios skips it and boots from the UEFI LiveUSB instead.

jasonwryan wrote:

I've not used grub with UEFI: it seems unnecessarily complicated: before recreating the FS, try using gummiboot or refind, both are much simpler to set up and use (IMO).

Ok, I installed gummiboot and it successfully created an EFI entry.

[root@archiso /]# gummiboot --path=/boot install
Created /boot/EFI/Boot.
Created /boot/loader.
Created /boot/loader/entries.
Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/gummiboot/gummibootx64.efi
Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/Boot/BOOTX64.EFI.
Created EFI boot entry "Linux Boot Manager".
[root@archiso /]#

I edited the loader.conf to enable the timeout. Rebooted, saw Linux Boot Manager in bios boot menu, but it still didn't boot. Again, it seems no matter what I do to the /dev/sda1 partition the bios never starts the bootloader from that device (ie I never get a grub or now a gummiboot menu).

I forgot to mention, While troubleshooting this yesterday I upgraded the bios from 1.30 to 1.60 thinking the bios was to blame. Asrock lets you downgrade, so I went back to 1.30 but it made no difference.

Last edited by gizzard (2014-08-03 21:32:23)

Head_on_a_Stick · 2014-08-03 17:52:20

gizzard wrote:

Ok, I installed gummiboot and it successfully created an EFI entry.
[root@archiso /]# gummiboot --path=/boot install
Created /boot/EFI/Boot.
Created /boot/loader.
Created /boot/loader/entries.
Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/gummiboot/gummibootx64.efi
Copied /usr/lib/gummiboot/jummibootx64.efi to /boot/EFI/Boot/BOOTX64.EFI.
Created EFI boot entry "Linux Boot Manager".
[root@archiso /]#
I edited the loader.conf to enable the timeout. Rebooted, saw Linux Boot Manager in bios boot menu, but it still didn't boot. Again, it seems no matter what I do to the /dev/sda1 partition the bios never starts the bootloader from that device (ie I never get a grub or now a gummiboot menu)

Did you create the /boot/loader/entries/arch.conf file?
The "default" line (in loader.conf) also needs to be changed to "arch" (if you use arch.conf).
https://wiki.archlinux.org/index.php/Gu … ot_entries

Last edited by Head_on_a_Stick (2014-08-03 17:59:20)

gizzard · 2014-08-03 19:50:14

Head_on_a_Stick wrote:

Did you create the /boot/loader/entries/arch.conf file?
The "default" line (in loader.conf) also needs to be changed to "arch" (if you use arch.conf).
https://wiki.archlinux.org/index.php/Gu … ot_entries

Thank you, initially I did not. The wiki says to use the PARTUUID from the root partition and not the $esp partition. The problem is I can't find the PARTUUID for the root partition, I think because it is a LVM volume. It does have a UUID:

[root@archiso /]# blkid -s PARTUUID -o value /dev/mapper/vol_ssd_1-root
[root@archiso /]# blkid -s UUID -o value /dev/mapper/vol_ssd_1-root
546c53ab-3752-4559-aa61-0336e620110c
[root@archiso /]# blkid -s PARTUUID -o value /dev/sda1
43a1b3e2-62c2-4dc5-af97-f9b7448d8c77

With the UUID for /dev/mapper/vol_ssd_1-root, I created these:

/boot/loader/entries/arch.conf

title	Arch Linux
linux	/vmlinuz-linux
initrd	/initramfs-linux.img
options	root=UUID=546c53ab-3752-4559-aa61-0336e620110c rw

/boot/loader/loader.conf

default arch
timeout	5
#default 5ef372e3a3c94671b062c4cf1d379b9c-*             <----- I did not type this in, it was generated when gummiboot was installed, but I commented it out

Rebooted, didn't work.

Before entering chroot, blkid shows this for /dev/sda2, the LVM partition that "contains" the actual root partition:

/dev/sda2: UUID="cfXu85-rJu8-Cvqk-i1lu-94CJ-Ix4T-e5QERp" TYPE="LVM2_member" PARTLABEL="Linux LVM" PARTUUID="e13326cb-42c6-4e5f-ad00-306848bb0d9a"

So, I replaced the UUID option in arch.conf with the PARTUUID listed above, and rebooted, and it didn't work.

I just realized I have been mounting /dev/mapper/vol_ssd_1-root to /mnt when chrooting, rather than /dev/vol_ssd_1/root. Would that be contributory somehow?

Head_on_a_Stick · 2014-08-03 19:53:59

gizzard wrote:

I just realized I have been mounting /dev/mapper/vol_ssd_1-root to /mnt when chrooting, rather than /dev/vol_ssd_1/root. Would that be contributory somehow?

Haven't got a clue, sorry: I don't use LVM
EDIT: The only UUID you haven't tried is that given for sda2:

UUID="cfXu85-rJu8-Cvqk-i1lu-94CJ-Ix4T-e5QERp"

Maybe try that?

Last edited by Head_on_a_Stick (2014-08-03 19:55:58)

gizzard · 2014-08-03 21:34:28

Head_on_a_Stick wrote:

The only UUID you haven't tried is that given for sda2:
UUID="cfXu85-rJu8-Cvqk-i1lu-94CJ-Ix4T-e5QERp"
Maybe try that?

Tried it, didn't work.

jasonwryan · 2014-08-03 21:43:56

I use:

options root=/dev/mapper/vgroup-lvroot quiet

You can use lvdisplay to get the correct VG/LV names of the root device.

gizzard · 2014-08-04 01:04:53

jasonwryan wrote:

I use:

options root=/dev/mapper/vgroup-lvroot quiet

I tried both of these in arch.conf one at a time, but neither worked (the first is based on your code):

options root=/dev/mapper/vol_ssd_1-root rw
options root=/dev/vol_ssd_1/root rw

It still seems to me that the EFI partition is not even being detected by the bios, so no matter what bootloaders are present on that partition it doesn't matter. Here's what I get when booting from the LiveUSB and dropping into the UEFI Shell x86_64 v2. I bring this up again because I think a filesystem (specifically FS1:, the one that should be on /dev/sda1) might be missing from the mapping table (with my comments):

UEFI Interactive Shell v2.0. UEFI v2.31 (American Megatrends, 0x0004028D). Revision 1.02
Mapping Table
FS0: Alias(s):HD8b0b0b:;BLK1:
 PciRoot(0x0)/Pci(0x1a,0x0)/USB(0x1,0x0)/USB(0x1,0x0)/HD(1,MBR,0x371d28ba,0xf8,0xf800)     <----- I think this is the FAT filesystem on the LiveUSB
BLK0: Alias(s):
 PciRoot(0x0)/Pci(0x1a,0x0)/USB(0x1,0x0)/USB(0x1,0x0)
BLK2: Alias(s):
 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x1,0x0)
BLK4: Alias(s):
 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x2,0x0)
BLK3: Alias(s):
 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x1,0x0)/HD(1,MBR,0x00000000,0x1,0x1bf244af)    <-------- I think this is /dev/sda
BLK5: Alias(s):
 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x2,0x0)/HD(1,GPT,0x585bcf50-bfbb-404e-8490-4c4f897828c9,0x800,0x12a1968f)    <-------- I think this is /dev/sdb
Shell>

From the shell I can cd to FS0: and browse directories on the USB stick that contain various efi's. I might dig out an old empty HDD and try to install a bootloader from scratch onto it just to see if the bios can boot at all from a sata port.

gizzard · 2014-08-05 01:50:20

Ok, so maybe making some progress. I booted to archiso and moved the contents of /dev/sdb to a network share. I left /dev/sda completely alone, which contains the original boot, root, var, and home LVM partitions. I then did the following:

Completely erased the partition table on /dev/sdb with sgdisk --zap-all /dev/sdb
Created a new 512 MiB ef00 partition with gdisk on /dev/sdb1
Created a new 8300 partition with the remaining space to /dev/sdb2
Created a FAT32 filesystem with mkfs.fat -F32 /dev/sdb1
Created a ext4 filesystem with mkfs.ext4 /dev/sdb2
Mount /dev/sdb2 to /mnt
Mount /dev/sdb1 to /mnt/boot
Install the base system with pacstrap /mnt base and completed the rest of the installation guide
Installed gummiboot and configured arch.conf to boot /dev/sdb2
Rebooted

and I was greeted with a nice login prompt! So the motherboard / bios is able to boot EFI partitions from hard disks, and for some reason my /dev/sda1 EFI partition on the SSD is not being detected by the bios.

I also rebooted in to the UEFI Interactive Shell and saw this code, in addition to the other code listed in my previous post:

FS1: Alias(s):HD26c65535a1:;BLK5:
  PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x2,0x0)/HD(1,GPT,6ab12e5e-1bfd-45ca-8473-71699845a615,0x800,0x100000)

So, it seems if I can make a fresh EFI partition and FAT32 filesystem on /dev/sda1, and then reinstall gummiboot to it via chroot, it should work. The problem is I don't know how to do this safely without screwing up the rest of the drive. If I follow the steps above, will pacstrap over-write the existing root directory? Alternatively, if there's a way to boot from /dev/sdb1 but use the root / var / home on /dev/sda2, that would be fine too, although sda2 is an LVM partition.

gizzard · 2014-08-06 22:28:09

Marking as solved, although I am still not sure what the problem was. I followed the steps in my previous post, but this time I mounted my old LVM root / var / home partitions on /mnt and the new /dev/sdb1 partition to /mnt/boot. Once I chrooted, /boot was empty. I ran a "pacman -S linux" and the kernel was recopied to /boot. I then installed gummiboot and configured it to boot the old LVM root partition and basically everything restarted just fine. I just left the old /dev/sda1 partition alone.

Thanks to the debug wiki for the inspiration. This post makes a good point that the EFI partition does not necessarily need to be on a fast drive, so putting it on the HDD rather than SSD isn't a big deal. I just have to go back and clean out the boot menu with efibootmgr. Thanks to everyone that helped!

Arch Linux

#1 2014-08-02 19:45:56

[SOLVED] EFI system partition fails to boot

#2 2014-08-02 20:23:11

Re: [SOLVED] EFI system partition fails to boot

#3 2014-08-02 21:11:28

Re: [SOLVED] EFI system partition fails to boot

#4 2014-08-03 03:47:59

Re: [SOLVED] EFI system partition fails to boot

#5 2014-08-03 04:20:41

Re: [SOLVED] EFI system partition fails to boot

#6 2014-08-03 12:36:47

Re: [SOLVED] EFI system partition fails to boot

#7 2014-08-03 13:20:18

Re: [SOLVED] EFI system partition fails to boot

#8 2014-08-03 16:47:51

Re: [SOLVED] EFI system partition fails to boot

#9 2014-08-03 17:52:20

Re: [SOLVED] EFI system partition fails to boot

#10 2014-08-03 19:50:14

Re: [SOLVED] EFI system partition fails to boot

#11 2014-08-03 19:53:59

Re: [SOLVED] EFI system partition fails to boot

#12 2014-08-03 21:34:28

Re: [SOLVED] EFI system partition fails to boot

#13 2014-08-03 21:43:56

Re: [SOLVED] EFI system partition fails to boot

#14 2014-08-04 01:04:53

Re: [SOLVED] EFI system partition fails to boot

#15 2014-08-05 01:50:20

Re: [SOLVED] EFI system partition fails to boot

#16 2014-08-06 22:28:09

Re: [SOLVED] EFI system partition fails to boot

Board footer