Ubuntu Server boots to grub rescue after every kernel upgrade, have to revert to older kernel to boot, wrong disk in grub?
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
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.
Ubuntu Server boots to grub rescue after every kernel upgrade, have to revert to older kernel to boot, wrong disk in grub?
I have a relatively new Ubuntu server but every time I reboot, I'm sent to GRUB rescue and have to do some weird stuff to get it to work. First, here's my partition layout from within the working server:
So, it reboots, I get brought to GRUB rescue. If I do the following:
Code:
set prefix=(hd0,gpt2)/boot/grub
set root=(hd0,gpt2)
insmod normal
normal
boot
I get:
Code:
Error: you need to load kernel first
If I try to load the kernel with the following:
Code:
insmod linux
linux /boot/vmlinuz root=/dev/sda2
I get:
Code:
error: attempt to read or write outside of disk “hd0″
Instead, if I do the following:
Code:
linux /boot/vmlinuz-5.4.0-45-generic root=/dev/sda2
initrd /boot/initrd.img-5.4.0-45-generic
boot
I'm good to go.
I'm in over my head a bit here, what's the best course of action for getting this so the system can safely reboot after a kernel update? Try to move /boot back to sda1? Change some configuration so it remembers to point to sda2?
Last edited by surfrock66; 10-13-2020 at 11:09 AM.
Since it's a "relatively new Ubuntu server" it should be EFI rather than BIOS - so you'd need a EFI partition, not a BIOS_boot. Go here and do as it says - that way we'll all have some relevant info.
was sda1 mounted to /boot originally, and if so why did you change it? What did you do to change /boot/ to sda2?
Was sda1 an efi parition formatted fat32 originally?
Your probably getting the grub-rescue because you didn't run
Code:
sudo grub-install --force /dev/sda
after moving /boot to /sda2. If that will even work. Not all distros grub-install will install bootloader code to the mbr of gpt type disk. At the grubrescue prompt what is the output of
After trying to install grub, the server is completely unbootable. If I boot from a live environment, I can chroot into my drive and all my data is there, but the system is totally unbootable.
I tried using boot-repair, but that also did not fix it. It did give me useful debug output though, so I'm not sure if this can help me figure out what to do next:
give more details, grub-rescue>, grub> prompt, grub-menu but hangs when selecting menu item, something else? What happens when you go into the bios boot menu do you have more than one choice, does the bios boot menu have the option to boot from file?
Last edited by colorpurple21859; 10-21-2020 at 06:11 PM.
I believe for some reason or another the system isn't wanting to boot sda in efi mode. I think this will work for a quick fix.
boot a live iso, With gparted shrink the fat32 partition so you will have a 2mb space between the efi partition and root partition. In the 2Mb space create a new cleard partition labeled bios-boot and flag it as bios_grub,
Code:
mount /dev/sda2 /mnt
grub-install --target=i386-pc --boot-directory=/mnt/boot /dev/sda
Last edited by colorpurple21859; 10-22-2020 at 09:28 AM.
I made that efi partition 1GB since I had the space, is that too big? Is there a target I should go for; I often see "100-200mb" recommended but haven't found an upper limit.
I'll do those things now, the system is powered off in the rack room.
I made that efi partition 1GB since I had the space, is that too big?
Yes usually it is smaller, the size of the efi partition isn't the issue.
This is just a guess of what is happening, the system isn't allowing sda to boot in efi mode. To allow to boot in legacy mode, You need a 1-2 mb partition cleared/empty with the bios-grub flag set. This will allow grub to install in legacy mode to sda mbr.
The boot code needed for grub to boot in legacy mode on a gpt disk in split between the mbr and the bios-boot partition.
The grub code that goes in bios-boot was located on the efi partition, when "grub-install --target=x86_64-efi" was ran the grub code on the efi partition was overwritten, henceforth unable to boot sda.
Ok. I went through the RAID configuration; as far as I can tell everything is correct. It's a 5-disk raid5 made from 1TB disks, which specifically should be ok as the PERC 6/i has an issue with disks over 2TB in size (not virtual disks, individual disks, reference: https://community.spiceworks.com/top...-dell-perc-6-i ). The bootable VD is correct (the only one) and "Enable controller BIOS" is checked. Pictures attached.
I created the partition (it's 16MB because if I didn't do that, the efi partition got moved to start at 14MB on the disk). Picture attached.
I did the grub install exactly as indicated and it said no errors to report. I rebooted, it returned to grub rescue. When I do "ls" I get the following:
(proc) (hd0) (cd0)
When I do set I see "prefix=(hd0)/EFI/ubuntu" but when I do ls of (hd0) or any sub directory I get "error: unknown filesystem."
I guess grub is no longer seeing the gpt partitions? In gparted from the live environment, everything looks fine and I can see all my data. Doing "insmod part_gpt" doesn't help
Last edited by surfrock66; 10-22-2020 at 02:13 PM.
Does it matter that it's not software RAID, but a HW RAID through the dell PERC6/i controller? I don't know why I didn't mention it, I think I did in a post somewhere else and just forgot that part here, my apologies.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.