Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

With respect to the other answers above, I suspect they're answering the wrong question. It sounds like your /boot/grub2/grub.cfg file is simply "messed up" in a way that prevents new-kernel-pkg, the script that runs after each kernel is installed and makes the necessary changes to the boot config, to handle.

So, that's the first thing you could try. uname -r will show you the currently booted kernel. If you have a newer kernel installed (rpm -q kernel will list them all), then try running the following:

sudo new-kernel-pkg -v --mkinitrd --dracut --depmod --make-default --update 4.12.14-300.fc26.x86_64

(Or whatever kernel release listed in the rpm -q output is latest, if you don't have 4.12.14 installed.)

That is SUPPOSED to update your boot config to make the specified kernel the default. If it fails to, hopefully it'll output a message giving some indication why. The kernel updater is smart about keeping the booted kernel around no matter what, and if you're really still running 4.5 (or even 4.12.5) then it's been doing that for a while so it really needs to get sorted out.

If the new-kernel-pkg script doesn't work, the output may tell us why. But you'll probably end up having to regenerate your grub config entirely using grub2-mkconfig. That's a dicey proposition, tho, since it relies on auto detection of things like dual booting / other OSes installed. If you have any of that it can make a mess of things. So, absent more details, let's call that a last resort.

But i wouldn't say that a solution for choosing boot targets manually is what you really want, because it won't fix the update problem. You'll still have to choose the new target manually every time you update the kernel. You want that script to be able to maintain things for you, and it should be able to. If it can't, then that's the real problem you need to fix.

With respect to the other answers above, I suspect they're answering the wrong question. It sounds like your /boot/grub2/grub.cfg file is simply "messed up" in a way that prevents new-kernel-pkg, the script that runs after each kernel is installed and makes the necessary changes to the boot config, to handle.

So, that's the first thing you could try. uname -r will show you the currently booted kernel. If you have a newer kernel installed (rpm -q kernel will list them all), then try running the following:

sudo new-kernel-pkg -v --mkinitrd --dracut --depmod --make-default --update 4.12.14-300.fc26.x86_64

(Or whatever kernel release listed in the rpm -q output is latest, if you don't have 4.12.14 installed.)

That is SUPPOSED to update your boot config to make the specified kernel the default. If it fails to, hopefully it'll output a message giving some indication why. The kernel updater is smart about keeping the booted kernel around no matter what, and if you're really still running 4.5 (or even 4.12.5) then it's been doing that for a while so it really needs to get sorted out.

If the new-kernel-pkg script doesn't work, the output may tell us why. But you'll probably end up having to regenerate your grub config entirely using grub2-mkconfig. That's a dicey proposition, tho, since it relies on auto detection of things like dual booting / other OSes installed. If you have any of that it can make a mess of things. So, absent more details, let's call that a last resort.

But i wouldn't say that a solution for choosing boot targets manually is what you really want, because it won't fix the update problem. You'll still have to choose the new target manually every time you update the kernel. You want that script to be able to maintain things for you, and it should be able to. If it can't, then that's the real problem you need to fix.

Oh, and I forgot to mention: if you're compiling your own kernels for some reason, instead of installing them as rpms from the distribution repos, then the new-kernel-pkg script is the way you'd generate the boot image (initramfs) and set those up in grub, after installing the kernel file into /boot. The only difference is, you'd use --install instead of --update the first time, to add a new entry into the grub.cfg.)