Buster - unable to boot, unable to recreate boot bits
 

As the result of some stupidity I can no longer boot my system.

The problem occurred after running fsck on a filesystem that was, as far as I understand, my EFI partition.

I can boot via Debian Live and mount and see everything OK (I can see my kernels, gnu stuff etc), but I am unable to come up with the right incantations to get grub to recreate the boot bits.

I suppose some of my problem lies in my ignorance of how EFI works.

The disk that I'm working with (a memory drive) is GUID partitioned. Running grub-install --efi-directory=/boot/efi on this device gives me:

grub-install: error: /boot/efi doesn't look like an EFI parition

The partition that I am mounting /boot/efi on IS created as an EFI System partition type (Ext4).

I am mounting my system partition on /mnt, mounting my efi partition on /mnt/boot/efi, mounting /dev /pts /proc /sys /run on /mnt and running chroot /mnt, then running the grub command shown above.

My hardware IS using EFI (verified via sudo dmesg | grep efi).

I recently upgraded from Stretch. Thought everything was fine (no errors in upgrade). Had been running a couple days perfectly fine: no problems booting. Due to hanging the system (I had an mysql query run amok) I ended up power-cycling the system: it's a headless server. Problems bringing the server back up led me to trashing it via efsck.

I think that I've tried every repair application and every suggested repair steps and I'm now totally stumped. I REALLY don't want to have to reinstall the OS.

Nope. The EFI standards mandate FAT only. Later versions, i.e. almost all current computers, accept VFAT as well.
As far as Linux is concerned, the grub-install will fix things - however some manufacturers require a M$oft module be present, in which case the firmware won't boot anything if it's absent. Basically all you can do is recover the contents if you have a backup, or go the nuclear option and reformat. If you dual-boot Windows recover that first then grub-install again. If it's a Linux-only machine, try it and see.

So, then, to [attempt to fix/resolve] I can just change the partition type to Fat or VFAT? I'm only running Debian on this server, no plans for anything else. (I didn't see any types such as these being available through the Live boot [gknow] disk utility]: I had aspirations of trying this, but because I didn't see anything obvious, and I had other pressing matters to attend to, I gave up.) I drop the type "EFI?"

I don't quite recall the initial installation of this system. But here's what I show as how things were set up:

Filesystem Size Used Avail Use% Mounted on
udev 3.9G 0 3.9G 0% /dev
tmpfs 787M 69M 719M 9% /run
/dev/nvme0n1p2 73G 3.6G 66G 6% /
tmpfs 3.9G 957M 3.0G 25% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/nvme0n1p1 952M 1.5M 950M 1% /boot/efi
/dev/nvme0n1p5 17G 267M 16G 2% /home
/dev/nvme0n1p3 9.2G 37M 8.6G 1% /tmp
/dev/sda1 492G 8.1G 459G 2% /data/sda1
/dev/sda3 492G 164M 466G 1% /data/sda3
/dev/sda2 196G 449M 186G 1% /data/sda2
tmpfs 787M 0 787M 0% /run/user/1000

Is that /boot/efi bogus? As stated, I don't recall how it was created.

Rather than chase bit-and-pieces, go here and post the RESULTS.txt - it has all we need to see. Bootrepair produces a similar report if you already have that.

The /boot/efi is required on an efi system. The efi partition is needs to be a vfat filesystem and mounted at /boot/efi for grub-install to work

I wasn't able to get boot-repair to work (problems accessing the repository or such).

Took another look this morning and find that I did have Partition Type set to "boot," which, as far as I can tell/have read, is what is supposed to be necessary. BUT, for "Contents" it still shows up as being ext4. Am I needing to recreate this partition from scratch? Or, can I reformat as VFAT (do it on the commandline as I cannot seem to get this option through disk manager)?

I'm mostly understanding how things work. Just struggling with how to resurrect w/o causing real damage.

You can format it, from command line.

I'm still battling this beast...

Copied all my old boot files (except grub files) to the refreshed boot partition, which is properly identifying as VFAT (also has a boot flag- maybe this isn't right?). Did all the right incantations to run grub-install only to encounter problems setting EFI variable (write failures, "No space left on device."). After trying and failing at all the most likely "solutions" to this problem (EFI dump files being the most likely culprit- I cannot delete them), I've decided to try a direct boot from the UEFI shell.

In the UEFI shell I can see all what I believe are the requisite files in my boot partition (fs0). Going to pursue booting from UEFI shell to see if I can manually make things work.

At this point I'm wondering whether to just dump using grub.

I have limited bandwidth to work with in which case this is just going to take me a while.

you don't copy all the boot files to this partition, you don't copy anything to this partition when using grub as bootloader.
/boot is where your boot files are including grub files. The efi partition is formatted fat32, flagged as esp, and mounted at /boot/efi. Then run grub-install as root. If your not able to boot into the system then you wil need to chroot into your system from a live iso, then mount the efi partition to /boot/efi and run grub-install.

All is now working fine. One thing that I had to do/run was 'update-grub.' In addition I had to edit my fstab file to change the UUID for the reconstructed /boot partition.

Should be fine as long as I don't run efsck again on /boot (or any other VFAT partition)! (no need to comment on this as I've learned this "lesson")

Is grub even being used? Don't know/don't care: it's a headless server; I ONLY care that it boots (and now that it does I'm done- even IF there are "incorrect" files in /boot- I have a ton of disk space).

Thanks!

If you had to run update-grub the answer is yes. Anyways its good that you have it working again.