BIOS Update destroyed EFI partition

I posted here a couple of days ago about my computer freezing and I got some advice to reinstall the OS and update my bios. I started with reinstalling EoS but the freezing kept happening, today I updated and flashed my BIOS with the latest firmware but after that I’ve been unable to boot into my OG linux install.

The issue is that I have two separate nvme ssd drives, one had Windows on it, but I removed it because it had overwritten my EFI partition after updating the BIOS (and I think maybe tried to re-format or “fix” my nvme drive with linux on it).

So I couldn’t boot into my Linux install, the option didn’t even exist in the BIOS after updating it. It had turned into “Windows boot manager” on BOTH nvme’s. The linux eos filesystem still exists though on the ssd.

So then I went in and removed windows with Gparted (on the old windows ssd) and installed EOS with GNOME over the top of the SSD, I was having some troubles with the default systemd-boot on the borked install of linux/eos so this time I chose grub.

Now the problem I’m still having is
A) removing the remaining window stuff (see output of fdisk -l) FDISK
B) fixing the issue with EFI / getting my other install back to a bootable state.

Im running fdisk from my new install on the samsung nvme (newly broken install from 2 days ago is on WD black) and I have mounted it and chrooted into it to poke around a little bit. I dont see anything in /efi
and there was nothing in /boot until I just tried to run dracut to rebuild the initramfs image, which worked as far as I can tell but it had said “proc/ and sys/ aren’t mounted your mileage may vary.”

output of “sudo efibootmgr” from the second (newest) linux install on samsung drive.

BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0001,0002,0004
Boot0001* UEFI:CD/DVD Drive	BBS(129,,0x0)
Boot0002* UEFI:Removable Device	BBS(130,,0x0)
Boot0003* endeavouros	HD(1,GPT,3b96d472-eaf4-de47-895b-09d3eff3cc63,0x1000,0x1f4000)/File(\EFI\ENDEAVOUROS\GRUBX64.EFI)
Boot0004* UEFI:Network Device	BBS(131,,0x0)

Any guidance on what to do would be greatly appreciated.

Okay on /dev/sda i only see 2 Windows partitions. Normally there are 4. There should be Efi, System Reserved, System Restore and C: partition that Windows is installed on.

/dev/sda1     34      32767      32734    16M Microsoft reserved
/dev/sda2  32768 1953521663 1953488896 931.5G Microsoft basic data

On /dev/nvme1n1 you have an EndeavourOS install

/dev/nvme1n1p1    4096    2052095    2048000  1000M EFI System
/dev/nvme1n1p2 2052096 1953520064 1951467969 930.5G Linux filesystem

On /dev/nvme0n1 you have an EndeavourOS install.

/dev/nvme0n1p1    4096    2052095    2048000  1000M EFI System
/dev/nvme0n1p2 2052096 1953520064 1951467969 930.5G Linux filesystem

The last disk is DOS. Not sure if that is being used for files?

/dev/sdb1        2048 976770112 976768065 465.8G  7 HPFS/NTFS/exFAT

Anyway you are missing the Windows EFI and or Windows bootloader. I don’t know which nvme drive is the one with grub but what i would do is try to use a Windows install disc and run a repair to try to fix the Windows boot first but i don’t think it will because partitions and files are missing. You may end up having to reinstall Windows if it won’t repair it and boot into Windows. Then all you have to do is arch-chroot into the installed EndeavourOS system on whichever nvme drive you had grub on and reinstall grub and run the grub update command.

Do I have to reinstall windows? I honestly don’t want windows back if I dont have to, I’d rather remove it entirely especially since I already installed EoS over it to try and fix my original install. Whats missing the ability to boot is /dev/nvme0n1p2. It says there is an EFI system but I dont see it anywhere and Grub on my new install isnt finding it. The old install of Eos that isnt booting had Dracut and systemd-boot. Im chrooted into it from the new install and I’m not sure what command to run or what to look for.

Then all you need to do is boot on the live ISO and arch-chroot into the installed sysytem that has the EndeavourOS install with grub. Then reinstall grub and run the grub update command and you should be able to just boot EndeavourOS.

https://discovery.endeavouros.com/system-rescue/arch-chroot/2022/12/

https://discovery.endeavouros.com/system-rescue/repair-a-non-booting-grub/2021/03/

Did you already arch-chroot into the installed system?

Show this command:

ls /home

Edit: This should show you are in your user /home

Edit2: If you are chrooted properly then the wiki i posted shows you how to reinstall grub and run the grub update command.

yea I installed linux over the old windows partition and chrooted into my old linux partition. “ls /home” gives me my old username and it clearly has all of my old files and such.

The old system uses dracut and systemd-boot which I am not familiar with. the system with grub is on says this when I run os-prober:
$ sudo os-prober
/dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
/dev/nvme0n1p2:EndeavourOS Linux (rolling):EndeavourOS:linux

You should be able to fix grub then with the arch-chroot. If you don’t want Windows and are going to remove it anyway then you don’t need to enable os-prober. It will just fix the grub bootloader and boot EndeavourOS. You may want to get rid of both Windows and the other installed EndeavourOS with systemd-boot then.

Windows is already gone. I installed Eos over it (samsung /dev/nvme1n1). The EOS install (on the WD_BLACK /dev/nvme0n1) with systemd-boot, the efi was overwritten by windows when I updated the bios and it now indicates that it is windows, when it isnt. I’m not sure how to use systemd-boot to fix that

I still see Windows Files on /dev/sda that’s what i was referring to. All you need to do is create a new GPT partition on both the drives you want cleared using gparted. If you arch chroot into the one you installed EndeavourOS grub and reinstall grub and run the grub update command after this then you should have a bootable EndeavourOS.

Was it nvme1n1, nvme0n1 or sda?
If you don’t want Windows, then, after you fix EnOS system(s), use Gparted to delete any partitions you don’t want (WinOS related).

How do you look for it? :smile:
Check in the system you talk about, inside the file /etc/fstab, for a partition with vfat file system.

For properly chrooting, you need to also mount the $ESP (efi) partition.
Read the posted links about proper chrooting.

How do you know that?
Browse the $ESP partition for relevant files.

can you report

sudo parted -l

Thank you everyone. Sorry for not following up, Im really not sure what ended up fixing everything but basically I regenerated the kernel image portion of my borked EOS install as best as I could using dracut (the image was literally missing), mounted it into the second installs EFI partition and then booted from a USB stick and pulled it out and somehow the missing EFI files were back/regenerated from the borked install and it booted back into the broken installation.

Its hard for me to explain it in a way that is easy to understand but Windows just destroyed the EFI folder and in its place was an extra windows system boot manager. I ended up also having to dig through the EFI and boot folders to find all of the windows boot stuff and manually deleted it.

The sda’s are unrelated HDD’s.

I think from now on I will just A) never install windows again and B) be more careful when updating my BIOS and anticipate something being messed up. In reality that was windows fault as it tried to “repair” my installation and my MSI mother board swapped my boot order to windows to let it happen. Then windows overwrote the grub and EFI folders even though it was on an entirely separate SSD

Also to my original post about freezing, I think it has something to do with either Awesome-git [awesome wm] or Picom because I haven’t experienced the freeze under XFCE, or wayland, though I need to spend a lot more time using them to be 100% sure

1 Like

Nothing like this has happened. Firstly, Windows are dead (destroyed after your second EnOS installation, as you have said), so the dead cannot destroy anything. Secondly, even if there were alive, they do not delete folders, but sometimes they replace/delete NVRAM (UEFI) boot entries.

Reincarnation of files cannot be done by itself, unless a greater power does it :wink: , even in Linux :person_shrugging: .

My only reliable assistant :crystal_ball: showed me what has happened:

  • When you updated the BIOS, all NVRAM (UEFI) boot entries were reset/deleted, with only the default vendor’s boot entry, which is named as “Windows Boot Manager”, even if Windows is not installed.
  • When you used your second EnOS installatiion and chrooted, you did not do it properly, probably using the simple chroot command, and excluding the ESP (/efi) partition, so you thought that the folders and files are destroyed :scream_cat:.
  • Then you mounted the other ESP and recreated kernel files, so an entry for the old/broken installation was created in the grub menu (possibly in UEFI as well).
  • After successful booting to the previously broken system, the old ESP was automatically mounted at the correct mount point (/efi for systemd-mount systems). Then, the previously empty /efi folder (since it was serving only as a mount point) had contents again (since it was mounted as designed).

Disclaimer: All of the above is imaginary and should not be taken as a Magician’s prophecies!

It went like this:
I started with a dual boot setup with windows and Awesome WM on separate NVME SSD drives > AWM/EOS is randomly freezing > prompted to backup and update BIOS as a potential fix > Update BIOS > Reboot into “windows is fixing XYZ” > Every attempt to reboot goes to windows > Cant reboot into Linux/stuck in windows, all boot entries load up windows or windows repair > boot into live-usb and delete Windows partitions with Gparted > install GNOME and Eos as a backup and to permanently overwrite windows > chroot from the new installation into the OLD broken installation > remove windows EFI and Boot artifacts > regenerate image using dracut > mount EFI > Reboot and I did some random stuff here that may or may not have had any effect, but it rebooted back into my installation using systemd-boot instead of grub.

I think the reason that you think that is because pretty much everyone in this thread misunderstood what happened. It didn’t help that Im not good enough to properly explain things lol

I only ever installed the second eos on the windows nvme ssd after I got stuck in a windows boot loop where windows was force updating and “fixing” drives, which left me unable to access endeavour os no matter what I did.

It was confusing because of that as well as my original install was using Systemd-boot and Dracut and only the new one used grub. After doing all of that it went back to booting with the systemd menu.

You are right that when I was asking for help last time, I had not yet mounted the EFI partition yet though. Realistically I personally think I just needed to change the boot order back to USB first (I would have put Linux first if the option was there but it was only both “windows boot manager” for each SSD), then boot a Live USB, chroot in properly, regenerate missing image using dracut, figure out the EFI/boot stuff and then reboot.

I do appreciate the insight, I was definitely making mistakes and not understanding some things, and I wasnt able to properly convey that to the people here

Its also why at that point it had said “grub” when it should have looked more like this:

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,0002,0003,0004
Boot0000* Linux Boot Manager	HD(1,GPT,37b14299-1384-be4d-95b8-d607769775ec,0x1000,0x1f4000)/File(\EFI\SYSTEMD\SYSTEMD-BOOTX64.EFI)
Boot0001* UEFI OS	HD(1,GPT,37b14299-1384-be4d-95b8-d607769775ec,0x1000,0x1f4000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0002* UEFI:CD/DVD Drive	BBS(129,,0x0)
Boot0003* UEFI:Removable Device	BBS(130,,0x0)
Boot0004* UEFI:Network Device	BBS(131,,0x0)

That’s why I mostly rely on my Magic Crystal Ball :crystal_ball: , which is the only capable assistant in cases with poor details for a complicated problem. :person_shrugging:

IMHO, you have to let time build your Linux experience first :smile: .

With no UEFI entries after BIOS reset, you only need to recreate the missing UEFI entry.
In order to do that with the easiest way, you have to properly chroot to the broken system.
Depending on the bootloader, use the relevant method.

The advancing errors started because you did not properly chrooted.
I suggest you study on this subject, as it is a system saver, as well as sanity saver sometimes… :slightly_smiling_face:

Archlinux has a very good assistant utility that is very easy (for not complicated system installations, with i.e. encryption, LVM etc.) called arch-chroot.
Also, EnOS wiki has articles with such instructions.

Without studying, it is very difficult to maintain an Archlinux based system. :person_shrugging:


The only reasons I posted my previous comment after you had reported it was solved, is to clarify for user readers, including yourself, that Windows do not destroy files and folders (being a faulty rumor in the Linux world), and that your system still needs to be confirmed it works correctly (as designed).
Read through my comments and try to resolve any potentiall misconfigurations.

Have a nice day! :smiling_face:

Yes, I know I’m tagging onto an older post, but this is related (clearly).
I have an Asrock motherboard and I had issues updating the bios (tech support contacted), and they eventually got me a solution (not a good one IMO), but the end result is that when flashed, the efi partition war cleared of the linux bootmanager, though Windows survived or was rebuilt… I recovered with arch-chroot.
I also noticed that on the windows partition it lost my PIN and wifi security information. Both have been reclaimed after dancing with MS for a while (many hops to reset PIN)
This is a new machine, but I’ve never had this issue when updating a BIOS before.

My guess would be that the update for the bios does not see a certificate for Secureboot I would assume that the update would check for this. Does this happen on distro’s that support Secureboot?

This i would expect would trigger a behavior in the firmware that clears out the efi for a new install do to the fact it thinks the other one is corrupted.

Well, I have only EndeavourOS at present, so I can’t say :slight_smile: Just thought it might help someone in some way to report it.
Since I actually want to upgrade BIOS further (the tech guy was conservative), I might could test. What distros support SecureBoot?

What is the exact Asrock motherboard model?