Re: nfslockd kernel module fails to load

From: Alexander Leidinger <Alexander_at_leidinger.net>
Date: Thu, 23 Apr 2020 09:46:02 +0200
Quoting Konstantin Belousov <kostikbel_at_gmail.com> (from Thu, 23 Apr  
2020 10:04:12 +0300):

> On Thu, Apr 23, 2020 at 08:30:08AM +0200, Alexander Leidinger wrote:
>> Quoting Konstantin Belousov <kostikbel_at_gmail.com> (from Thu, 23 Apr 2020
>> 09:19:08 +0300):
>>
>> > On Thu, Apr 23, 2020 at 08:08:09AM +0200, Alexander Leidinger wrote:
>> > > Hi,
>> > >
>> > > link_elf_obj: symbol xdr_free undefined
>> > > linker_load_file: /boot/kernel/nfslockd.ko - unsupported file type
>> > > KLD nfsd.ko: depends on nfslockd - not available or version mismatch
>> > > linker_load_file: /boot/kernel/nfsd.ko - unsupported file type
>> > >
>> > > The xdr kernel module is loaded.
>> >
>> > The following should help.
>>
>> >  /* So that loader and kldload(2) can find us, wherever we are.. */
>> > +MODULE_DEPEND(nfslockd, xdr, 1, 1, 1);
>> >  MODULE_DEPEND(nfslockd, krpc, 1, 1, 1);
>>
>> I thought MODULE_DEPEND is only a way to tell the loader / kldload that the
>> other module is to be loaded in case it is not in the kernel / loaded
>> already. Is this only a part of what it does and / or did this change and
>> now it is also needed so that a kernel module is able to resolve the
>> symbols? In my case the module is loaded already when I try to load the
>> nfslockd module.
>
> Did you tried the patch ?

I was trying it after asking the question. I confirm it works.

> You already said that the module was loaded.
>
> MODULE_DEPEND() handles symbol namespaces.

Since when is this the case (rough figure would be enough if someone  
knows it without looking it up)?

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander_at_Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild_at_FreeBSD.org  : PGP 0x8F31830F9F2772BF

Received on Thu Apr 23 2020 - 05:46:13 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC