0

I recently updated my kernel on CentOS 6.7. That also cleaned up all the older versions, which also updated my /boot/grub/grub.conf, it has a single entry (of the new kernel). Now, when I rebooted, the boot fails with an error "file not found", the reason being, it is still trying to boot with the older kernel, which is not there anymore under /boot. When I go to the list of kernels page, it listed only the older kernel (which again isn't there anymore), no sign of the new kernel in this list. Finally, I had to boot using the grub command line, it worked fine. I have verified /etc/grub.conf, it is a sym link to /boot/grub/grub.conf. There is also one more grub.conf under /boot/efi/EFI/redhat/, but that is also identical to /boot/grub/grub.conf. I searched for the kernel version string to check if it is still referred somewhere, it is not. Then I found out that this was beyond me, something is still not good. Please advice me.

Update This may have something to do with the latest BIOS update, where uefi boot is enabled now. When I manually select the boot drive, I see 2 options one starting with UEFI aaaaaa OS Bootloader and another which starts with SATA aaaaaaaa Boot Drive. When I select the boot drive, it is booting with the latest kernel. Should I modify anything after the BIOS update?

12
  • 1
    My experience of grub is on Ubuntu, so I don't know how relevant it is, but there is a command sudo update-grub which will rebuild the configuration file at any time, especially after calling /etc/default/grub. If you don't have this script, all it does is call grub-mkconfig -o /boot/grub/grub.cfg, so you can use this command instead. However, the normal software update process should call this automatically whenever there is a new kernel and I don't know why this has not happened in your case.
    – AFH
    Mar 30, 2016 at 11:35
  • Do you have a separate boot partition and/or other physical disks (bootable or not) on the system? It doesn't sound like it's part of the problem here, but it's worth being sure.
    – Tim G
    Mar 30, 2016 at 12:07
  • My env still uses the legacy grub (0.97) so there is no option to do grub-mkconfig. Mar 30, 2016 at 12:21
  • @MaheshHViraktamath grub legacy does not use grub.cfg but menu.lst
    – Tom Yan
    Mar 30, 2016 at 14:12
  • @TomYan Thanks for the clarification, my menu.lst is pointing to grub.conf, should it not be a symlink by any chance? Mar 30, 2016 at 14:19

2 Answers 2

0

You're able to boot via grub command line? Just edit grub.conf to match the fixes you made for your one-time-boot, make a backup, and see below about grub-mkconfig.

---- I re-read and found more details; the below section assumes you couldn't boot ----

Since you cannot boot, you can try two things: Edit the boot.cfg manually, or boot a rescue-disk/live-cd and run grub-mkconfig.

The first option requires you know the name of the new kernel file or can find it (like with a rescue-disk/live-cd). Edit /boot/grub/grub.cfg (or press the hotkey at the grub menu to just edit the boot line for one-boot) and find the line that includes "linux [...] vmlinuz[...]. You need to change the vmlinuz section of the line to match the new file name. If applicable, you'll also need to change the initramfs section to the appropriate new file name. Save it and see if you can boot (or make the edit in grub and see if it boots, then edit it once you're in.)

grub-mkconfig will obliterate these changes if it doesn't work right, though, so if you work yourself up to something that boots at all, save the working grub.cfg as a backup.

The final step is to ensure that (sudo) grub-mkconfig -o /boot/grub/grub.cfg will correctly generate the right boot lines. If you're on a live-cd and haven't managed to boot into the OS yet, use chroot to change root to your actual disk so it picks up the right boot files (and don't forget to mount /boot if it's a separate partition). Run the command and see if it boots.

The grub-mkconfig step isn't strictly necessary if you manage to make it a bootable system, but it's best practice and updates will probably wreck your boot again if grub-mkconfig isn't functional.

If it turns out grub-mkconfig isn't functional, you'll need to do some diving into /etc/grub(.d) to find which config file isn't behaving properly. Those configuration files are very complicated to be able to handle many situations, so you can simplify, comment-out and hard-code your own things to make it work for you again.

Good luck.

1
  • My env still uses the legacy grub (0.97) so there is no option to do grub-mkconfig. Mar 30, 2016 at 12:21
0

My env still uses the legacy grub (0.97) so there is no option to do grub-mkconfig.

Do you agree for updating fromgrub legacy to grub2?

Then you can update it with apt-get, then:

sudo grub-install /dev/sdX --boot-directory=/your_boot_folder.

Then, do the already talked command : sudo grub-update (grub-mkconfig...)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .