[SOLVED] Buster - unable to boot, unable to recreate boot bits
DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
The partition that I am mounting /boot/efi on IS created as an EFI System partition type (Ext4).
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.
Nope. The EFI standards mandate FAT only. Later versions, i.e. almost all current computers, accept VFAT as well.
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:
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.
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.
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.
Last edited by colorpurple21859; 05-07-2020 at 05:51 AM.
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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.