#1085208 linux-*: Provide information about /boot space usage

#1085208#5
Date:
2024-10-16 05:49:05 UTC
From:
To:
Hi,

I think I just spotted a new feature of apt (thanks for the continuous
improvements): reporting and protection of /boot. However, I think it
was far off and hence prevented me from upgrading without looking into it.

Story is that some time ago, my /boot was too small (it came with
Debian's default) for upgrades of the kernel, and I was advised on IRC
to configure something regarding modules (IIRC something like:
as-needed) which drastically reduced the used size in /boot to the
extend I haven't had to worry about it anymore. Today it was different.

Starting point:

paul@mulciber ~ $ sudo apt full-upgrade --update
...
Installing dependencies:
   linux-doc-6.11  linux-image-6.11.2-amd64

Suggested packages:
   debian-kernel-handbook

Summary:
   Upgrading: 40, Installing: 2, Removing: 0, Not Upgrading: 0
   Download size: 152 MB
   Space needed: 308 MB / 9,351 MB available
   └─ in /boot:  141 MB / 137 MB available

Warning: More space needed in /boot than available: 141 MB > 137 MB,
installation may fail
Continue anyway? [y/N]
Abort.

paul@mulciber ~ $ df -h /boot/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       235M   92M  131M  42% /boot

paul@mulciber ~ $ ls -al /boot/
total 80374
drwxr-xr-x  5 root root     1024 okt 15 22:04 .
drwxr-xr-x 18 root root     4096 sep 29 07:03 ..
-rw-r--r--  1 root root   276610 sep 22 16:24 config-6.10.11-amd64
-rw-r--r--  1 root root   276609 sep  8 20:29 config-6.10.9-amd64
drwx------  5 root root     4096 jan  1  1970 efi
drwxr-xr-x  5 root root     1024 sep 29 21:37 grub
-rw-r--r--  1 root root 31007922 okt 15 22:04 initrd.img-6.10.11-amd64
-rw-r--r--  1 root root 30959713 sep 27 08:00 initrd.img-6.10.9-amd64
drwx------  2 root root    12288 jun  4  2020 lost+found
-rw-r--r--  1 root root       83 sep 22 16:24 System.map-6.10.11-amd64
-rw-r--r--  1 root root       83 sep  8 20:29 System.map-6.10.9-amd64
-rw-r--r--  1 root root  9697216 sep 22 16:24 vmlinuz-6.10.11-amd64
-rw-r--r--  1 root root  9725888 sep  8 20:29 vmlinuz-6.10.9-amd64

I thought, maybe something (a bug?) is going to make these files a lot
bigger, so let's remove 6.10.9. After doing that and then upgrading, my
/boot looked like below, and in the process I didn't see it blowing up
temporarily:

paul@mulciber ~ $ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       235M   92M  131M  42% /boot

paul@mulciber ~ $ ls -al /boot
total 80646
drwxr-xr-x  5 root root     1024 okt 16 07:33 .
drwxr-xr-x 18 root root     4096 okt 16 07:33 ..
-rw-r--r--  1 root root   276610 sep 22 16:24 config-6.10.11-amd64
-rw-r--r--  1 root root   278832 okt  6 01:00 config-6.11.2-amd64
drwx------  5 root root     4096 jan  1  1970 efi
drwxr-xr-x  5 root root     1024 okt 16 07:34 grub
-rw-r--r--  1 root root 31007922 okt 15 22:04 initrd.img-6.10.11-amd64
-rw-r--r--  1 root root 31097605 okt 16 07:33 initrd.img-6.11.2-amd64
drwx------  2 root root    12288 jun  4  2020 lost+found
-rw-r--r--  1 root root       83 sep 22 16:24 System.map-6.10.11-amd64
-rw-r--r--  1 root root       83 okt  6 01:00 System.map-6.11.2-amd64
-rw-r--r--  1 root root  9697216 sep 22 16:24 vmlinuz-6.10.11-amd64
-rw-r--r--  1 root root  9865152 okt  6 01:00 vmlinuz-6.11.2-amd64

#1085208#10
Date:
2024-10-16 11:18:48 UTC
From:
To:
Control: clone -1 -2
Control: reassign -2 src:linux
Control: retitle -2 linux-*: Provide information about /boot space usage
Control: seveirty -2 wishlist

size of (linux-image-6.11.2-amd64) + ( largest initrd + largest map ) * 1.1

It seems Debian kernels include modules in their image package, causing
the modules to be counted. An Ubuntu kernel image (which I tested this
against) meanwhile is true to the name and only contains the kernel image
(the modules are in linux-modules-$(uname -r)).

What are our ways out here?

* Split modules out of linux-image into linux-modules
* Add a new Boot-Size: field indicating the size of files in /boot
* Change the estimate to use the largest kernel size. This is much more
  unreliable.

We also need to have a look at packages triggering initrd generation:
Technically you need space for one additional initrd in /boot as the
new file is being written before the old one is deleted. :(