Kernel modules compression

Feature requests
1

Now the modules take over 150MB , I think if compressed with zstd ,it would save lots of space . most linux distributions using this feature.

2

Perhaps this one should be reopened then?

3

You might save 75mb? Even if it was 100mb, what’s the use case for needing such small savings? I believe the image is compressed using squashfs isn’t it? (I might be wrong)

4

Every save is nice which will aggregate up to bandwidth costs for VyOS Networks Corporation themselves.

Will also give room to add more tools such as btop which is currently missing.

5

okay ,I didn’t notice the image is already compressed using squashfs .

6

Yeah, main magic occurs when the squashfs (used as underlay for the persistent storage who uses unionfs or if its overlayfs) is created:

squashfs_compression_type = "xz -Xbcj x86 -b 256k -always-use-fragments -no-recovery"

There are a few other cleanups being runned aswell:

Above excludes-file is automatically called by debian-live scripts/build/binary_rootfs and scripts/build/binary_chroot.

And then there is this feature request that hopefully can be re-opened in future (kernel stuff is redundant between the bootable ISO itself and content of squashfs which is (or was) another 35MB or so to shrink the image by):

7

Please not that you cannot strip the modules. This will remove the modules signature and will thus be unable to be loaded by the Kernel as module signature is enforced.

Module compression was worked on during the secure boot implementation, but it got in the way with module signing. Now that all the smoke settled, it should be trivial to implement. I have re-opened ⚓ T5641 Enable compression of kernel modules and first builds show a size reduction in 60MB which is almost 10% of the overall image size.

2 Likes
8

Thats why 92-strip-symbols.chroot have a whitelist of which directories are safe to perform which strip in.

9

Does this impact the final result? Best I can figure out, the image is compressed using xz which is going to give excellent compression anyway?

10

Needs to be tested.

Also how RAM usage affects this.

I assume that squashfs isnt fully loaded into RAM during boot so it will just be a matter of regular pagecache kicking in. And in that case would it be of any favour of not having the modules compressed within the squashfs (since it then needs to be unpacked somewhere anyway except for the decompression of squashfs itself)?

That is if the module isnt compressed on its own then its just compressed through squashfs which will expand the content upon access into RAM. While if its compressed then it must also be decompressed on its own by the kernel before it can use it?

There is also this thing of kernel files themselves exists both in the squashfs aswell as the ISO itself. So from that point of view compressing the modules anyway should be a good thing because whats placed on the ISO itself isnt compressed by default. That is it can be a good thing anyway to compress the kernel modules if possible because that could shrink the ISO size anyway.

Im thinking of this case (which isnt about compression but to get rid of redundant files who exists both in the ISO and the squashfs itself):