On Mon, Sep 17, 2012 at 2:16 PM, Lucas De Marchi <lucas.demarchi@xxxxxxxxxxxxxx> wrote: > Hi Thierry, > > On Mon, Sep 17, 2012 at 2:02 PM, Thierry Vignaud > <thierry.vignaud@xxxxxxxxx> wrote: >> On 17 September 2012 18:45, Thierry Vignaud <thierry.vignaud@xxxxxxxxx> wrote: >>>>>> We (Mageia Linux) uses kmod in our hardware tools in order to guess >>>>>> the modules that manage the hardware present. >>>>>> >>>>>> However in some cases, kmod code doesn't work well. >>>>>> See: https://bugs.mageia.org/show_bug.cgi?id=5833 >>>>>> >>>>>> It appears that it doesn't use modules.order (but when writing it, in >>>>>> depmod). >>>>> >>>>> kmod is correct to only ever reference the modules.order file when >>>>> calling depmod. Aliases are sorted once according to the list, and then >>>>> modprobe should then just Do The Right Thing™ when resolving the alias >>>>> from the generated index. The bug here is that the sorting fails in >>>>> depmod when modules are compressed. >>>> >>>> Humm. >>>> We could try something like this (untested) in order >>>> to successfully compare "foobar.ko" & "foobar.ko.xz" >>> >>> Humm, reading more, those hashes are also used for symbols, and >>> in that case it's wrong. >>> I guess we would need a dedicated comparator for module names >> >> For now, I'll just fix modules.order in our installer (as we already run depmod >> anyway) > > Thanks for reporting this. I'll take a look at it tonight or tomorrow. > > Fixing this in hash implementation or hash comparison function is the > wrong thing to do. As you noticed, the hash is used for other things > too. > > cheers > Lucas De Marchi I've just made a quick fix. Could you please send me your modules.order, modules.alias, modules.dep together with the affected modules (only the names are ok). Bonus points for you if you use this information to actually create a test in the testsuite :-) See the (untested) patch attached. Lucas De Marchi
Attachment:
fix-depmod-with-compressed-modules.diff
Description: Binary data
