[Solved] Accidentally formatted EFI system partition

[FanOfLinux]

ASUS
ASUS ROG GA502 Zephyrus R7 RTX 2060 16GB/512GB Gaming Laptop;
15.6" 144Hz FHD Display, AMD Ryzen 7 4800HS, 16GB DDR4,
512GB PCIe NVMe SSD,
Nvidia GeForce RTX 2060 Max Q,
Win 10 Home, GA502IV-WS74

$ uname -a
Linux <username> 5.11.0-36-generic #40~20.04.1-Ubuntu SMP Sat Sep 18 02:14:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

It is embarrassing but I accidentally formatted EFI system partition.

I have Windows on one nvme and Mint on the other nvme.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 477G 0 disk
├─nvme0n1p1 259:1 0 260M 0 part (<== I accidentally formatted this )
├─nvme0n1p2 259:2 0 16M 0 part
├─nvme0n1p3 259:3 0 456.3G 0 part
├─nvme0n1p4 259:4 0 900M 0 part
└─nvme0n1p5 259:5 0 19.5G 0 part
nvme1n1 259:6 0 1.8T 0 disk
├─nvme1n1p1 259:7 0 1T 0 part /
├─nvme1n1p2 259:8 0 24G 0 part [SWAP]
└─nvme1n1p3 259:9 0 500G 0 part /media/foffb/< some ID .... >

I think this is not reversible.
If there is a fix (besides more coffee before starting work in the future....),
what is/are the solution/s?
Thank you.

Note: I dread rebooting my laptop.
If I do it will likely not boot up.
Then I have to reinstall Windows and then Mint Edge Cinnamon!
Ouch!!!!!

[all41]

look at testdisk in the repositories
the files may be recoverable

[rene]

1. If /dev/nvme0n1p1's partition type is not still "EFI System", i.e., shows up as such in sudo fdisk -l /dev/nvme0n1, you first need to with e.g. fdisk or gdisk change /dev/nvmen0p1's partition type back to "EFI System", i.e., numeric type EF00. I expect you don't need this part; that it's still the proper partition type.

2. If /dev/nvme0n1p1 is not still formatted as FAT32 you then need to e.g. sudo mkfs.fat -F32 /dev/nvme0n1p1. I expect you need this; that you reformatted it as e.g. ext4 or some such.

3. 1 and 2 done, it should be enough to with sudo grub-install /dev/nvme0n1 reinstall Grub onto it.

As to Windows; if you do 1 and 2 on Linux, see e.g. https://windowsreport.com/windows-10-de ... partition/ while leaving out step 4. Which, note, then probably disallows boot into Linux again (because, Microsoft) but that's at that point a standard problem that can be fixed up next.

I would not yet at this point advise recovery with TestDisk as such...

[FanOfLinux]

Thank Rene.

Code: Select all

$ sudo fdisk -l /dev/nvme0n1
[sudo] password for foffb:            
Disk /dev/nvme0n1: 476.96 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: WDC PC SN530 SDBPNPZ-512G-1002          
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 19934BB7-510B-4ED6-9E70-0C0170146786

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048     534527    532480   260M EFI System
/dev/nvme0n1p2    534528     567295     32768    16M Microsoft reserved
/dev/nvme0n1p3    567296  957475470 956908175 456.3G Microsoft basic data
/dev/nvme0n1p4 957476864  959320063   1843200   900M Windows recovery environment
/dev/nvme0n1p5 959320064 1000214527  40894464  19.5G Microsoft basic data

Looks like /dev/nvme0n1p1 is still EFI system.
GParted listed /dev/nvme0n1p1 as Fat32.
May be I did not formatted /dev/nvme0n1p1.
Instead I may have formatted /dev/nvme0n1p2 since GParted listed its File System Label as "Unknown".
When I clicked on Information icon for /dev/nvme0n1p2 in GParted GUI dialog,
I get the screenshot below. Looks like I am screwed, or rather I screwed myself!
Any rescue idea for /dev/nvme0n1p2 ?



So

[rene]

No, that /dev/nvme0n1p2 thing is going to be fine; as you can see, it's an only 16M partition, and while I'm admittedly not too sure what Windows does with them (I believe it's just some alignment thing...) those "Microsoft Reserved" partitions are not normally formatted indeed.

The fdisk -l output confirmed /dev/nvme0n1p1 still an ESP as to partition type at least so that's good. It's probably currently mounted, so so as to avoid caching issues, do sudo umount /dev/nvme0n1p1 and (try to) remount sudo mount /dev/nvme0n1p1 /boot/efi. If that still mounts, df -T /boot/efi should show fat32 as the type, and simply looking in /boot/efi should show e.g. ubuntu/ and whatever the Windows subdirectory is.

If that's all good, appears you didn't in fact do anything. If not... would be sort of good if you had an idea of what you did

[FanOfLinux]

I did these in descending order:

Code: Select all

$ df -Th /boot/efi 
Filesystem     Type  Size  Used Avail Use% [b]Mounted on[/b]
/dev/nvme1n1p1 ext4 1007G  125G  832G  13% /

Above shows it is mounted on root and root is type ext4 (as expected).

Hmmm, rhe efi partition is type ext4, but GParted after device refresh showed it is fat32. Confusing.

Addendum: I was confusing myself. GParted from screenshot below is for /dev/nvme0n1 which has the windows OS.

See screenshot at bottom. Somehow, I tried but I was not able to insert the image here. .

Code: Select all

$ sudo umount /dev/nvme0n1p1
umount: /dev/nvme0n1p1: not mounted.
# Above shows it is not mounted.
$ sudo mount /dev/nvme0n1p1 /boot/efi
$ sudo mount /dev/nvme0n1p1 /boot/efi
mount: /boot/efi: /dev/nvme0n1p1 already mounted on /boot/efi.
$ df -Th /boot/efi 
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p1 vfat  256M   512  256M   1% /boot/efi

So /dev/nvme0n1p1 is vfat (not fat32).
May be everything is OK as in the calm before the storm (before I reboot!)
What to do now?

[rene]

Don't blame you for the mistake; believe I may have not yet ever managed to type "/dev/nvme0n1p1" without getting it wrong at least once; hate that "n1" thingy. But...

Code: Select all

$ df -Th /boot/efi 
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p1 vfat  256M   512  256M   1% /boot/efi

So /dev/nvme0n1p1 is vfat (not fat32). May be everything is OK as in the calm before the storm (before I reboot!)

Seems it is not. Yet, it's FAT (vfat is fine) but it's also quite empty. If you simply look in /boot/efi I trust you will not see anything there. That is; what seems to have happened is what you said in the first place: that you reformatted /dev/nvme0n1p1, even if through some tool that helpfully did so as FAT rather than ext4.

As originally said, as far as I know a simple sudo grub-install /dev/nvme0n1 should be enough to reinstall Grub on the ESP; simply look there after doing so; I'm not fully certain; you should see a directory ubuntu/ with the actual EFI binaries in it. If you do, I'd feel it safe to reboot (but that IS while noting that I'd not be too seriously shaken if it hung after all; booting a Live system and fixing it up should always be possible).

For Windows that posted link still looks good, while repeating that it likely wipes out possibility to boot Linux again, but if you post back from Windows we should be able to fix that no problem, again through booting from a Live system DVD/USB.

[rene]

Note by the way that a/the thing is that I'm currently on a legacy system and that I can not change that for a few hours still. If you insist I can test and be more definitive later.

[FanOfLinux]

Code: Select all

~$ ls /boot/efi
# Empty
~$ sudo grub-install /dev/nvme0n1           
Installing for x86_64-efi platform.
Installation finished. No error reported.
~$ ls /boot/efi
EFI
# Yay!  EFI installed.
$ ls /boot/efi/EFI/
BOOT  ubuntu

~$ df -Th /boot/efi 
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p1 vfat  256M  5.2M  251M   3% /boot/efi

Used is 5.2M
it looks better now!
Thanks.
Deleted earlier ==>> ( Should I reboot to see if it works? )
Cancel ==>> (I am going to reboot now!
Fingers crossed!)
Oops before I reboot, if it hangs up,
how do I fix it using LIVE USB?

[rene]

Should I reboot to see if it works?

Yes, Linux should now be bootable again. Windows will not yet be; would need something like in that posted link.

[FanOfLinux]

Thanks,
I rebooted.
It works! Whew!

I will work on Windows boot later.

[rene]

Oh, by the way; just realized: as far as I'm aware (still, can only in fact check later) the ESP is in fact normally mounted on Mint, specifically on /boot/efi. Now that you reformatted it it will have gotten a different ID and your /etc/fstab supposedly attempts to mount it by said old ID. I.e., you may have noticed a bit of delay when booting? If so, obtain the current ID for the filesystem now on /dev/nvme0n1 from the output of sudo blkid and update the /boot/efi entry in /etc/fstab.

[FanOfLinux]

Thanks Rene.
Updating UUID in /etc/fstab for /boot/efi makes boot time much faster!

[FanOfLinux]

I am using Windows 11, not Windows 10.
About "Windows 10 deleted EFI partition: Here’s how to restore it",
https://windowsreport.com/windows-10-de ... partition/ ,
there is this procedure,

> $ format quick fs=fat32

Which would format the EFI partition.
All my work in Linux Mint to restore the EFI partition to be erased since I have a dual boot setup.
And if I succeed with Windows EFI restore, I have to do the same in Mint, AGAIN.
Restoring EFI in Mint would erase Windows EFI setup, correct?
Then this becomes a endless loop. No?

Furthermore, if Windows erase Mint's EFI setup, then I cannot boot into Mint,
and I guess I have to use LIVE USB to restore its EFI.

The only way too stop this is after restoring EFI for Windows,
I have to reinstall Mint instead of restoring EFI.
Correct?

Note:
I do not know how the EFI between WIndows and Mint works, but is this hunch correct,
may be when Windows installs its EFI, then installing Mint's EFI would just update Window's EFI instead of erasing it?

[rene]

That's why I said you would be leaving out step 4. And, yes, even without I expect that access to Linux may be lost again (because, again, Microsoft) but it's not the case that vice versa the sudo grub-install /dev/nvme0n1 does anything to the Windows setup on the ESP. You'd be doing latter from a Mint Live USB --- with a bit of setup; report back after you did Windows since maybe you won't need to if the Windows BCDBOOT step is less destructive than I fear.

[EDIT] On review of https://windowsreport.com/windows-10-de ... partition/ I see that while its "bcdboot c:\windows" step is "sort of" its step 5 it's also listed as the final step of its step 4. Probably clear but so as to avoid confusion: what I mean is that you'd use that step only.

[FanOfLinux]

Hi Rene:

I only have a Windows 11 recovery USB I created from this laptop.
It may not be the same as a bootable Windows on a USB.

So I will try to use that for setting my the Windows ESP.
But I think the Windows 11 recovery USB will just reinstall Win OS 11
onto nvme0n1, and I still have all my Mint installed on nvme1n1.
If I recall correctly, the WIn 11 recovery USB does not allow something similar to Mint LIVE usb.
Hope I am wrong here.

Addendum:
I just reboot and I notice there is no grub menu to select Mint or Windows since Windows EFI is gone. Ouch!!!
.

After I setup Windows to run and boot on nvme0n1, let's look at recovering Mint on nvme1n1.
Thanks.

[FanOfLinux]

I was not able to boot into Windows when I restart the laptop.
I tried using Windows recovery on USB.
There were two options:
-Windows System recovery
-Windows System image restore

When running Windows System recovery, it reported there was no Windows OS found on the nvme.
This sounds like formatting the EFI partition causes a huge lost of data for which Windows is not
able to recover from!

I could not use Windows System image restore because it can only do image restore when user
have already have Windows 11 up and running, meaning you can only restore when you are inside Windows!.

Finally I gave up and have the recovery software reinstall Windows 11.
After installation, I used Windows' Disk Management and saw Disk 0 (WIndows 11)
and Disk1.
Windows 11 is on Disk 0, which I assume is nvme0,
Disk 1 should be nvme1 (which I saw contains all my prior Linux Mint partitions).
So now I have a fresh Windows 11 installed.

When I rebooted, there was no grub menu to select Windows or Linux Mint.
At this stage, I can only boot into Windows.
So now I have to repair the boot to display an OS boot menu option which will have a list of choices to boot.
I shut down and inserted LIVE Mint USB and boot into BIOS and force selection of Linux Mint LIVE USB to run.

Next I did the following to get boot repair done (all from within LIVE Mint OS on USB):

Code: Select all

#Install Boot-Repair from Software Manager.
#or do the install as follow (from command line): 

#Setup boot repair repo
sudo add-apt-repository ppa:yannubuntu/boot-repair

#Update the APT cache.
sudo apt update

#  install Boot Repair.
sudo apt install boot-repair -y

# Running Boot-Repair
#Press menu key (Windows logo key) and type "boot" (exclude quotes).
# You will see "Boot Repair" as an app to run. 
# Run it and select "Recommended .." to initiate boot repair. 

Exit Mint LIVE USB, and should be able to see a boot menu when rebooting.

In hindsight, I should have just install Windows (and not try to restore EFI partion from within Mint at all), and then run boot repair from Mint LIVE USB.
If your Linux Mint is on the same nvme or SSD as Windows, this method would still work
because Mint is on a different partition.

Thank you Rene, for the initial guidance!.

[rene]

See it's done but also see you didn't just follow the "Windows command prompt" advise linked. The thing is that in these EFI days booting has in fact gotten a lot simpler: the ESP is nothing but a regular filesystems and the bootloaders regular files on said regular filesystem. Recovery from a destroyed ESP is as such nothing other than recreating it and copying the bootloaders back. sudo grub-install did/does in the Linux case, bcdboot c:\windows would've in the Windows case (although it might have done a bit more / too much as well as earlier said/implied).

That is; you seemingly did a lot more than in fact required --- but if all's well, all's well.

[FanOfLinux]

I am not sure what you mean by "Windows command prompt" since I said I was never able to get into Windows using the Windows recovery USB I created for my laptop.
I do not have any other Windows OS on a USB.

Can you explain it in another way of how I can get into "Windows command prompt"?

[rene]

The provided windowsreport.com link says it's Shift-F10 on a Windows install USB/DVD which may be the same for "a recovery USB" but if not, the following excruciatingly slow video shows it available on a recovery USB as an "advanced option" at 3:35.