reinstating boot/efi partition lost on a fried SSD

gumb · 10-20-2019, 05:06 PM

One of my SSDs failed and I lost the data on it. I've installed a new one but need to reconstruct the lost /boot/efi partition, and get it and the original root partition talking to each other.

The machine has two SSDs. The M.2 drive (sdb) holds the root partition (sdb1), which is still intact, whilst the SATA drive which failed (sda) held the boot/efi partition in addition to the /home partition. (Since this is a 'new' secondhand laptop I hadn't got around to doing a backup yet, so my last backup is my old laptop).

After installing a replacement SATA SSD, I booted the openSUSE Leap 15.1 rescue system from a USB stick, changed root to the original oS installation on sdb1 and then, from within the YaST Partitioner, created a new /boot/efi partition (sda1) and /home (sda2) on the new disk.

Everything is mounted by UUID, and fstab contains the new /boot/efi partition, but it appears that it is empty and I don't know how to fill it with the necessary files and link it to the root partition. Currently if I reboot I get the error:
no such device: /efi/boot/fallback.efi

I've tried forcibly reinstalling the package grub2-x86_64-efi from the USB stick (I don't know how to get network from the rescue system) and after some random googling have tried the command

Code:

efibootmgr -c --disk /dev/sda --part 1

as well as openSUSE's grub update command

Code:

grub2-mkconfig -o /boot/grub2/grub.cfg

which both looked to have done whatever they're required to do, but I'm just grabbing at straws and there's other missing link(s) in the chain to get this install back up and running. Any ideas?

syg00 · 10-20-2019, 08:49 PM

Haven't used yast in years, but partitioners typically only create the partition itself. Even if it also formats a filesystem (yast probably would) it will by definition be empty. The EFI partition must be [V]FAT.
Make sure it is mounted then re-install grub - this will populated the binaries - then run the mkconfig. Be aware that some brain-dead manufacturers expect/require an appropriately named Windows module be present before they will boot. And no, it's not necessarily because of secure boot.

mrmazda · 10-21-2019, 02:25 AM

Quote:

Originally Posted by gumb

Code:

efibootmgr -c --disk /dev/sda --part 1

https://en.opensuse.org/openSUSE:UEFI has an example how to create a new UEFI entry using efiboomgr that is quite different from your attempt. AFAICT, if there is only one ESP partition in a system, efibootmgr needs neither disk nor partition specification. I haven't needed either one when restoring a lost entry to an ESP on GPT M.2 as sdc with 2 SATA MBR disks as sda and sdb.

The MBR sector (sda) is not used by UEFI for Grub on GPT disks. UEFI is a vastly different boot process from MBR. Take a look through https://www.happyassassin.net/2014/0...lly-work-then/ if you want to understand the UEFI processes.

I presume either you've booted the installed system from installation media, or properly chrooted from a rescue boot to perform these repairs. Exactly what method did you use?

Did you try running yast bootloader to make any trivial change (e.g. timeout) after forceably reinstalling grub2-x86_64-efi? I would expect yast in chroot to populate the ESP partition properly once grub2-x86_64-efi has been reinstalled and with appropriate fstab adjustment. Have you double checked UUID of the ESP in fstab matches the newly created ESP's UUID?

FWIW, all my fstab entries mount by LABEL rather than UUID. Also I boot by LABEL via /boot/grub2/custom.cfg via /etc/grub.d/06_custom (a copy of 40_custom), which places all my custom entries at the top of the grub menu that grub2-mkconfig creates. Custom.cfg contains 12 stanzas in only 3680 bytes, while grub.cfg is 31kb.

fatmac · 10-21-2019, 05:20 AM

Quickest way would likely be to do a complete re install to the SSD, then alter fstab to set it up how you want it to act.

onebuck · 10-21-2019, 09:11 AM

Moved: This thread is more suitable in <Linux - Hardware> and has been moved accordingly to help your thread/question get the exposure it deserves.

tofino_surfer · 10-21-2019, 12:14 PM

Boot into the openSUSE Leap 15.1 rescue system from a USB stick and paste the output of "efibootmgr -v" and "ls -lR /boot/efi" into blocks with CODE tags.

If you can't access the network from the rescue system then insert a second flash drive to use as file storage.

Quote:

Quickest way would likely be to do a complete re install to the SSD, then alter fstab to set it up how you want it to act.

This wouldn't be the quickest. It may be the longest. They only need to re-install grub2 to the ESP. Also they don't want to put / on the SSD but rather keep it on the M2.

colorpurple21859 · 10-21-2019, 02:35 PM

Short version:
boot rescue usb, mount root partition(sdb1), mount efi partition to /boot/efi of root partition(sdb1)
mount --bind /dev /proc /sys /run to same on root partition(sdb1)
chroot into root partition
run grub2-install

gumb · 10-21-2019, 05:19 PM

Thanks for the responses. Between sleep and work I'm not progressing fast with this. Every time I think I've found the cure I try rebooting and just get the same error. Unfortunately I can't yet find a way to save the output or post anything here. I tried inserting another USB stick into the remaining USB port but can't seem to mount it.

My first critical error was that everything I'd tried yesterday was without remembering to mount the /boot/efi partition after I'd done chroot to the original install. So now I've done that, I then uninstalled and reinstalled the grub2-x86_64-efi package, went into YaST Bootloader and made a minor change to the timeout, which forced the bootloader update script to run. After this I can see /boot/efi is all populated with a load of new stuff. Still didn't boot though.

I looked at efibootmgr -v and couldn't see anything that looked like a useful reference to the right partition, despite there being other items that are clearly related to my previous setup, including an alternative distro that was installed on the lost SSD. So I tried again the command I pasted before:

Code:

efibootmgr -c --disk /dev/sda --part 1

which added a new entry with 'HD' in the string and what seemed like the correct details. It warned that this was a second entry called simply 'Linux', but I noted the default boot order put this new entry first, so hoped that would work. Nope.

For the moment I've turned Secure Boot off in the BIOS and am trying just with UEFI boot.

Regarding the reply suggesting it would be easier to simply reinstall from scratch, in some ways perhaps yes, but it's not desirable. It's enough of a hassle piecing together what I lost from my home partition and I'd put considerable time into system configuration that I'd rather not go through all again. Salvaging at least the root would help me piece together a load of other missing bits and bobs, and is still preferable even if it takes me a couple of days to figure out.

For reference, when at the rescue prompt, these are the commands I go through, based on something I read on the Internet long ago:

Code:

mount /dev/sdb1 /mnt
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
chroot /mnt

There might be additional things I should put in or a better way to do it but since I have to type this fresh every blasted time and I've done it about thirty times already it's a bit tiring as it is!

colorpurple21859 · 10-21-2019, 06:45 PM

Quote:

without remembering to mount the /boot/efi partition also

yes that will cause issues. Did you format the efi partition fat32 or fat16?

Code:

mount /dev/sdb1 /mnt
mount /dev/sda1 /mnt/boot/efi
mkdir /mnt/boot/efi/EFI

also

Code:

mount -o bind /run /mnt/run

did you run

Code:

 grub2-install /dev/sda

after chroot into system?

gumb · 10-21-2019, 07:30 PM

Quote:

Originally Posted by colorpurple21859

Did you format the efi partition fat32 or fat16?

I don't know. In the YaST Partitioner ISTR there were options for FAT32, FAT16, FAT12 or Auto, so I left it on the default of Auto.

Quote:

Originally Posted by colorpurple21859

Code:

mount /dev/sdb1 /mnt
mount /dev/sda1 /mnt/boot/efi
mkdir /mnt/boot/efi/EFI

I mounted the /boot/efi partition after having done chroot into the install on /dev/sdb1, i.e.

Code:

mount /dev/sda1 /boot/efi

I'm a bit confused how this works and what differing effect your suggestion would have.

Quote:

Originally Posted by colorpurple21859

also

Code:

mount -o bind /run /mnt/run

did you run

Code:

 grub2-install /dev/sda

after chroot into system?

I noted the earlier response and added /run to the commands. I also tried grub2-install shortly after my last post, though without the /dev/sda at the end. It seemed nonetheless to add the correct info to the listings seen in efibootmgr -v. Still doesn't boot. Always the same error: no such device: /efi/boot/fallback.efi

colorpurple21859 · 10-21-2019, 07:42 PM

Quote:

I'm a bit confused how this works and what differing effect your suggestion would have.

either way will work. This wouldn't happen to be an HP, where you will have to go into the bios to change boot order?

A Work around may be to copy /boot/efi/efi/opensuse/grubx64.efi to /boot/efi/efi/boot/fallback.efi

what does is output of

Code:

efibootmgr

tofino_surfer · 10-21-2019, 11:31 PM

Quote:

A Work around may be to copy /boot/efi/efi/opensuse/grubx64.efi to /boot/efi/efi/boot/fallback.efi

No it may not. This isn't what fallback.efi does. Rod Smith has a good page on this:

https://www.rodsbooks.com/efi-bootloaders/fallback.html

Quote:

Many Linux distributions now set up fallback.efi and BOOT.CSV files in such a way that, if the NVRAM entries are all lost, fallback.efi will run to re-create the entries. Thus, ideally you won't even know that a problem existed and has been corrected. The point of this page is to enable you to set up fallback.efi yourself if your distribution doesn't, and to give you enough information to manage the situation if your distribution has set it up but something you don't expect or want happens as a result....

Quote:

what does is output of efibootmgr

I asked for this in post #6. They never responded. This is important as fallback.efi is needed only when the NVRAM variables are missing.

The OP needs to post the output of:

Code:

$ sudo efibootmgr -v 
$ ls -lR /boot/efi

gumb · 10-26-2019, 10:09 AM

Quote:

Originally Posted by tofino_surfer

I asked for this in post #6. They never responded. This is important as fallback.efi is needed only when the NVRAM variables are missing.

The OP needs to post the output of:

Code:

$ sudo efibootmgr -v 
$ ls -lR /boot/efi

As I mentioned previously, I have no network on the rescue system and my attempts to mount another USB stick also failed, so I have no way to easily post the output here.

Finally I've found a workaround, not a solution. The laptop was supplied with an EFI partition and another distro installed, which I'd originally kept on a separate partition, but since all that got lost on the failed SSD I now only need to keep my preferred openSUSE installation. So I disabled UEFI boot in the BIOS and then, again from within the YaST Bootloader settings on the rescue system, selected regular GRUB2 instead of UEFI GRUB2. It now boots.

However, I have a new quandary. Maybe I should create a new post. The new /home is blank and I want it populated with the default users' files so that I can log in and retain various temporary files and setups related to existing users. I don't know if the useradd command can allow to just populate a home directory without creating a new user. Or if there's some way I can create a new user, delete the existing one and then change the username and user ID to the old one.

mrmazda · 10-26-2019, 10:30 AM

Quote:

Originally Posted by gumb

However, I have a new quandary. Maybe I should create a new post.

You should create a new thread, if you can't first find a solution by searching.