Kernel module not found at boot time due to hyphen/underscore mismatch

Hi!

I've installed the Guix system on my cubietruck yesterday, but had some

difficulties. At first, the root partition was not available at boot, so

I got a repl with a message saying that /dev/mmcblk0p1 was not

available. I added the following to my guix config file:

(initrd-modules (cons "sunxi_mmc" %base-initrd-modules))

although the guix system command worked, the produced system still

couldn't boot, but this time the message was that guix was unable to

find sunxi_mmc.ko. Using the repl I could confirm that this module was

indeed here, but under the name sunxi-mmc.ko. Using load-linux-module*,

I was able to confirm that loading it made the filesystem available in

/dev. In the end this line:

(initrd-modules (cons "sunxi-mmc" %base-initrd-modules))

was the right line to add, and I could properly boot my cubietruck!

The bug here is that guix should either be smarter and load sunxi-mmc.ko

when it can't find sunxi_mmc.ko, or not allow me to build a system when

I specify sunxi_mmc since it doesn't exist at boot time.

Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

Didn’t ‘guix system init’ suggest adding this module? Could it be that

this module was actually built-in in the kernel you booted?

Phewww.

This underscore vs. hyphen thing is terrible.

In commit fcd068e984078ab74c6842af2525bf88096cd262 we fixed the initrd

builder so it would try both file underscore and hyphen.

But now I suppose we need to do the same in ‘load-linux-module*’?

Thanks,

Ludo’.

Le Mon, 18 Mar 2019 21:42:29 +0100,

Ludovic Courtès <ludo@gnu.org> a écrit :

I couldn't find it in the output of lsmod, so I think it was builtin.

I guess so :)

Yeah. But looking at kmod, it doesn't seem to be so bad for them.

They basically always use the version with underscores as the lookup

key for their internal hash tables.

For alias resolving, they use a resolver for [a-zxxx] AND they replace

dashes THAT ARE NOT IN THE "[...]" block by underscore before using it

for lookups.

modules.dep entries are always file names (no replacements whatsoever).

When a module is loaded as a result of an alias lookup, it has a special

key (string-append name "\" target-alias). No idea what that's for.

I'd caution about complicating our version overly much by putting

just-in-case replacements everywhere. Rather we should find out what

their original strategy is (if any :P) and do that as well.

Module aliases (the alias itself, not what it's resolved to) sometimes look

like that:

./arch/x86/crypto/des3_ede_glue.c:MODULE_ALIAS_CRYPTO("des3_ede-asm");

WTF...

But the thing the alias is resolved to is always the modname (which

has hyphens replaced by underscore and stops before a dot).

Their bin files (we don't use them) always have the final modname as key,

as opposed to their source files (for example "modules.alias" rather

than "modules.alias.bin"). (The source files sometimes have paths as key)

I think that they assume that each module, whether it has dependencies or

not, is listed in modules.dep . They use modules.dep.bin for the lookup

of a module by modname, rather than by path.

So I think a pretty good fix is:

Every time we want to lookup a module by modname, check a hashtable that

is built from modules.dep by:

In this way we would look up modules in a way similar to them.

Why they couldn't just have used file names without mangling them beats me.

Sigh...

Hi Danny,

Thanks for the explanation, I was unaware of all these subtleties…

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Instead of guessing, we could also store a mapping from module name to

file name. I had that in a previous patch series that we discussed some

time ago (see below.)

This a custom format, not used by kmod or any other tool, but the

advantage is that it solves the module/file name mapping without ugly

guess-hacks.

WDYT?

Thanks,

Ludo’.

Maybe I'm too paranoid but can we have "guix" in the file name "modules.name"

somewhere? Otherwise I see it coming that upstream uses modules.name for an

incompatible purpose and then we'd be with a guix interface that's broken

and/or break their interface.

(So much complexity for something so silly. Honestly, I feel like E-mailing

the upstream author and telling him what I think. WTF :P)

Should we warn when we use the fallback? I like the defensive programming

but I feel we shouldn't have it *silently* fall back when the database is

broken/missing.

Otherwise LGTM!

^^^^^^

Nice. Where was that all my life. ;-)

merge 36574 34902

quit

I have the same issue with sdhci_acpi > sdhci-acpi (See attached image) on my Laptop.

Please fix this somehow, I'm a noob and don't know how to fix that outside of the installer.

Hi Ludo,

Your patch has a LGTM, but I don't see it on master. Would you like to push it, or is there a reason why you didn't do it yet?

Thanks!

retitle 34902 Kernel module not found at boot time due to hyphen/underscore mismatch

quit

severity 34902 important

quit

Hello!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

So I went ahead and pushed these patches, derived from our beautiful

patch set at https://issues.guix.gnu.org/issue/30604:

c85ccf60bf linux-modules: Define and use a module name database.

e1a9a7f275 linux-modules: Add 'load-linux-modules-from-directory'.

2a693b69ca linux-modules: Add "modules.devname" writer.

4f8b9d1a6f linux-modules: Add "modules.alias" writer.

The actual fix for the hyphen/underscore mismatch that Julien reported

is commit c85ccf60bf. The “modules.devname” and “modules.alias” are

actually unused so far but (1) it was easier to preserve them, and (2)

that’ll give us an incentive to finish

https://issues.guix.gnu.org/issue/30604. :-)

I added an explicit comment that “modules.name” uses a Guix-specific

format. We can always rename it if the kernel folks decide to acquire

that file name.

Julien, could you please confirm that your initial issue is fixed?

Thanks,

Ludo’.