[Solved] Unable to boot after deleting EFI system partition

Questions about Grub, UEFI,the liveCD and the installer
Forum rules
Before you post please read how to get help
Post Reply
somelurker
Level 3
Level 3
Posts: 159
Joined: Fri Jul 01, 2016 6:10 pm

[Solved] Unable to boot after deleting EFI system partition

Post by somelurker »

I recently started doing some testing to transition from MBR to UEFI. Although computers these days support both, I wanted to futureproof my installation scheme.

First of all, here is what my computer's drives look like:

/dev/nvme0n1p1 is the EFI system partition I created
/dev/nvme0n1p2 is where Windows 10 is installed. This partition is encrypted with VeraCrypt
/dev/nvme0n1p3 is the /boot partition for Linux

/dev/sda1 is an NTFS partition. It is some spare space for the Windows installation to use should the SSD not be enough
/dev/sda2 is the Linux partition. It is encrypted as LVM on LUKS

Generally, both Windows and Linux get along just fine. When I start the computer, VeraCrypt's boot loader pops up first and prompts for a password. I enter it to get into Windows, or I press Esc to bypass VeraCrypt's boot loader. Then control passes to Linux.

I decided to try to play around with /dev/nvme0n1p1, and this is where things went south. I first used CloneZilla to clone /dev/nvme0n1p1 and /dev/nvme0n1p3. Then I did 2 tests:

1. Test 1: I formatted /dev/nvme0n1p1 and /dev/nvme0n1p3 each to a different file format (they were originally ext4, so I used ext2). The system predictably failed to boot. But using CloneZilla to restore both partitions resulted in a fully working system again.

2. Test 2: I deleted /dev/nvme0n1p1 and /dev/nvme0n1p3, then created new partitions in their place. Again, the system failed to boot, as expected. But here's where the situation diverges from Test 1. Even after I used CloneZilla to restore both partitions, I could only get the VeraCrypt boot loader to boot Windows. When pressing Esc to bypass VeraCrypt's boot loader, I could not get Linux to boot.

What is different about my 2 test situations, and what causes the system to fail to boot even after I've restored /dev/nvme0n1p1 and /dev/nvme0n1p3 from a CloneZilla image?

I'd be grateful for any comments.
Last edited by somelurker on Tue Dec 04, 2018 7:16 am, edited 1 time in total.

rbmorse
Level 3
Level 3
Posts: 186
Joined: Mon Mar 07, 2011 11:56 pm
Location: Albuquerque, New Mexico USA

Re: Unable to boot after deleting EFI system partition

Post by rbmorse »

I'm just guessing here, but the possibility that comes to mind is that when you abort the VeraCrypt loader it just calls the system EFI boot loader.

When you formatted the EFI partition during your "test," it caused the system to update the boot configuration data stored in the EFI's nvram on the next restart. However, restoring the original partition with Clonezilla doesn't change the EFI data back to the way it was and setup can't find the correct unique identifier (I don't know if it uses the UUID or something else) for the valid EFI boot partition. The boot stalls.

Merely deleting the original partition doesn't change the EFI setup data, so when you restore the original partition the EFI setup is still valid.

Boot into the EFI setup, go to the boot configuration settings and make sure the boot device chooser is pointing to the correct EFI boot partition for Mint. Might want to clear out any old/invalid options while you're there.
Hope is not a plan

somelurker
Level 3
Level 3
Posts: 159
Joined: Fri Jul 01, 2016 6:10 pm

Re: Unable to boot after deleting EFI system partition

Post by somelurker »

Thanks for the suggestion! I was thinking along the same lines and I used efibootmgr to delete the broken Linux entry. Is this what you meant? I used this command, but the 1 is just a placeholder for whatever the actual number for the Linux entry was:

efibootmgr -b 1 -B

This appears to have gotten rid of the broken entry.

Unfortunately, I have no idea how to add the entry corresponding to the newly restored partition. Googling found this:

efibootmgr -c -d /dev/sda -p 2 -L "Linux" -l "\efi\boot\bootx64.efi"

So presumably, I'd change /dev/sda to /dev/nvme0n1 and the 2 to a 3. But how can I tell if the path is \efi\boot on my system, and whether the file name is bootx64.efi or something else?

Edit: You're brilliant! The problem was exactly as you said it was. I figured out how to create a replacement entry using efibootmgr. I used this line (adjusted for my system of course) from the Arch wiki:

efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose

After I recreated the Mint entry, Mint booted again but VeraCrypt didn't, so I then recreated the VeraCrypt and Windows entries as well, and both operating systems booted properly again.

One problem still bothers me: Where exactly is the list accessed by efibootmgr stored? I accidentally deleted the Windows entry while doing my testing, and thought I'd take a shortcut by restoring the /dev/nvme0n1p1 partition using CloneZilla instead of trying to recreate the Windows entry using efibootmgr. To my surprise, even after restoring the partition, the Windows entry was still missing. This suggests that while the .efi files for each entry may be stored on the EFI partition, the list itself is stored elsewhere. Where might this elsewhere be?

Edit 2: I answered my own question purely by luck. I stumbled across the answer in Gentoo Wiki: https://wiki.gentoo.org/wiki/Efibootmgr

It turns out the list is stored in the firmware of the system. It's a scary thought that I could have accidentally deleted an entry and there'd be no recovering from it. What if I deleted a USB boot entry by mistake? I couldn't even boot into a Linux live USB to run efibootmgr to fix the problem. Is there any way to back up or restore the efibootmgr to its original settings?

rbmorse
Level 3
Level 3
Posts: 186
Joined: Mon Mar 07, 2011 11:56 pm
Location: Albuquerque, New Mexico USA

Re: Unable to boot after deleting EFI system partition

Post by rbmorse »

What you did works, obviously, but it's probably easier to boot into the motherboard's EFI settings, navigate to the boot section, and set the desired boot partition there. When the machine restarts, the EFI settings in the system nvram will be updated.

rEFInd should have sorted all this out by itself. The only thing you have to do with rEFInd is tell the system EFI setup (in what used to be know as the BIOS setup) which partition contains the rEFInd boot files.

The documentation for rEFInd is online at https://www.rodbooks.com/refind. You can find info on backing up the rEFInd boot configuration there. If you use rEFInd (and I do) and you're going to play with the system "just to see what happens" (I do that too, but not as much as I used to) I recommend you spend some time and let Rod walk you through the in's and out's of the EFI boot system. It's quite interesting and will make things much easier if there's a boo-boo in the future. You're already on to Clonezilla and that's a good start, but getting to know rEFInd better is another good tool to have handy.
Hope is not a plan

somelurker
Level 3
Level 3
Posts: 159
Joined: Fri Jul 01, 2016 6:10 pm

Re: Unable to boot after deleting EFI system partition

Post by somelurker »

I actually didn't use rEFInd at any point. That line I pasted was just using it as an example showing how to use efibootmgr to add an entry that I was using. What can it do that efibootmgr can't? I'm still very new to UEFI, and much of the documentation is over my head atm.

Edit: By the way, I ran into one (hopefully final) difficulty. After successfully booting into Windows, I am unable to shut down properly. The screen turns black, but the power button remains on, as does the display (there is light behind the black). I also verified that Windows did shut down properly before I did the following:

1. Deleted the EFI partition
2. Restored the EFI partition with Clonezilla
3. Used efibootmgr to recreate 3 entries (ubuntu, Windows, and VeraCrypt) such that I was able to boot into both Windows and Linux again

What could possibly have caused the inability to shut down? Does UEFI control that as well?

Edit: I found the problem. It turns out I used the wrong file when creating the ubuntu (which is really Linux Mint) entry. I found the correct file by running sudo efibootmgr -v on the working system. This verbose mode gives the .efi file that every entry is based on, allowing me to recreate them more accurately. Why would the Linux .efi file affect Windows? The two don't seem related to me; yet they clearly are because I was able to shut down properly once I used the correct .efi file for Linux.

There are still a lot of things I don't know, such as why I can only boot into Linux when the /boot partition is on the same drive as the EFI partition, but these are not urgent problems, and I can read up on them at my own pace. I'm going to mark my thread solved. Thanks!

Post Reply

Return to “Installation & Boot”