20

I got a notification of updates to Ubuntu 20.04. I always check the list of updates to decide how serious a backup I need to do before updating. Today's kernel update (5.13.0.28.31~20.04.15) needs half a gigabyte of extra disk space:

$ sudo apt upgrade 
...
The following NEW packages will be installed:
  linux-headers-5.13.0-28-generic linux-hwe-5.13-headers-5.13.0-28
  linux-image-5.13.0-28-generic linux-modules-5.13.0-28-generic
  linux-modules-extra-5.13.0-28-generic
The following packages will be upgraded:
  linux-generic-hwe-20.04 linux-headers-generic-hwe-20.04
  linux-image-generic-hwe-20.04 linux-libc-dev
4 to upgrade, 5 to newly install, 0 to renove and 0 not to upgrade
Need to get 95.0 MB of archives.
After this operation, 508 MB of additional disk space will be used.

I know that Ubuntu allows several kernels to coexist, so this kernel must use fresh disk space rather than replacing existing software, but it still seems large. I've not kept notes, but I thought a kernel update was usually a couple of hundred MBs. Have I just never noticed the size of kernels before or is there something unusual about today's update?

0

3 Answers 3

43

There are a few of different things going on here, depending on where your curiosity lies...

Kernels updates are delivered as standalone packages, not simple upgrades

Most of your system is packaged in such a way that when an upgrade is extracted, it replaces the last version. Kernels are packaged with their version in the package name. This affords you the ability to fall back to a previous version if something goes wrong.

You don't need to keep the old kernels around. As soon as you know the new one works, you can remove the old ones. sudo apt autoremove will do this for you, but make sure the new version works first.

Kernels are big (and are getting bigger)

So we've established why installing an updated kernel takes up additional space, but why so much space?

Ubuntu ships a kernel built for a wide selection of hardware. Canonical wants it to Just Work™ when you plug things in. Every minor version has more drivers added to it. The rate of old drivers being removed is typically much slower.

So over time we expect the kernel to bloom in size. Bionic's 4.15.0-101.102 is roughly 60% the size of Focal's HWE 5.13.0. This is mostly expressed through having fewer modules especially in modules-extra.

I like to think of this as progress. Disk space and bandwidth is cheap for most of us, so prioritising driver support makes sense. I don't think what we're seeing here is abnormal.

But why are their packages so small? How does a 94MB download take up 508MB of disk space?

They compress [really] well. You can see this by downloading the packages and using a little scripting to expose their unpacked size.

  • Get the packages: apt download linux-generic-hwe-20.04 linux-headers-generic-hwe-20.04 linux-image-generic-hwe-20.04 linux-headers-5.13.0-28-generic linux-hwe-5.13-headers-5.13.0-28 linux-image-5.13.0-28-generic linux-modules-5.13.0-28-generic linux-modules-extra-5.13.0-28-generic
  • Compare their "physical" size with their contents' size: for f in *.deb; do stat --printf="%5n\t%s\t" "$f"; dpkg -c $f; done

That's pretty raw at that point. You can scootch it into Calc to show totals and percentages:

enter image description here

Somewhat more than 508MB of disk space combined (before DKMS too) but perhaps you already had some of the packages downloaded. Either which way, you can see that some packages are massively bigger.

I want smaller Kernels!

And you can have them. Just looking down the modules-extra package contents, I can see hundreds of megabytes of things I don't need. Alas, there are some I do need though.

You can (fairly easily) build your own Kernels. There are build scripts (I'm currently using linux-tkg). It's 450MB on disk at the moment but I could run it though a helper like make localmodconfig to cut its built modules down to just the things currently loaded. This would cut out about 95% of the modules.

The problem with this approach is it takes CPU time, and my time to update it when there are updates. You're on your own. Most people are better off with the maintained kernel.

5
  • 1
    The other problem with the approach of building your own is that you either still have to enable drivers you might need (for example, I build my own kernels, but still enable most of the USB hardware drivers, because I can reasonably expect I may need any of them on short notice), or you have to rebuild every time something about your hardware changes (and localmodconfig, last I checked, needs a full kernel to work from). Feb 2 at 19:29
  • 2
    @AustinHemmelgarn I agree, you definitely need to plan ahead with localmodconfig. Adding back things can be laborious. Running a tool like modprobed-db on a regular basis ahead of time can be useful to track down the modules you actually use over a period of time. But yeah, even dumping the network adapters you don't use is 50MB saved. Rinse and repeat over storage controllers, graphics adaptors, and you're very quickly up to 150MB without breaking a sweat.
    – Oli
    Feb 3 at 11:16
  • @Oli Agreed, even just getting rid of the stuff you know you don’t need can indeed be a huge savings, that’s part of why I build my own kernels at all (the other part being that I want certain things that most distros don’t enable by default). Feb 3 at 12:57
  • @Oli it would be neat if a distribution wrapped modprobed-db and kernel updates from source in such a way that unnecessary modules keep being thrown out behind the scenes without need for manual user interaction. Feb 3 at 14:50
  • You can build a dpkg.cfg.d file with path-exclude/path-include entries to avoid extracting modules you don’t need — carefully done, this reduces the disk space required for kernel modules while avoiding the need to build them from source. Feb 4 at 8:11
22

Why does today's kernel update need half a gigabyte of disk space?

It's not exactly what it looks like. It is showing you that 508MB of the disk would be used, but is it telling you that this storage is permanent? What if I tell you that almost 450MB of them would be freed after running a simple command?

Generally, when a major upgrade occurs, new files and directories have to be placed. However, it won't automatically remove the older ones. Resulting in extended disk usage!

After upgrading your kernel, you can remove those old unsupported kernel modules by running:

sudo apt autoremove

It will remove all the previous kernels and their modules, which will free up almost 450MB of disk space.


Q&A

Why does today's kernel update need half a gigabyte of disk space?

It is because it has to place new files. It won't remove the older files, resulting in extended disk usage.

I've not kept notes, but I thought a kernel update was usually a couple of hundred MBs

Yes, they are, in fact, this upgrade is only 60-80MB.

is there something unusual about today's update?

Yes, this is a major kernel upgrade. You might not know that Ubuntu 20.04 will soon get upgraded to its 4th stage. So you'll get many upgrades like this. Get ready for Ubuntu 20.04.04!!


Why are kernels so big?

Linux kernel manages and controls the hardware resources like I/O (networking, storage, graphics and various user interface devices, etc.), memory and CPU for your device or computer. Each time a new upgrade comes, you get newer drivers and resources for better hardware resources.

If you are using a wireless card with custom-built drivers, then you have to recompile the drivers after the newer kernel kicks in. However, what about the other modules? The modules you do not need are still in your system. Why have iwlwifi when I use rtw99? The Linux kernel comes with thousands of different drivers for all kinds of devices. By default, apt will install ALL of them. This is one of the main reasons, why you should compile the Linux kernel yourself. To compile Linux kernel yourself without unnecessary things refer to this thread, comment #2.


Difference between Download Size and Installed Size.

Why does it show:

Need to get 95.0 MB of archives.

Even though it is saying "508 MB of additional disk space will be used"?

It is because of Compression.

The .deb also known as the "archive" format uses lossless compression algorithms to fit a huge number of files in a single .deb without increasing its size. You can run the following command to see the difference between installed size and download size.

apt show linux-generic-hwe-20.04 linux-headers-generic-hwe-20.04 linux-image-generic-hwe-20.04 linux-headers-5.13.0-28-generic linux-hwe-5.13-headers-5.13.0-28 linux-image-5.13.0-28-generic linux-modules-5.13.0-28-generic linux-modules-extra-5.13.0-28-generic | egrep "Size|Package" | grep -v APT

Here is a table showing the difference:

Package Installed-Size Download-Size
Package: linux-generic-hwe-20.04 Installed-Size: 19.5 kB Download-Size: 1,928 B
Package: linux-headers-generic-hwe-20.04 Installed-Size: 19.5 kB Download-Size: 2,516 B
Package: linux-image-generic-hwe-20.04 Installed-Size: 19.5 kB Download-Size: 2,628 B
Package: linux-headers-5.13.0-28-generic Installed-Size: 24.5 MB Download-Size: 2,569 kB
Package: linux-hwe-5.13-headers-5.13.0-28 Installed-Size: 75.9 MB Download-Size: 11.8 MB
Package: linux-image-5.13.0-28-generic Installed-Size: 10.2 MB Download-Size: 10.0 MB
Package: linux-modules-5.13.0-28-generic Installed-Size: 99.3 MB Download-Size: 18.3 MB
Package: linux-modules-extra-5.13.0-28-generic Installed-Size: 298 MB Download-Size: 51.1 MB

Should I remove older kernels?

Yes, you can remove old kernels, but it depends on how you operate your system.

  • If you have a habit of breaking your system once every week/month then its a good idea to keep multiple kernels.

  • If you use your system sincerely without doing experiments then its a good idea to remove older kernels.

How do I remove older kernels completely?

To completely purge ALL old kernels:

apt list --installed | grep linux-image | awk '{ print $2 }' | sort -V | sed -n '/'`uname -r`'/q;p' | xargs sudo apt-get -y purge

To only purge the EoSS kernels:

sudo apt autopurge

Alternatively, as raj commented, you can wait for Software Updater to popup and ask for the removal of older kernels.

2
  • My experience is that software updater in Ubuntu usually asks to remove old kernels shortly after new kernel update is installed. I usually don't have to remove anything manually.
    – raj
    Feb 3 at 12:54
  • 2
    It's hard to use a desktop computer without the GUI (how would you browse the Web?) :) and because the software updater handles updates anyway, I don't see anything abnormal in the fact that it asks me both to install new updates and to remove old unused kernels. It doesn't happen after a "long time", but usually within few hours after installing new kernel version, sometimes immediately after installing new kernel. I see this as a proper way of operation. BTW. I definitely prefer Synaptic to running apt manually :)
    – raj
    Feb 3 at 13:45
0

All of the above is absolutely true.

However part of the answer, (and why the above answers work), is based on the way Linux handles a "deleted" file - it doesn't really get deleted until everything using it has finished.

Example:
Assume an application, "Super Duper Text Editor", and also assume you have several windows open with text you are editing.

Additionally, assume an update to Super Duper Text Editor gets installed. Your existing editing sessions don't immediately get clobbered, they go away after you close them.

Like this:

  1. You have several instances of the text editor open.
  2. You update it.
    • The updater "unlinks" the directory entry to the old file, (or re-creates it), and adds a link to the new file, with the original directory entry marked as "deleted"
    • The existing links to your sessions remain until the existing sessions are closed.
  3. All the new files are added, but the existing files that are still in use aren't destroyed because they're still in use.
  4. Eventually, as you save work and close windows, the number of active links to the old files drops to zero. (remember, the directory's link was removed when the package was updated.)

When the number of links to a file drops to zero, the file is assumed to be "deleted" and that space is recovered for re-use by the filesystem and marked as available in the superblock and/or volume bitmap.

Eventually, (or especially after a reboot), all the old files have zero links and are fair game to be overwritten.

I am sure that there are details I have missed, but that's the general way it works.

8
  • 4
    I don't see how this relates to Kernel updates. It might apply to other things but Kernels are packaged with their version string in the package name; there's just a metapackage which points to a new version. When you do a Kernel update it's not just that it's memory resident, it's a whole new copy of the kernel being installed alongside the old ones.
    – Oli
    Feb 3 at 0:07
  • " it's a whole new copy of the kernel being installed alongside the old ones" . . . and as a consequence of the way Linux handles file deletions, the amount of disk space will be doubled until the next reboot. How is this not related?? Feb 3 at 6:14
  • 2
    @JimJRHarris "the amount of disk space will be doubled until the next reboot" ... that doesn't apply to how kernels are updated, though, since each kernel image is a file with a different name. So until the older kernel's package is removed, that file will stick around. Whether you reboot or not is not related.
    – muru
    Feb 3 at 9:09
  • Good point. Thanks for the clarification. Feb 3 at 10:05
  • 4
    "as a consequence of the way Linux handles file deletions, the amount of disk space will be doubled until the next reboot." - No, the disk space is released when the old kernel is removed, no reboot required. It has nothing to do with Linux' unlinking semantics, because neither the running kernel image nor loaded kernel modules keep files busy like that. You can verify this for yourself using lsof, df, and rm; deleted kernel images/modules immediately release disk space. So sadly your answer does not apply to this scenario.
    – marcelm
    Feb 3 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.