Tell Apt to Stop Upgrading My Kernel since I use the Linode-provided kernel?
According to https://www.linode.com/docs/platform/how-to-change-your-linodes-kernel/, one option for using a kernel in my Linode is:
The Linode kernel. Linode maintains an up-to-date kernel: Linode’s engineering team monitors for new versions of the Linux kernel and then packages them for users shortly after they are available. These kernels are not installed on your filesystem -- instead, the Linode Manager supplies them at boot time to your system.
I love this feature. I've always hated dealing with kernel updates, and having the
/boot partition fill up with old, unused kernels is an annoying part of server maintenance. When I use Linode, I don't have to worry about this because through some sort of amazing magic, the
/boot partition, Grub, all this other gorp I don't need is skipped!
When I create a new configuration profile for my Linode, I just select the Linode-built kernel I'd like to use and it is "provided to my system at boot time". Please detect my non-sarcasm/earnestness when I say that I absolutely adore this feature.
So no, I'm not looking to understand Grub, or how the bootloader works, or etc. The problem I'm facing is that currently, when I become root using
sudo, and try to get latest package upgrades (something I want to do regularly, or have done for me using autoupdate), I get this:
# apt install Reading package lists... Done Building dependency tree Reading state information... Done The following package was automatically installed and is no longer required: linux-modules-4.15.0-32-generic Use 'apt autoremove' to remove it. The following packages will be REMOVED: linux-image-4.15.0-32-generic 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. 2 not fully installed or removed. After this operation, 8,294 kB disk space will be freed. Do you want to continue? [Y/n]
OK, I don't let it do this, because I want to be more explicit. So I run
autoremove and get this:
# apt autoremove Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-image-4.15.0-32-generic linux-modules-4.15.0-32-generic 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. 2 not fully installed or removed. After this operation, 74.4 MB disk space will be freed. Do you want to continue? [Y/n] Y (Reading database ... 117627 files and directories currently installed.) Removing linux-image-4.15.0-32-generic (4.15.0-32.35) ... W: Last kernel image has been removed, so removing the default symlinks /var/lib/dpkg/info/linux-image-4.15.0-32-generic.postrm ... removing pending trigger /etc/kernel/postrm.d/initramfs-tools: update-initramfs: Deleting /boot/initrd.img-4.15.0-32-generic /etc/kernel/postrm.d/x-grub-legacy-ec2: Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... Could not find /boot/grub/menu.lst file. Would you like /boot/grub/menu.lst generated for you? (y/N) /usr/sbin/update-grub-legacy-ec2: line 1101: read: read error: 0: Bad file descriptor run-parts: /etc/kernel/postrm.d/x-grub-legacy-ec2 exited with return code 1 dpkg: error processing package linux-image-4.15.0-32-generic (--remove): installed linux-image-4.15.0-32-generic package post-removal script subprocess returned error exit status 1 Removing linux-modules-4.15.0-32-generic (4.15.0-32.35) ... Errors were encountered while processing: linux-image-4.15.0-32-generic E: Sub-process /usr/bin/dpkg returned an error code (1)
So clearly some part of the grub/default boot process for the typical way of managing a Linux boot partition is lying around. I just want to disable it entirely. Oh, and I don't want apt to tell me that there's a new kernel -- I'll figure that out (I'm on the mailing list… ahem)… and I'll upgrade once I've seen it out in the yard long enough to be considered trustworthy. By then, Linode typically has it available in the manager. So I'll just reboot my Linode from the manager and automagically pick it up.
Anybody know how to disable the kernel-management features of
dpkg? I've tried removing the
/boot directory entirely. I guess maybe there's some stuff I should get rid of in
There's also an interesting setting in the "Configuration Profile" page from Linode that says:
modules.dep Helper -- Creates a modules dependency file for the kernel you run
I have this switched to
Yes but I'm not seeing any effects from it in the sense that I guess I'm getting the modules but I'm also getting the kernel, which I do not want.
Any help that does not begin "here's how you install the latest Kernel" would be gratefully appreciated.
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.
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: 18.104.22.168.46 Candidate: 22.214.171.124.46 Version table: *** 126.96.36.199.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 188.8.131.52.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: 184.108.40.206.46 Candidate: 220.127.116.11.46 Version table: *** 18.104.22.168.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 22.214.171.124.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 126.96.36.199.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.
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 (188.8.131.52.46) ... Removing linux-headers-generic (184.108.40.206.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 ;)
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!
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!