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.
---
Talk Mailing List
[email protected]
https://gtalug.org/mailman/listinfo/talk
