Arch Linux

LB06

Member

From: The Netherlands

Registered: 2003-10-29

Posts: 435

Grub reinstall problems (EFI)

Hello,

Today I was cleaning up my EFI boot entries and I figured I should also reinstall grub, because to my knowledge that doesn't happen automatically with EFI.

So, I executed

[root@arch ~]# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub
Installing for x86_64-efi platform.
Installation finished. No error reported.
[root@arch ~]# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux-lts
Found initrd image: /boot/initramfs-linux-lts.img
Found fallback initramfs image: /boot/initramfs-linux-lts-fallback.img
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/initramfs-linux.img
Found fallback initramfs image: /boot/initramfs-linux-fallback.img
  No volume groups found
Found Windows Boot Manager on /dev/sdb1@/EFI/Microsoft/Boot/bootmgfw.efi
Found memtest86+ image: /boot/memtest86+/memtest.bin
done

As per wiki instructions. It created a new efi file in /boot/efi/EFI/grub/grubx64.efi. However, upon reboot I was dropped into the GRUB rescue console.

So I used my GRUB standalone EFI which I created as a backup especially for these kind of situations. To my knowledge it doesn't use an external grub.cfg, because there's no grub.cfg present in that dir and manually changes to /boot/grub/grub.cfg are not reflected in GRUB on boot.

Several other threads on this forum suggested that there may be legacy in /boot/grub/, so I moved that dir aside, create a new one, reinstalled grub without errors and created a new grub.cfg. However, this one doesn't want to boot at all.

I also created a new standalone image using

echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg
grub-mkstandalone -d /usr/lib/grub/x86_64-efi -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "/boot/efi/EFI/grub/grubx64_standalone.efi"  "boot/grub/grub.cfg=/tmp/grub.cfg"
grub-mkconfig -o /boot/efi/EFI/grub/grub.cfg

but it exhibits the exact same problem as the 'regular' GRUB image: if I select it in my EFI screen, the screen flashes and just 'returns' to the same screen.

Here is the output of

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --no-nvram --debug

http://privatepaste.com/4082c82353

I added --no-nvram to prevent grub-install from wiping the current boot entry and reusing it to install the 'new' entry.

My EFI boot entries are as follows:

[root@arch ~]# efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0003,0002,0001,0006,0007,0000
Boot0000* Windows Boot Manager	HD(1,800,1ff801,08f49656-1ad5-41e7-8986-7ab985375c1b)File(\EFI\Microsoft\Boot\bootmgfw.efi)(invalid optional data length)
Boot0001* grub	HD(1,800,1ff801,08f49656-1ad5-41e7-8986-7ab985375c1b)File(\EFI\grub\grubx64.efi)
Boot0002* GRUB Standalone	HD(1,800,1ff801,08f49656-1ad5-41e7-8986-7ab985375c1b)File(\EFI\arch_grub\grubx64_standalone.efi)
Boot0003* GRUB Standalone NEW	HD(1,800,1ff801,08f49656-1ad5-41e7-8986-7ab985375c1b)File(\EFI\grub\grubx64_standalone.efi)
Boot0006* Hard Drive 	BIOS(2,0,00)(invalid optional data length)
Boot0007* CD/DVD Drive 	BIOS(3,0,00)(invalid optional data length)

I manually added Boot0003. Boot0002 is the "legacy" standalone image.

My /dev/sdb

[root@arch ~]# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.10

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

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 250069680 sectors, 119.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): F2F0D994-BFAA-4B88-AB5A-5240FF75A815
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2048-sector boundaries
Total free space is 6847 sectors (3.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2097152   1023.0 MiB  EF00  EFI System
   2         2099200         2361343   128.0 MiB   0C01  Microsoft reserved ...
   3         2361344       149555199   70.2 GiB    0700  Basic data partition
   4       149555200       237486734   41.9 GiB    8300  Linux filesystem
   5       237488128       249807502   5.9 GiB     8200  Linux swap
   6       249808896       250069646   127.3 MiB   EF02  BIOS boot partition

Any insights would be highly appreciated!

Last edited by LB06 (2014-05-31 08:07:14)

shulamy

Member

From: israel

Registered: 2010-09-11

Posts: 456

Re: Grub reinstall problems (EFI)

maybe

 --bootloader-id=arch_grub 

is important?

ezik

LB06

Member

From: The Netherlands

Registered: 2003-10-29

Posts: 435

Re: Grub reinstall problems (EFI)

Why would that be important? The .efi file is in EFI/grub/. That arch_grub dir is just one I used in the past, but it should be possible to just install grub in the default dir, right?

\hbar

Member

Registered: 2014-03-15

Posts: 165

Re: Grub reinstall problems (EFI)

So grubx64.efi is installed in /boot/efi/EFI/grub/ , the efibootmgr is configured to load \EFI\grub\grubx64.efi and the linux kernel is in /boot .

Now, if /dev/sdb1 is mounted to /boot/efi, then the efi variable pointing to grubx64.efi would be pointing to the right file, but the kernel would be in /dev/sdb4.

If /dev/sdb1 is mounted to /boot, then the efi variable pointing to grubx64.efi is wrong.

It may be that you should have run

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub

Can you post the output of 'lsblk', the contents of 'grub.cfg' and the output of 'blkid'?

LB06

Member

From: The Netherlands

Registered: 2003-10-29

Posts: 435

Re: Grub reinstall problems (EFI)

Of course!

grub.conf: http://privatepaste.com/53a350fdbf

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   128M  0 part 
└─sda2   8:2    0 476,8G  0 part 
sdb      8:16   0 119,2G  0 disk 
├─sdb1   8:17   0  1023M  0 part /boot/efi
├─sdb2   8:18   0   128M  0 part 
├─sdb3   8:19   0  70,2G  0 part 
├─sdb4   8:20   0    42G  0 part /
├─sdb5   8:21   0   5,9G  0 part [SWAP]
└─sdb6   8:22   0 127,3M  0 part 
sdc      8:32   0 139,8G  0 disk 
└─sdc1   8:33   0 139,8G  0 part /mnt/raptor
sr0     11:0    1  1024M  0 rom  

/dev/sda2: LABEL="840PRO" UUID="76885C42885C02D3" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="198da948-615c-4412-8200-2ebc43e316e3" 
/dev/sdb1: UUID="B626-174A" TYPE="vfat" PARTLABEL="EFI System" PARTUUID="08f49656-1ad5-41e7-8986-7ab985375c1b" 
/dev/sdb3: UUID="149E78D59E78B0BA" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="05ca4b54-73e1-48b5-8a11-a1f0f2dc41c7" 
/dev/sdb4: UUID="64591632-4cb7-4b18-a9c5-9e0cbb8a232a" TYPE="xfs" PARTLABEL="Linux filesystem" PARTUUID="b7ffb134-aeca-429e-a3a3-7262cd48326f" 
/dev/sdb5: UUID="402649c3-86db-48de-9a5a-77462fe868e6" TYPE="swap" PARTLABEL="Linux swap" PARTUUID="77f35c0e-1425-47d5-8e2a-35ff33b0932f" 
/dev/sdc1: LABEL="raptor" UUID="40B295E6B295E0A8" TYPE="ntfs" PARTUUID="a8ad5cd8-01" 
/dev/sda1: PARTLABEL="Microsoft reserved partition" PARTUUID="0ccf4b56-8577-4b5d-aebc-3670b3ba9539" 
/dev/sdb2: PARTLABEL="Microsoft reserved partition" PARTUUID="fc844dda-b503-49be-bb8b-18ee5b7a1481" 
/dev/sdb6: PARTLABEL="BIOS boot partition" PARTUUID="d80b983f-9b58-40a5-afb1-e4ebb6ea8338" 

Installing for x86_64-efi platform.
grub-install: error: /boot doesn't look like an EFI partition.

Last edited by LB06 (2014-05-31 16:23:43)

\hbar

Member

Registered: 2014-03-15

Posts: 165

Re: Grub reinstall problems (EFI)

Okay, that looks fine.

If I understood correctly, you have two standalone images and a regular one, when you try to boot from either standalones nothing happens (you get sent back to the efi manager screen), and the regular one goes to rescue mode. Is that correct?

Does it go to rescue mode immediately, or do you first get to pick a menu entry?

My understanding is that standalone images have the grub.cfg imbeded in them. I don't understand the syntax you used to create the standalone image (I'm confused by the whole /tmp/grub.cfg thing), but that comes from my own ignorance rather than a possible source of problems.

LB06

Member

From: The Netherlands

Registered: 2003-10-29

Posts: 435

Re: Grub reinstall problems (EFI)

Nope, I have 2 standalone images. One from years back, created during the install. The other one I just created as per wiki instructions with an 'external' grub.cfg. The original image is one with an internal grub.cfg, as far as I can see. I have manually modified my 'regular' grub.cfg file (just changed the label from a boot entry), but it's not reflected in the boot menu, so I assume it's been embedded.

Apart from these 2 standalone images, I also have a normal install. Both the normal install and the new standalone image do absolutely nothing. Not even go to the grub rescue console. The only one that works is the ancient grub standalone image.

New normal install --> does nothing
New standalone image --> does nothing
Old standalone image --> works.

I was only dropped to the grub rescue console when I still had my 'old' regular grub install. Then I reinstalled grub and it didn't even drop to the rescue console anymore.

I'm really at a loss at this point.

Last edited by LB06 (2014-05-31 18:49:24)

\hbar

Member

Registered: 2014-03-15

Posts: 165

Re: Grub reinstall problems (EFI)

You could try enabling grub debugging (https://wiki.archlinux.org/index.php/GR … g_messages), see if anything interesting shows up.

You could also try starting grubx64.efi from an EFI shell, that may give you some information so as to what's going wrong as well.

LB06

Member

From: The Netherlands

Registered: 2003-10-29

Posts: 435

Re: Grub reinstall problems (EFI)

Whoah, I think that maybe my EFI partition is corrupted. fsck.vfat reports

Seek to 2147483136:Invalid argument

And mkdir /boot/efi/EFI/test reports

mkdir: cannot allocate memory

I found out about this when I tried to install Gummiboot with gummiboot --path=/boot/efi install. Creating a dir in a subdir or creating a file works fine. The EFI partition is 2G and I have 16G of RAM, most of which unused, even including cache and buffers. I tried booting into Windows to repair the partition there, but it's not mapped to anything so I can't do much. I've run memtest86 (or well, the EFI one) but it does not report any kind of error.

LB06

Member

From: The Netherlands

Registered: 2003-10-29

Posts: 435

Re: Grub reinstall problems (EFI)

For those interested, I have solved the issues, it seems. What I at some point did was upgrade the EFI/BIOS on my mobo, a Gigabyte Z77X-UD3H, from F18 to the latest version. This solved my most immediate problem: not being able to (re)install any bootloader at all. I reinstalled GRUB, created a new standalone GRUB image and installed Gummiboot. All worked.

I thought all problems had been solved, but when I wanted to modify Gummiboot's loader.conf, vim returned an "Fsync failed" on save and would refuse to save. Dmesg showed that it tried to write beyond the FS boundaries. I could not modify anything anymore. In the meantime, fsck still returned the same error and I could not get Windows to run chkdsk on the partition. volmount.exe Z: /S worked, but I still couldn't access the volume or run chkdsk on it. So what I did was just boot into Arch and basically just recreated the partition.

umount /dev/sdb1 # unmount the EFI partition
mkdir /boot/efi.bak/
rsync -cav /boot/efi/. /boot/efi.bak/
gdisk /dev/sdb # delete and recreate the EFI partition
mkfs.vat /dev/sdb1
mount /dev/sdb1 /boot/efi/
rsync -cav /boot/efi.bak/. /boot/efi/

I then rebooted and everything worked (again)!

Regarding which thing solved which problem exactly, I'm not sure. I'm pretty certain the vfat partition was corrupt before my EFI upgrade, but why it temporarily made everything functional again, I'm not sure. I think the problems would have been solved too without the upgade, if I had only recreated and repopulated my $esp. Anyway, I hope people in a similar situation find this thread and are able to solve the problem in the same manner.

Also, on a side note, what I did just now was migrate my $esp from /boot/efi/ to /boot/ by copying everything in /boot/ (basically just the kernel stuff and /boot/grub/) to /boot/efi/, umount /boot/efi/, moving aside /boot/ and creating a new empty one to mount the EFI partition there.

The advantage is that all boot related stuff is now on the efi partition, so I can always drop into an EFI shell to change stuff. Also, Gummiboot requires everything to be in the $esp. Gummiboot doesn't know anything about the root partition, so I can't point to /boot/vmlinuz-linux. Nor should it have to, so mounting the $esp in /boot/ makes sense to me. I like Gummi much better than Grub, btw.