For reasons that are too complicated to explain here, the ESP partition of my multiboot system was accidentally formatted.
I thought I could easily fix it by installing a new distribution and that the boot menu would work, but that’s not the case.
Although os-prober and GRUB correctly identified the installed Linux operating systems (there were no path or UUID issues), none of them will launch — the logo just spins endlessly.
With Zorin, I managed to fix the issue by reinstalling without formatting.
Unfortunately, the ‘Something else’ mode of the Ubuntu 24.04 installer does not allow you to avoid formatting the partitions.
How can I refresh my installation without completely reinstalling?
I’ve already tried a number of things in chroot mode, including installing rEFInd or regenerating the initramfs, but nothing has worked.
What’s blocking?
How can I reinstall the kernels from the command line?
I don’t know the answer to your question but for what it’s worth, I couldn’t resist asking Claude about it… not sure if this helps you but figured I’d post. AI can be wrong so please wait for an authoritative answer from one of the gurus.
Response from Claude as follows….
Recovering Ubuntu Boot After ESP Format
This is a classic issue after losing the ESP. The spinning logo suggests the kernel starts loading but fails — typically because the initramfs or kernel modules are incomplete/mismatched after the ESP was recreated.
Here’s how to properly reinstall the kernel and boot infrastructure from a live USB:
1. Boot from Ubuntu Live USB and identify your partitions
lsblk -f
Note your Ubuntu root partition (e.g., /dev/sda2) and the new ESP (e.g., /dev/sda1).
2. Mount everything properly
sudo mount /dev/sdXY /mnt # Your Ubuntu root partition
sudo mount /dev/sdXZ /mnt/boot/efi # Your ESP
# Critical virtual filesystems
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run
# For EFI variables access
sudo mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
3. Chroot in
sudo chroot /mnt
4. Reinstall kernel and boot components
# Check your installed kernel version
dpkg -l | grep linux-image
# Completely reinstall the kernel (forces regeneration of everything)
apt install --reinstall linux-image-$(uname -r)
# If that doesn't match your installed kernel, use the actual version:
apt install --reinstall linux-image-6.8.0-xx-generic # adjust version
# Reinstall GRUB EFI
apt install --reinstall grub-efi-amd64 shim-signed
# Reinstall to ESP
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
# Regenerate initramfs for ALL kernels
update-initramfs -c -k all
# Update GRUB config
update-grub
5. Exit and reboot
exit
sudo umount -R /mnt
sudo reboot
If it still hangs — debug the boot
Add nomodeset and remove quiet splash temporarily in GRUB to see actual error messages:
Thank you very much, @evc, for kindly responding to my call for help!
And thank you twice as much because I refuse to use AI — except to check that the wine pairing I had in mind for a dish wasn’t a bad choice.
That way, I get a little idea of its capabilities.
It just so happens that I had been tinkering with a little script to help an acquaintance troubleshoot his system by automating the creation of a chroot environment — and learning how it works at the same time.
So I know what Claude is explaining, and I’ll be able to try the next step, which I’m currently stuck on: reinstalling the kernel.
As for the rest, I’ve already checked or done it, but it didn’t work.
But it also reminded me of “nomodeset”, which I had forgotten about.
As I feared, reinstalling the kernels hasn’t helped.
What bothers me most is not knowing why reinstalling the ESP partition doesn’t restore a functional multiboot for Linux. Windows is another matter.
The file ‘/boot/efi/EFI/ubuntu/grub.cfg’ points to the file ‘/boot/grub/grub.cfg’ in the distribution that manages the menu.
The UUIDs in this file are correct.
Is the UUID of the ESP partition written anywhere?
Is there a problem with ‘/boot/efi/EFI/ubuntu/shimx64.efi’? As long as the ‘ESP’ partition existed, I could install and reinstall distributions and the multiboot system would still work.
Ugh!
I think I found a way to reinstall without formatting using the command line.
However, no matter how hard I search, I can’t find that page anymore.
Any ideas?
Thank you very much for your suggestions, @UB-user, but as I mentioned, everything is fine in that regard. ‘/boot/efi/EFI/ubuntu/grub.cfg’ correctly points to ‘/boot/grub/grub.cfg’, in which all UUIDs are correct, too.
I managed to recover the Zorin 17 and Zorin 18 partitions from my multiboot because the developers had the wisdom (?) to keep the Ubuntu 22.04 installer.
Its ‘Something else’ mode allows you to uncheck the ‘Format’ box for the root partition (‘/’), enabling you to ‘reinstall’ the OS over the previous one.
All packages revert to the versions available when the ISO was released, but no data is lost (documents, images, music, downloads, etc.). You just have to reinstall the Flatpaks — I unsnapified my systems…
I tried reinstalling the kernels and GRUB on a test UB partition, but nothing changed — it just keep spinning at startup.
The only things left to try are retrieving the boot log to see if it reveals anything and digging through the fsck manual to see if I can run a check of all OSes at startup.
I also considered using the empirical method of installing UB 22.04 on a 24.04 test partition without formatting the ‘/’ partition to see what would happen. If that works, the only thing left to do would be to upgrade to 24.04 — but it doesn’t work, of course…
But for now, I prefer to tinker with a script that will allow me to retrieve the lists of installed packages and Flatpaks so that I can quickly restore my installation after a complete reinstallation.
The “backup” part is ready, I still have to test the “restore” part.
What I don’t understand is what ‘broke’ since the other partitions have nothing to do with ‘/boot/efi’ — rEFInd doesn’t work any better — and what gets ‘fixed’ when reinstalling over it.
