Package updating on Debian based distros
 

Ubuntu Mate 18.04 launches the Software Updater program minimized when there are available updates to install. This appears in the lower panel (task bar) and prods me to do the deed. Great!

Mint Mate 19.1 handles this a little differently. A tiny, nondescript shield icon appears in the notification area. I have finally trained myself to look for this thing. Which brings me to the issue...

On the Mint installation (a virtual machine) I currently have the shield shown. If I click on it I am taken to Update Manager which shows me a new kernel (4.15.0.46) available. As I only use this VM occasionally I generally do a manual update when I bring it up after a period of no use. When I ran the appropriate commands I did NOT see the kernel availableI also tried apt-get update and apt-get dist-upgrade. Nothing. Yet the newer kernel is still offered in Update Manager. The current kernelTo quote Monty Python "and now for something completely different..." On an Ubuntu mate 18.04 VM I told Software Updater to check for available updates. It tells me "The software on this computer is up to date." And yet The Software Updater is configured to look for everything as best I can tell.

Which brings me to the question... Which can I trust, the gui or the command line? These VMs are used occasionally for testing so I am not too concerned about them. However, I have two Raspberry Pi machines running Ubuntu 18.04 in a "production" mode. One as the gateway, firewall, dhcp and VPN sharing box for my home LAN and the second as a dedicated Bit Torrent client. Both run headless. The first accessed with ssh and the second with a VNC server. When I see updates on the VNC environment I install them and then run a manual update on the other Pi using the command line. Based on the above experience I do not who which, if either, Pi would be up to date.

Am I missing something?

TIA,

Ken

p.s. I asked on the Mint forum but could not get an answer as to why the gui would tell me something was available which was not available via the command line.

Technically a new kernel is not an update. An update is something that replaces the old version with a new one. Kernels are not usually treated in this way because of the risk that the new kernel won't boot on your hardware; then if the old kernel has been overwritten or deleted, you can't boot at all.

Most distros therefore install a new kernel alongside the old one and modify the bootloader to load the new kernel by default but to allow access to the old one as a fallback. If there is an even older kernel still hanging around, that gets deleted.

Whether a given package management tool recognises a new kernel as a potential update depends on how "smart" it is. Command line tools are often more conservative in this way than graphical tools, because they don't want to preempt the sysadmin's choices, whereas graphical tools are designed for naive users. For example, I have found that apt-get will not upgrade packages that have new dependencies, whereas synaptic will.

Thanks hazel,

I am familiar with how new kernels are installed along with the current one and perhaps a kernel or two back. I have had to boot to an older kernel - especially in CentOS 6 - when my video card was no longer supported or when VMWare had not caught up and I could not build the necessary kernel modules. I guess I am just concerned that the command line does not even inform me that the new kernel is available if I wish to install it. Let me give synaptic a try. I have no used that for a while.

Ken