[GTALUG] war story: EFI System Partition is fragile

[D. Hugh Redelmeier]

The EFI System Partition (EEFS) is an important component in a 
UEFI-booting system.

The EFS is a FAT32 partition that contains all the programs that can be 
run by the firmware.  So to boot Windows or Linux, the system runs some 
*.efi files from this partition.

FAT32 isn't a very forgiving filesystem.

I just had one damaged by Windows updates.  I was left with a system 
that just went to a grub prompt when booted.

Diagnosis:

I booted a live Fedora USB stick.

First I had to figure out which partition was the EFS.  I did 
that by using "disks" (gnome-disk-utility).  There might have been 
lighter-weight tools, but I'm used to this one.

I did an fsck on the partition.  Lots of bad news.  "Fixing" resulted
in grubenv and grub.cfg becoming empty.

This, of course, left grub quite confused and ignorant.

Fixing:

I did some tricky things, as advised by the internet.  They might only
work because the live USB stick's Fedora matched the installed Fedora
in some way.

The general idea is to create a chroot world with the Disk's system
(bur running the USB stick's kernel).  Then use grub2-miconfig to
install a new and useful grub.cfg in the EFS.

- mount all the necessary partitions of the disk system
  + root on /mnt/x
  + I don't have a /boot partition but many would
  + EFS on /mnt/x/boot/efi
  + home on /mnt/x/home
  + swap is already handled.

Use bind mounts to create necessary bit:
	mount -bind /dev /mnt/x/dev
	mount -bind /sys /mnt/x/sys
	mount -bind /proc /mnt/x/proc

get into this world
	su
	chroot /mnt/x

fix the grub.cfg
	su
	chroot /mnt/x
	cd /boot/EFI/fedora
	ls -l grub.cfg
	grub2-mkconfig -o grub.cfg

It should now be fixed, but do have a look around for other problems.


Lessons:

- /boot/efi is fragile.
- Consider backing it up.
- Consider leaving it unmounted at rest.