Is is possible to compress System.map files

Because my /boot is full, I’ve noticed today System.map file for a given kernel is almost as large as the kernel itself, take a dozen of MiBytes:

18991464    vmlinuz-7.2.0-0.rc5.260729gfc02acf6ac0c.43.fc45.x86_64
12673553 System.map-7.2.0-0.rc5.260729gfc02acf6ac0c.43.fc45.x86_64

18999656    vmlinuz-7.2.0-0.rc5.260731g8ba098e6b6ff.45.fc45.x86_64
12674426 System.map-7.2.0-0.rc5.260731g8ba098e6b6ff.45.fc45.x86_64

19007848    vmlinuz-7.2.0-0.rc6.260807gf9a2394a2348.52.fc45.x86_64
12681055 System.map-7.2.0-0.rc6.260807gf9a2394a2348.52.fc45.x86_64

I was wondering it the file could be compressed … provided the tools depending on System.map could read a compressed file.

I see upstream kmod’s depmod doesn’t have support for reading compressed file.

Which other tools would need to deal with a compressed System.map file ?

Note that the kernel and the system.map are both relatively small. Each is less than 20MB, making those all 6 files only about 80MB total

If you run df -h it should show the size of the partition, as well as the used amount.
ls -l /boot will show the size of all files in /boot and on my system I see that the initramfs images are much larger, with the rescue image at about 180MB and the image for each kernel may be near the same size (often about 150MB)

Please show us the output of both those commands.
df -h & ls -l /boot as preformatted text.

The question is also: Are the System.map files actually required in /boot when they are just copies of the System.map file from /usr/lib/modules/*/System.map?

They aren’t much use there if the system uses luks

And not much use in /boot either because /boot can’t be mounted until the root file system is unlocked and mounted. Everything needed to unlock the luks file system must be available in the initrd image.

No System.map files are not needed for the boot loader to load the kernel, nor for the kernel to initialize. So strictly speaking, System.map is not required to boot, see Is it possible to deduplicate kernel's config and System.map between /boot and /lib/modules? - #3 by ydroneaud

But the file is expected in /boot by some tools, probably because, historically, Linux make install copies the file in /boot (I have to dig into git history).

From developer perspective, I believe System.map is mostly intended for debugging.

From user perspective, System.map could be optionally provided to depmod when generating modules.dep (used by modprobe to load modules and their dependencies), and depmod expects the file in /boot (and not in compressed form).

So, if the file is not needed for users, may be it can be compressed, and developer tools that use it could be adapted to read a compressed file, or developers be advised to decompress it before usage.

@grumpey changed the category to Ask Fedora/Boot … but I’m not exactly asking people how Fedora boots, and definitely not looking for a solution.

I’ve posted in Project discussion/Engineering to ask if this is a change that could be considered for kernel packaging.

And I’m asking how System.map is used in Fedora, to identify other issue that would arise if the file was packaged and installed in compressed form.

Also, depmod doesn’t read System.map unless giving the pathame of System.map via the “-F” option. That can be confirmed using strace.

I only find /usr/bin/readprofile as the only one on my system specifically referring to /boot/System.map-*.

Also, some people have replaced grub2 by sd-boot, and those systems don’t have any /boot/System.map and seems not to miss it at all.

/boot full:

why not just delete the *rc5 kernel ???

I don’t believe the OP was particularly interested in cleaning space up from /boot.

It was more of a “these files which aren’t really required are just as large as each kernel, and they compress down to a fraction of their original size… why don’t we compress them.”

Clearing space is not the end goal, it was merely the catalyst.