Ubuntu Server boots to grub rescue after every kernel upgrade, have to revert to older kernel to boot, wrong disk in grub?

colorpurple21859 · 10-22-2020, 10:34 PM

Code:

Does it matter that it's not software RAID, but a HW RAID

I don't know, but I suspect it is part of the problem, maybe someone will chime in that knows more about it.

surfrock66 · 10-22-2020, 11:37 PM

Sidebar, I have a 64GB spare SSD. Could I install that and put the UEFI partition there, and point it to the VD?

colorpurple21859 · 10-23-2020, 07:18 AM

I Think that will work, If it was me, I would a least give it a try. Maybe another option is set up a usb key to boot the system.

See if this gets you going

Code:

grub-install --target=i386-pc --modules="raid5rec" --boot-directory=/mnt/boot

surfrock66 · 10-23-2020, 12:01 PM

Still no go; I ended up adding "/dev/sda" to the end since that didn't specify a target.

If I throw in the 64GB SSD, what would the procedure be for converting that to boot? I think I understand the general idea, but I want to make sure...

1) Partition the SSD, make a 1GB efi partition at the front, then make a 16mb partition after that. efi partition is FAT32 and flagged as boot, 16MB partition is cleared, labeled bios-boot, and has the bios_grub flag
2) Confirm the lettering (I'm guessing the new drive will be /dev/sdb) and repeat the grub-install commands to remove the modules, targeting /dev/sdb

I should be able to blow away /dev/sda1 and /dev/sda3 in that case, correct? I feel like I should do that first, extend /dev/sda2 so it takes the whole virtual disk, but then reboot because it'll now be known as /dev/sda1. Then, in a fresh live-environment cycle, I'd need to confirm all drive letters. How do I specify that /dev/sda will contain root?

colorpurple21859 · 10-23-2020, 01:18 PM

flag the efi partition esp. Mount /dev/sda2 /mnt, mount the new ssd efi partition to /mnt/boot/efi. On the first run do grub-install --boot-directory=/mnt/boot /dev/<ssd drive> .
If it was me I wouldn't do any partition changes on /dev/sda until the system was booting

surfrock66 · 10-23-2020, 02:28 PM

Sounds good; my only reasoning for that is if I delete the partitions before /dev/sda2, is /dev/sda2 gonna get re-id'd as /dev/sda1?

colorpurple21859 · 10-23-2020, 03:10 PM

That is a good possibility, however if your fstab and grub.cfg uses uuids that shouldn't be an issue. Just hate adding a new issue before fixing the old issue.

colorpurple21859 · 10-23-2020, 07:22 PM

This may work better to reinstall grub by chrooting into the system from live iso.

Code:

mount /dev/sda2 /mnt
mount /dev/<efi partition> /mnt/boot/efi
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount -o bind /run /mnt/run
chroot /mnt
grub-install /dev/<drive with efi partition?>
exit
reboot

surfrock66 · 10-24-2020, 01:27 AM

Ok, abort, per this, I'm out of luck on EFI: https://www.dell.com/community/Power...x/td-p/7521058

I embraced legacy boot, cleared out those partitions, made a 16MB bios_grub partition, booted into the live environment, did boot-repair, and it's now up and running perfectly.

Thanks for all the help; I've learned a bunch and appreciate your time!

colorpurple21859 · 10-24-2020, 07:49 AM

Code:

Ok, abort, per this, I'm out of luck on EFI

I don't think it really matters if one uses efi mode or legacy mode to boot a system as long as the system boots. The issue usually comes in when mixing uefi and legacy on a a multiboot system or when the system is using one and the live iso is using the other when attempting a fix. It is easier fixing a legacy boot from efi booted iso, then the other way around
AT least you got it working again.