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.