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

  • Done
  • quality assurance status badge
Details
5 participants
  • Danny Milosavljevic
  • Julien Lepiller
  • Ludovic Courtès
  • lukasbf
  • Meiyo Peng
Owner
unassigned
Submitted by
Julien Lepiller
Severity
important
Merged with
J
J
Julien Lepiller wrote on 18 Mar 2019 10:17
guix cannot find a module on boot
(address . bug-guix@gnu.org)
813466538d530a38bddf60ed348cb75b@lepiller.eu
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.
L
L
Ludovic Courtès wrote on 18 Mar 2019 21:42
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 34902@debbugs.gnu.org)
87o967lxsa.fsf@gnu.org
Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

Toggle quote (7 lines)
> 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))

Didn’t ‘guix system init’ suggest adding this module? Could it be that
this module was actually built-in in the kernel you booted?

Toggle quote (11 lines)
> 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!

Phewww.

Toggle quote (4 lines)
> 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.

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’.
J
J
Julien Lepiller wrote on 18 Mar 2019 22:34
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 34902@debbugs.gnu.org)
20190318223404.1b3c06b9@lepiller.eu
Le Mon, 18 Mar 2019 21:42:29 +0100,
Ludovic Courtès <ludo@gnu.org> a écrit :

Toggle quote (14 lines)
> Hi Julien,
>
> Julien Lepiller <julien@lepiller.eu> skribis:
>
> > 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))
>
> Didn’t ‘guix system init’ suggest adding this module? Could it be
> that this module was actually built-in in the kernel you booted?

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

Toggle quote (27 lines)
>
> > 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!
>
> Phewww.
>
> > 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.
>
> 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*’?

I guess so :)

Toggle quote (3 lines)
>
> Thanks,
> Ludo’.
D
D
Danny Milosavljevic wrote on 18 Mar 2019 23:40
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190318231359.217af9f4@scratchpost.org
Toggle quote (2 lines)
> This underscore vs. hyphen thing is terrible.

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:
* let x-path be the first value of each modules.dep line.
* Then the key for the hashtable entry is (underscore (stop-at-dot (basename x-path)))
* And the value for the hashtable entry is x-path.

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...
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlyQHlwACgkQ5xo1VCww
uqWbnwgAky0WPwHawV/qHLAND/5I8OvGn1CSwkjCsZS8wrHtOO6hOhfJiymOZqZs
CJeK+wUK9dS+nCa46ee8xeHF2XObl/jtlbkNewtCBjUPAtj/MzINlYcG3UvntKyc
Yvs4ZICC6nk0yAy3rHeeuBrenRoHDT69HTi175in+YikNwZ1mgrXk5dkgkmFPI1f
kDCYFW23r1XNywIvQUauXw4Kx2yob/ku2hNyzRXjOt6ietnUCpiuyz+mY8CKYGpF
CRcmOEFz5/OSnSUrfRUZddW5N7pl/o9mUM6Km9eId55b8RWxjXGFtlSMkMJf5s2A
LdB3E6eSKt0zWS0fyOzUS9nhCxQAdw==
=c5jZ
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 22 Mar 2019 21:27
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
87wokq4ptt.fsf@gnu.org
Hi Danny,

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

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (9 lines)
> Every time we want to lookup a module by modname, check a hashtable that
> is built from modules.dep by:
>
> * let x-path be the first value of each modules.dep line.
> * Then the key for the hashtable entry is (underscore (stop-at-dot (basename x-path)))
> * And the value for the hashtable entry is x-path.
>
> In this way we would look up modules in a way similar to them.

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’.
Attachment: file
D
D
Danny Milosavljevic wrote on 4 Apr 2019 22:42
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190404224217.5ddd00f7@scratchpost.org
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!

Toggle quote (1 lines)
>(basename file ".ko")
^^^^^^

Nice. Where was that all my life. ;-)
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlymbCkACgkQ5xo1VCww
uqWzpwf/UyysRfWE0EPtXVS/Y69qhO1aOKJp7+T32J23WOZFWPSItiPn+2b1OCdG
90yuC34rj918xgP5VbCvatBM3TSmerm48U0QlaCXGbQJIDCPMwM9KfkP831eiX+G
RUEw2UJjGq3n4y6iHFO8Eyhngqhrm6xabPetisTXBWZ8TViLBeNnlJ8eRObJgpBi
x96qRzmbc1pZ8EdDz6D4WlG345OevA6D2SN/wgvjkY/e6jKMqGy3oGJfD+aKkzUe
uB7Fj97hDYaxUNVTarbtd/0kih5A6ytYHW6qsht4vLDHJA0KyfIWYfIr9DjejPG7
AakeexaymWROYnSCDt8l+edIClLB4A==
=hW1v
-----END PGP SIGNATURE-----


M
M
Meiyo Peng wrote on 11 Jul 2019 03:46
control message for bug #36574
(address . control@debbugs.gnu.org)
87v9w9xs05.fsf@riseup.net
merge 36574 34902
quit
L
L
lukasbf wrote on 1 Aug 2019 06:51
guix cannot find a module on boot
(address . 34902@debbugs.gnu.org)
LlAW9Yf--3-1@tutanota.com
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.
Attachment: file
Attachment: IMG_20190801_013919.jpg
J
J
Julien Lepiller wrote on 1 Aug 2019 11:49
Guix cannot find a module on boot
(address . 34902@lebbugs.gnu.org)(address . ludo@gnu.org)
EA18246C-49EE-49E9-BBC8-BD2F7E995299@lepiller.eu
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!
L
L
Ludovic Courtès wrote on 16 Aug 2019 23:04
control message for bug #34902
(address . control@debbugs.gnu.org)
87ftm0g6th.fsf@gnu.org
retitle 34902 Kernel module not found at boot time due to hyphen/underscore mismatch
quit
L
L
Ludovic Courtès wrote on 16 Aug 2019 23:05
(address . control@debbugs.gnu.org)
87ef1kg6t9.fsf@gnu.org
severity 34902 important
quit
L
L
Ludovic Courtès wrote on 16 Aug 2019 23:10
Re: bug#34902: guix cannot find a module on boot
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
874l2gg6ko.fsf@gnu.org
Hello!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (14 lines)
> 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!

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

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

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’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 34902@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 34902
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch