do you manage to load it manually with modprobe/insmode ?

I am asking because right now, the "fuse" module in debian testing gives me "missing symbols" errors, so it's worth double-checking the basics...

I don't have a 4.18 kernel to test this (yet), I'm merely forwarding the downstream bug report.

systemd loads kmods by name during the early module loading, and doesn't process aliases. I am not convinced it's really a good idea to do the full alias magic this early. I mean, the alias stuff maps names to sets of kmods iirc, it's substantially more than just a way to rename modules... urks.

Those kernel hackers with their "don't break userspace" mantra should maybe not break stuff like this so willynilly...

/cc @raven-au

Hmm, so the alias is added in this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/autofs?id=a2225d931f75ddd3c39f4d0d195fad99dfd68671

The commit msg claims the alias is fine, but actually it isn't for cases like this one... If the kernel folks care that old userspace shall function correctly on new kernels they need to revert this one and a few others that are related, or find a different way out if they want to rename the kmod. /cc @torvalds

I mean, we can certainly look into working around this kernel change in userspace, and either process aliases or load autofs too, but this is not going to fix old systemd versions on new kernels...

Renaming kernel modules is problematic in general. There's lots of code in this world which checks for kernel features by accessing /sys/module/$SOMETHING. If those paths change because the kernel folks decided to rename a module then things will break. systemd for example currently uses a bunch of paths below /sys/module/:

/sys/module/vt/parameters/default_utf8
/sys/module/ipv6
/sys/module/printk/parameters/time
/sys/module/apparmor/parameters/enabled

Hence, besides the module loading itself, changing kmod names of generic kernel functionality will break stuff, all over the place.

Quoting Andreas Henriksson from IRC:
"
<ah[m]> Re #902946 it's likely when the following fails the fallback should be to also try kmod_module_new_from_alias (if I read the relevant code correctly on my mobile phone)...
[zwiebelbot] Debian#902946: Fails to load autofs module through autofs4 alias - https://bugs.debian.org/902946

<ah[m]> https://sources.debian.org/src/systemd/239-3/src/core/kmod-setup.c/?hl=125#L125

<ah[m]> IMHO would have been nice if kmod did that internally but it's documented not to so likely won't change: https://sources.debian.org/src/kmod/25-1/libkmod/libkmod-module.c/?hl=314#L314

<ah[m]> Or simply replace kmod_module_new_from_name with kmod_module_new_from_lookup which should dtrt and is used elsewhere in systemd source.
"

@mbiebl yeah sure, as I already said we can look into adding some fallbacks for this, but that's not going to fix old userspace on new kernels... anyway you look at it the userspace facing API of the kernel did change here...

@raven-au well, fact is kernels starting with 4.18 have problems with any released version of systemd since systemd will try to load "autofs4" and the kmod with that name ceased to exist. The MODULES_ALIAS is not honoured by systemd, as we don't follow aliases at all.

So, the rename is basically breaking all current userspace. And in my view that's a problem. And as I understand Linus' "don't break userspace" mantra this should also be considered a problem for the kernel folks.

Oh, wow. Linus being awful. Unlike on lkml we'd block him here for being like that. And just to make this clear: we are loading the kmod with libkmod, which isn't something the systemd folks invented but the official implementation of the kmod loader. Linus' remarks are hence entirely besides the point.

The kmod alias stuff is usually used to match kmods to pci or usb vid/pid and similar things, not as a hack to rename specific modules. We just wanted to load four specific general purpose kmods which some distros build as module and hence we reference them by name, in particular has the alias stuff allows non-unique mappings which is not of interest for this.

Anyway, if this is the level of conversation the kernel folks want then don't expect any further comment here from me on this topic. I am out on this one.