Workaround Debian's broken System.map behavior

[rincebrain]

Motivation and Context

Currently, if you make install on a Debian system without the linux-image-$FOO-dbg package, it will notice the System.map file, try to helpfully run depmod against it, and flood the screen with missing symbols for a long time.

Because Debian helpfully ships a stub file saying "go install this package instead if you really want the file" in the normal kernel packages.

I finally got annoyed enough about this happening on one slow testbed where this actually slows things down, and fixed it.

Description

If (sizeof(System.map) < 1kb) 
    { don't }

How Has This Been Tested?

It built and make installed locally without errors. CI hasn't screamed since I pushed the not-stale version.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[nabijaczleweli]

The dbgsyms for the current the bullseye kernel (linux-image-5.10.0-9-amd64-dbg) are an 800MB download and apparent-5700MB install (1.7G with compress=zstd). The filelist is here and accurate.

A better heuristic is to just have

sysmap=$(INSTALL_MOD_PATH)/boot/System.map-@LINUX_VERSION@; \
[ $$(wc -l < $$sysmap) -eq 1 ] && sysmap=$(INSTALL_MOD_PATH)/usr/lib/debug/boot/System.map-@LINUX_VERSION@; \

and leave the rest as-is (+ whatever comment best describes your feelings towards Debian's packaging decisions, I guess), the main [ -f condition will take care of this.

[rincebrain]

The dbgsyms for the current the bullseye kernel (linux-image-5.10.0-9-amd64-dbg) are an 800MB download and apparent-5700MB install (1.7G with compress=zstd). The filelist is here and accurate.

Sure, and on my systems with 1TB+, shrug. But some of my systems have 32 GB or less, and occupying a significant fraction of it just for System.map is not a worthwhile tradeoff. (And unfortunately, they don't currently use compressed debug symbol files on their own...)

(Most of my testbed VMs and hardware also don't run ZFS for the OS filesystem(s), simply because if they're for testing ZFS things, it's much more convenient to not risk the OS disk in the experiment.)

I opted for a 1k check instead of just a single line check or a string grep because I didn't want to play whack-a-mole if it changed the text inside to be subtly different, or across multiple lines, or [...]; I agree that the redirect to check /usr/lib/debug/[etc] is a more reasonable action to take on discovering that's the case, though.

How do you feel about the version I just pushed?

(The reason I described it as "broken" is that the number of people who would {need System.map, find the stub System.map, actually read the contents, not find out where to get the proper System.map by searching before getting to this point in the story} seems quite small. But perhaps that's just ubiquitous internet access privilege talking.)

[nabijaczleweli]

I wouldn't be worried about fragility of that check; I doubt it'll change any-time soon because this is new in bullseye (5.8.3-1~exp1), and seems to function fine, relieving the /boot pressure of the >3MB (buster) symtabs.

The updated version looks okay, except that the comment still mentions it being <1k, despite checking for a single line; how's about this:

Since bullseye, Debian ships fake one-line System.maps whose only symbol points to the kernel -dbg package. Naturally, depmod is less than amused by this.

I wouldn't say it's broken, as much as it's just fake – note how it retains the System.map structure, so tools that process it will most likely include that in their output. I don't think I've ever needed it, but if I did I can suck down the -dbg (9-second download at home for the whole thing isn't bad, but I take it you've never been on shitty dial-up in the mountains; win-win: smaller generic kernel download, but if you need it you probably also need the rest of -dbg (and if not, you probably know how to do a dpkg filter)).

[rincebrain]

I wouldn't be worried about fragility of that check; I doubt it'll change any-time soon because this is new in bullseye (5.8.3-1~exp1), and seems to function fine, relieving the /boot pressure of the >3MB (buster) symtabs.

The updated version looks okay, except that the comment still mentions it being <1k, despite checking for a single line; how's about this:

The comment mentions it because the actual check still does that.

I appreciate the need for tiny /boot (after all, my sparc is stuck with a 96MB boot because every partition tool ever is terrified to touch its disk, and reinstalling it would be extremely troublesome if it went awry), but I would have preferred if System.map still ended up somewhere accessible, possibly symlinked away, though not everybody's /boot gets symlinks.

I'm curious why you find checking for a single line much more palatable than a definitely-too-small character count? I don't have any deep philosophical attachment to either, just that checking for a single line seems slightly more like someone might accidentally break things checking for it.

(I'll happily give up after this round of questioning and just go for a line check if that's what you prefer, I'm just trying to understand why you prefer it.)

Since bullseye, Debian ships fake one-line System.maps whose only symbol points to the kernel -dbg package. Naturally, depmod is less than amused by this.

I wouldn't say it's broken, as much as it's just fake – note how it retains the System.map structure, so tools that process it will most likely include that in their output. I don't think I've ever needed it, but if I did I can suck down the -dbg (9-second download at home for the whole thing isn't bad, but I take it you've never been on shitty dial-up in the mountains; win-win: smaller generic kernel download, but if you need it you probably also need the rest of -dbg (and if not, you probably know how to do a dpkg filter)).

I was, actually, on dial-up for many years, though that was all before 802.11b was ratified.

I suppose my frustration is that, if their goal was to inform people looking for System.map in /boot, they could have named it anything but actually System.map - and I'm also not sure making it a valid, if empty, System.map file is a win, because tools will process it as valid and fountain errors when nothing is found, rather than obviously rejecting it as malformed.

Differing philosophies, I suppose.

[nabijaczleweli]

Oh, I actually didn't read it right and overfit it to my thing, soz. It's also hilarious to see that 802.11b got ratified in 1999, which is a solid year before I was born. I guess my point was more toward "in recent years", because the distribution model (and volume) changed accordingly with wide-spread internet access and I didn't consider the pre-broadband era. Because I was never usefully in it.

And primarily because it's a line-based format – it's not incredulous that it's <1k (that's out-of-domain), but it is incredulous that a kernel would have like a hundred symbols (and the way to check for <1k is with an, uh, unorthodox find-into-test-z spelling (I mean, I can't think of a better one, but it still sucks)).
If you'd rather do something more versatile that expresses "too short", then I'd go with something like [ $$(wc -l < $$symtab) -lt 100 ] && ... (or -gt ||) which is simpler overall.

I mean, I was actually surprised the -dbg package doesn't do a diversion, but then you don't actually need it to be in /boot, so meh. As for it still being there and being System.map, I can't say I disagree, but I think all other solutions are worse from a compat/discoverability perspective. But then it's not up to me, thankfully.

[behlendorf]

Either method of detecting the stub seems reasonable to me.