Tell Apt to Stop Upgrading My Kernel since I use the Linode-provided kernel?

Oh, sidebar, mostly a question to the "Linode engineering team":

Are there enhancements/efficiencies added to the Linode build of the kernel that you guys are providing for Linodes to boot from? Not a big deal if not, but if so, it's even more of a reason to manage my Linode's kernel this way.

Thanks again!

You can use 'apt-mark hold' to put a hold on a package to prevent it from being automatically upgraded, installed, or removed:

apt-mark hold examplepackage

This can apply to any number of packages. To check which packages you have set on hold, you can use:

dpkg --get-selections | grep "hold"

To remove the hold flag, you can use:

apt-mark unhold examplepackage

The kernel package installed in Ubuntu is usually called 'linux-image-generic' but there's also 'linux-headers-*' in /usr/src that can be put on hold as well.

Our Linux kernels are as close to the stock Linux kernel as possible, and in general we're moving towards having newer images boot with Grub by default since it allows for enabling, changing, or disabling modules in the distro-supplied kernel. However, we'll have our Linux kernel available for the foreseeable future if you'd like to continue using it.

@programsam Hi! I'm the primary engineer at Linode responsible for building our kernels. I'm glad you're enjoying this feature of Linode, and I wanted to take a moment to respond to your follow-up "sidebar" question.

First, a big difference between our kernel vs. what you might find on a distribution like Debian/Ubuntu is that our kernels are very vanilla - we apply very few patches to the upstream source code (usually none).

Another big difference is that Linode kernels do not use kernel modules like what you find on most distros. Instead, support for all of our (virtualized) hardware and features is built directly into the kernel itself. This means that we don't need to install any additional files onto your Linode in order to use our kernel, and results in a smaller kernel overall.

This of course also means that you can only use features of the kernel that we've explicitly built in, whereas on distribution-supplied kernels you can load kernel modules on the fly to extend its functionality. We try to account for all of our customers' use-cases when building our kernels, but occasionally we miss things and we encourage customers to let us know if there's something they'd like us to include in our kernels. We can build and deploy new kernels pretty quickly, so ultimately I think the trade-off is worth it.

Lastly, if you are interested to see what our kernel configuration looks like, you can run zcat /proc/config.gz on any Linode running one of our kernels. This will print all of the options that the kernel was built with.

Feel free to follow-up and "@" me if you have any other questions, and thanks for using Linode!

@mjones -- so I think this means I shouldn't see any kernel update notifications from apt any more:

root@li319-50:~# dpkg --get-selections | grep "hold"
linux-headers-generic                hold
linux-image-generic                hold

Am I right? I know also that various packages or programs dynamically link to the Linux Headers because they are in some sense the root of all actions you do with a computer, especially in Linux (I mean when you read a file, you eventually have to talk to the Kernel, amiright?)

At the moment, my Linode says this:

root@li319-50:~# apt-cache policy linux-image-generic
linux-image-generic:
  Installed: 4.15.0.44.46
  Candidate: 4.15.0.44.46
  Version table:
 *** 4.15.0.44.46 500
        500 http://mirrors.linode.com/ubuntu bionic-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     4.15.0.20.23 500
        500 http://mirrors.linode.com/ubuntu bionic/main amd64 Packages
root@li319-50:~# apt-cache policy linux-headers-generic
linux-headers-generic:
  Installed: 4.15.0.44.46
  Candidate: 4.15.0.44.46
  Version table:
 *** 4.15.0.44.46 500
        500 http://mirrors.linode.com/ubuntu bionic-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     4.15.0.20.23 500
        500 http://mirrors.linode.com/ubuntu bionic/main amd64 Packages
root@li319-50:~# uname -a
Linux li319-50 4.18.16-x86_64-linode118 #1 SMP PREEMPT Mon Oct 29 15:38:25 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

So with my new/current understanding, I'm running kernel v4.18.16 64bit from Linode's engineers (thanks @lblaboon!), but I have headers from Linux kernel version 4.15.0.44.46 -- I'm guessing this may cause problems if I try to install packages that compile on the machine and reference the Linux kernel header files -- am I on the right track here?

I also still have things in /boot, which makes me sad:

root@li319-50:~# ls /boot
grub  initrd.img-4.15.0-44-generic

Interestingly enough (to me, anyway), if I try to uninstall that older version of the kernel that I'm not even booting with:

root@li319-50:~# apt remove linux-image-4.15.0-44-generic
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 linux-image-generic : Depends: linux-image-4.15.0-44-generic but it is not going to be installed
                       Depends: linux-modules-extra-4.15.0-44-generic but it is not going to be installed
                       Recommends: thermald but it is not going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

And, in /usr/src:

root@li319-50:~# ls /usr/src
linux-headers-4.15.0-43          linux-headers-4.15.0-44
linux-headers-4.15.0-43-generic  linux-headers-4.15.0-44-generic

I've tried some fancy footwork…

root@li319-50:~# apt remove linux-headers-generic
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  linux-generic linux-headers-generic
The following held packages will be changed:
  linux-headers-generic
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 30.7 kB disk space will be freed.
Do you want to continue? [Y/n] Y
(Reading database ... 87215 files and directories currently installed.)
Removing linux-generic (4.15.0.44.46) ...
Removing linux-headers-generic (4.15.0.44.46) ...
root@li319-50:~# ls /usr/src
linux-headers-4.15.0-44  linux-headers-4.15.0-44-generic

And was only able to get this down to:

root@li319-50:~# ls /usr/src
linux-headers-4.15.0-44  linux-headers-4.15.0-44-generic

Which I guess is livable, quite honestly. It's not like my whole virtual drive is being filled with headers ;)

@lblaboon --

Thank you for your detailed response! This is close to what I had imagined; that you guys would have streamlined the process, included only what was needed and not what was not. De-bloating things is always something I'm a fan of. I mostly use my Linode for manual web hosting and the occasional Node.js app or an experiment or two, so a kernel with the specs you describe is just about perfect for my purposes -- no complaints here!

@mjones --

You said:

we're moving towards having newer images boot with Grub by default since it allows for enabling, changing, or disabling modules in the distro-supplied kernel.

Well, I'm sure people have asked for it, but I'm not one of them. This isn't a Raspberry Pi for gosh sakes, it's a lean and mean VM that's out there serving up websites. At least for me. If I want to do some crazy stuff involving kernel modules, I'd jump into a different/separate VM. Probably locally. I'd use something more transient and temporary. I like that my Linode keeps on clicking and ticking when I don't mess with it for months -- that's why we all got into Linux in the first place for gosh sakes.

Overall, I just really enjoyed having at least one machine that didn't require me to deal with figuring out whether the latest release from upstream is stable or will have bugs… whether it's the right flavor, etc.

Ok, you guys have been extremely helpful. Thank you so much!