GRUBble Trouble
My GRUB woes
I’m not one for superstitions, but I did manage to cause one of my hosts to become unbootable today. I was trying to extend /boot and shrink the EFI partition, after having sized them improperly during the installation. /boot was filling up anytime there were more than two kernels installed—a common occurrence—and /boot/efi was almost empty.
Unlike, say, the root file system, you can easily backup, unmount, delete, re-create, and restore the boot and EFI partitions while the system is running:
rsync -av /boot/efi/ /my_backup/efi_backup # backup efi
umount /efi # unmount /efi
rsync -av /boot/ /my_backup/boot_backup # backup /boot
umount /boot # unmount /boot
...then destroy and re-create the partitions as needed—in my case /boot as ext4 and /boot/efi as fat32 with esp and boot flags, and then:
blkid |grep -Ei "boot|efi" # find the UUIDs for any boot/EFI partition labels
...edit /etc/fstab to replace the UUIDs for the /boot and /boot/efi entries (you could do this with sed -i, but I didn’t feel like figuring out the syntax), then:
mount -a # attempt to mount everything; efi will fail
mkdir -p /boot/efi # make the mount point for EFI in /boot
rsync -av /my_backup/boot_backup/ /boot # restore backup of /boot
mount -a # mount everything
rsync -av /my_backup/efi_backup/ /boot/efi # restore backup of /boot/efi
Now, at this point, I stupidly rebooted, because it was my incorrect impression that, with UEFI in use, GRUB was no longer installed to the MBR in this case. You, reader, will be much smarter than I was.
On my next boot, I was confronted with the GRUB rescue screen. There, I had to follow these steps:
ls # list all available devices
ls (hd6,gpt2)/boot/grub) # list the devices until you find the one with GRUB
set prefix=(hd6,gpt2)/boot/grub
set root=(hd6,gpt2)
insmod linux
insmod normal
normal
The system booted. Rebooting immediately put me back to the GRUB rescue prompt. After repeating the manual boot steps above, I did:
grub-install
update-grub
reboot
Back in business!
Comments ()