I've had this problem for a while now and I thought it would be fixed once I upgraded to 20.04. Whenever I update a kernel - the path to the new kernel is not automatically updated in the vmlinuz & initrd sym links - I have to do it manually via the command line. I had HWE enabled in 18.04 before I upgraded to 20.04 - maybe that's part of the problem? Thanks for the help!
@nemo, while I do not fully understand the kernel install/upgrade process, I found a configuration file that you may want to check to see if it is different in your case. It is /etc/kernel-img.conf. Mine reads as below.
sai@sai-HP-Laptop-14-bs0xx:~$ cat /etc/kernel-img.conf
# Kernel Image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
do_bootloader = no
In case your file has do_symlinks = no, you may try making it 'yes'.
Hi @nemo, my Virtual machines of default 18.04 and 20.04 clearly indicates both those links were moved from / to /boot. These are not upgrades but likely the same move.
FYI, I checked the conf file @saivinob mentions and both say do_symlinks = yes. Yet their locations differ.
I'm also no expert on these changes (anyone?) but those symlinks have been there for decades. Are you getting errors? Is it possible you don't need to make those links?
EDIT: Sorry, I misread. But it still may get you in the right direction.
I just checked my kernel-img.conf file and it says do_symlinks =yes.
I have grub customizer installed, maybe that's stopping the symlinks from being updated?
It's not a major issue - it takes about 2 minutes to update the links. If I don't update the symlinks then the system boots the old kernel & not the new one.
Do you guys (or anyone else for that matter) know how to write a script to update these symlinks?
@nemo, looks like your suspicion about HWE is correct. Although I found /etc/kernel-img.conf by chance, it does play a role in creating symlinks and where the symlinks are created. Further poking lead to linux-update-symlinks which is the one that actually creates symlinks. This is called by postinst/postrm scripts in kernel package.
I could see this called out in regular kernel package (check any kernel source package) but I could not see any such script in -hwe kernel package. Don't take my word for it though.
Regarding script, you can probably use linux-update-symlinks as called out in postinst script. I'm not a devel so cann't help with a script. Someone else could help.
Below is full postinst script from a generic kernel package.
#!/bin/sh
set -e
version=@abiname@@localversion@
image_path=/boot/@image-stem@-$version
#
# When we install linux-image we have to run kernel postinst.d support to
# generate the initramfs, create links etc. Should it have an associated
# linux-image-extra package and we install that we also need to run kernel
# postinst.d, to regenerate the initramfs. If we are installing both at the
# same time, we necessarily trigger kernel postinst.d twice. As this includes
# rebuilding the initramfs and reconfiguring the boot loader this is very time
# consuming.
#
# Similarly for removal when we remove the linux-image-extra package we need to
# run kernel postinst.d handling in order to pare down the initramfs to
# linux-image contents only. When we remove the linux-image need to remove the
# now redundant initramfs. If we are removing both at the same time, then
# we will rebuilt the initramfs and then immediatly remove it.
#
# Switches to using a trigger against the linux-image package for all
# postinst.d and postrm.d handling. On installation postinst.d gets triggered
# twice once by linux-image and once by linux-image-extra. As triggers are
# non-cumulative we will only run this processing once. When removing both
# packages we will trigger postinst.d from linux-image-extra and then in
# linux-image postrm.d we effectivly ignore the pending trigger and simply run
# the postrm.d. This prevents us from rebuilding the initramfs.
#
if [ "$1" = triggered ]; then
trigger=/usr/lib/linux/triggers/$version
if [ -f "$trigger" ]; then
sh "$trigger"
rm -f "$trigger"
fi
exit 0
fi
if [ "$1" != configure ]; then
exit 0
fi
depmod $version
if [ -f /lib/modules/$version/.fresh-install ]; then
change=install
else
change=upgrade
fi
linux-update-symlinks $change $version $image_path
rm -f /lib/modules/$version/.fresh-install
if [ -d /etc/kernel/postinst.d ]; then
mkdir -p /usr/lib/linux/triggers
cat - >/usr/lib/linux/triggers/$version <<EOF
DEB_MAINT_PARAMS="$*" run-parts --report --exit-on-error --arg=$version \
--arg=$image_path /etc/kernel/postinst.d
EOF
dpkg-trigger --no-await linux-update-$version
fi
exit 0
Just an update on my situation. I installed a new kernel today and then ran sudo linux-update-symlinks and got the following error:
`Usage: /usr/bin/linux-update-symlinks {install|upgrade|remove} VERSION IMAGE-PATH
This command is intended to be called from the postinst and postrm
maintainer scripts of Linux kernel packages. The postinst script must
pass the first argument 'install' or 'upgrade' depending on whether a
fresh installation or an upgrade has taken place.
The VERSION argument must be the kernel version string as shown by
'uname -r' and used in filenames.
The IMAGE-PATH argument must be the absolute filename of the kernel
image.`
What arguments do I need to add to this command to make it work?
@nemo, I tried some combination but it messed the vmlinuz symlinks on my PC. I think it is not a good idea to run it on its own but rather should be called from a postinst script as it says. You could file a bug (or feature request) and continue to do manual symlink till it is fixed.
Thanks @mdooley! I'll give this a shot the next time I get a new kernel & report back my results. Thanks guys for all your efforts to solve my problem!