I would like to know if there is a way to know and compare the running versus the stored Linux kernel version.
I usually use $ uname -a
Linux montag 5.0.7-arch1-1-ARCH #1 SMP PREEMPT Mon Apr 8 10:37:08 UTC 2019 x86_64 GNU/Linux
… but it only gives me the running version… any help will be very much appreciated.
There will only be the current unless you set it up to keep other versions or install a different kernel without removing the current.
This isn’t like ubuntu or even manjaro where you would have multiple versions of the same kernel (mainline, lts, zen, etc…) arch maintains the kernels and only the current versions for each are officially supported. I believe you can however get different versions from the AUR or of course compile your own.
If you’re running grub and for example, install the lts kernel without removing the mainline kernel, grub will pick up both and add a menu entry for each under the advanced section. With other bootloaders you would need to create entries for each yourself.
Thank you very much for your kind reply, the information received is very useful. Maybe this will clarify my question:
. when you run the update process and it installs a new kernel, this will run the next time you reboot your computer. The reboot schedule can be days ahead. Then I would like to know and make sure which version is saved and which is running.
It seems the pacman -Q linux reports the saved kernel… I will have to check next time I update the kernel.
Installed kernel: pacman -Q linux
Running kernel: uname -r
Available kernel: pacman -Si linux - Note this only shows the newest kernel available in the local database, so repositories should be updated before!
As I am sometimes lazy rebooting, running not the latest installed kernel sometimes lead to issues, like breaking USB tethering or undervolting, I made this script (warning, noob here!):
#! /usr/bin/env zsh
installed_kernel=$(pacman -Q linux | cut -d' ' -f2 | sed -e 's/.\([^.]*\)$/-\1/')
running_kernel=$(uname -r | cut -d- -f1,2,3)
available_kernel=$(pacman -Si linux | sed -n 3p | cut -d: -f2 | tr -d " " | sed -e 's/.\([^.]*\)$/-\1/')
# DEBUG
#echo -e "running:\t$running_kernel\ninstalled:\t$installed_kernel\navailable:\t$available_kernel\n"
#installed_kernel="21301"
#running_kernel="12300"
#available_kernel="32123"
#tabs 4
SUDO=''
read -k 1 "REPLY?Check for kernel update? (y/n)"
if [[ "$REPLY" =~ ^[Yy]$ ]]
then
echo
if [ $(id -u) -ne 0 ]
then
SUDO='sudo'
$SUDO pacman -Syy
else
pacman -Syy
fi
available_kernel=$(pacman -Si linux | sed -n 3p | cut -d: -f2 | tr -d " " | sed -e 's/.\([^.]*\)$/-\1/')
echo
fi
if [ "$installed_kernel" = "$running_kernel" ]
then
echo -e "\e[32mKernel in sync!\t\e[1m$running_kernel\e[0m\n"
if [ "$running_kernel" != "$available_kernel" ]
then
echo -e "However, new kernel available:\t\e[33m\e[1m$available_kernel\e[0m"
read -k "REPLY?Upgrade system now? (y/n)"
if [[ "$REPLY" =~ ^[Yy]$ ]]
then
if [ $(id -u) -ne 0 ]
then
SUDO='sudo'
$SUDO pacman -Syu
else
pacman -Syu
fi
fi
fi
else
echo -e "\e[31mkernel out of sync!\e[0m"
echo -e "running:\t\e[31m\e[1m$running_kernel\n\e[0minstalled:\t\e[32m\e[1m$installed_kernel\e[0m"
if [ "$installed_kernel" != "$available_kernel" ]
then
echo -e "available:\t\e[33m\e[1m$available_kernel\e[0m"
fi
read -k 1 "REPLY?Reboot new kernel now? (y/n)"
if [[ "$REPLY" =~ ^[Yy]$ ]]
then
reboot
else
exit 1
fi
fi
Maybe the first two lines are interesting for you, as they output compareable strings:
installed_kernel=$(pacman -Q linux | cut -d' ' -f2 | sed -e 's/.\([^.]*\)$/-\1/')
running_kernel=$(uname -r | cut -d- -f1,2,3)
If the system is not rebooted immediately after a kernel upgrade then it will be unable to access any kernel modules (need for tasks such as filesystem mounting) so it’s usually best to reboot sooner rather than later.
That can break your system if the package databases are updated before you install another package, the ArchWIki has a warning against pacman -Sy (also known as a partial upgrade):
When I was grabbing it from the terminal it was some cat ... | grep ... | ... | .. and I only removed the cat because I knew it would be a comment but my caring stops there, pipelines are fine when used interactively, though I try to avoid and optimise in scripts.