modprobe on guix

modprobe on guix

[白い熊＠相撲道]

How do I load a kernel module in Guix?

I can insmod the concrete .ko file from the /gnu/store/... kernel 
directory, however this is impractical for scripts etc, since the 
directory will change with system reconfigure.

However 'sudo modprobe ...' doesn't load the kernel module...
-- 
白い熊＠相撲道

Re: modprobe on guix

[Mark H Weaver]

白い熊＠相撲道 <guix-devel_gnu.org@sumou.com> writes:
> How do I load a kernel module in Guix?

It should just work, assuming that LINUX_MODULE_DIRECTORY is set to
/run/booted-system/kernel/lib/modules and that you are using 'modprobe'
from Guix.  We set LINUX_MODULE_DIRECTORY in /etc/profile on GuixSD.

> I can insmod the concrete .ko file from the /gnu/store/... kernel
> directory, however this is impractical for scripts etc, since the
> directory will change with system reconfigure.

For insmod, use /run/booted-system/kernel/lib/modules.

> However 'sudo modprobe ...' doesn't load the kernel module...

It works for me.  Can you try the following command:

  sudo bash -c "echo $LINUX_MODULE_DIRECTORY"

and verify that it prints "/run/booted-system/kernel/lib/modules"?

      Mark

Re: modprobe on guix

[Alex Kost]

Mark H Weaver (2015-03-25 15:57 +0300) wrote:

> 白い熊＠相撲道 <guix-devel_gnu.org@sumou.com> writes:
>> How do I load a kernel module in Guix?
>
> It should just work, assuming that LINUX_MODULE_DIRECTORY is set to
> /run/booted-system/kernel/lib/modules and that you are using 'modprobe'
> from Guix.  We set LINUX_MODULE_DIRECTORY in /etc/profile on GuixSD.
>
>> I can insmod the concrete .ko file from the /gnu/store/... kernel
>> directory, however this is impractical for scripts etc, since the
>> directory will change with system reconfigure.
>
> For insmod, use /run/booted-system/kernel/lib/modules.
>
>> However 'sudo modprobe ...' doesn't load the kernel module...
>
> It works for me.  Can you try the following command:
>
>   sudo bash -c "echo $LINUX_MODULE_DIRECTORY"
>
> and verify that it prints "/run/booted-system/kernel/lib/modules"?

I'm on GuixSD (and LINUX_MODULE_DIRECTORY is set properly) but:

  $ sudo modprobe ...

doesn't load a module for me, however when I try it under root:

  # modprobe ...

it works.  No idea why that happens.

-- 
Alex

Re: modprobe on guix

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> I'm on GuixSD (and LINUX_MODULE_DIRECTORY is set properly) but:
>
>   $ sudo modprobe ...
>
> doesn't load a module for me, however when I try it under root:
>
>   # modprobe ...
>
> it works.  No idea why that happens.

Could it be that ‘sudo’ creates an environment that lacks
LINUX_MODULE_DIRECTORY?  That may well be the case.

Ludo’.

Re: modprobe on guix

[Alex Kost]

Ludovic Courtès (2015-03-26 00:01 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> I'm on GuixSD (and LINUX_MODULE_DIRECTORY is set properly) but:
>>
>>   $ sudo modprobe ...
>>
>> doesn't load a module for me, however when I try it under root:
>>
>>   # modprobe ...
>>
>> it works.  No idea why that happens.
>
> Could it be that ‘sudo’ creates an environment that lacks
> LINUX_MODULE_DIRECTORY?  That may well be the case.

Ah indeed, "sudo -E modprobe …" works.

-- 
Alex

Re: modprobe on guix

[Petter]

I've investigated a bit and have some light to shed on this issue.

First, I've tested printing the value of LINUX_MODULE_DIRECTORY as
suggested previously in this thread, and found it not to be a good test.

$ sudo bash -c "echo $LINUX_MODULE_DIRECTORY"
> /run/booted-system/kernel/lib/modules,
which shows indeed the expected output, but for the wrong reason.

This would be the shell doing the variable expansion while still in the
user's environment. Which makes it in effect similar to:
$ sudo bash -c "echo /run/booted-system/kernel/lib/modules"

Overwriting the variable in the user environment demonstrates this.
$ LINUX_MODULE_DIRECTORY=hello
$ sudo bash -c "echo $LINUX_MODULE_DIRECTORY"
> hello

Testing single quotes instead, which should leave the variable
unexpanded by the first shell.
$ sudo bash -c "echo $USER"
> petter
$ sudo bash -c 'echo $USER'
> root

And so this would be a better test.
$ sudo bash -c 'echo $LINUX_MODULE_DIRECTORY'
>
(empty value.)

As best i can find out  sudo  doesn't source any of the relevant shell
files, like /etc/profile; and so the root environment isn't set up like
if you logged in as root. And variables from the user environment isn't
passed on to it either. Besides using  sudo -E  , which passes on all
the user's environment variables (not recommended), the easiest fix
seems to be to use  sudo -i  . With  -i, --login  shell files will be
sourced, and we get an environment equal to being root user as far as i
can tell.

$ sudo -i bash -c 'echo $LINUX_MODULE_DIRECTORY'
> /run/booted-system/kernel/lib/modules

I don't know what the proper way of handling this is. But i'm using an
alias at the moment  alias sudo='sudo -i'  . With this  sudo modprobe
works fine.

(I've looked at whitelisting environment variables in /etc/sudoers, but
i believe this is for passing on user defined variables, not system
variables.)

Petter
(karhunguixi)

Re: modprobe on guix

[Ludovic Courtès]

Petter <petter@mykolab.ch> skribis:

> (I've looked at whitelisting environment variables in /etc/sudoers, but
> i believe this is for passing on user defined variables, not system
> variables.)

One solution would be to provide a /etc/environment file containing the
right value for LINUX_MODULE_DIRECTORY (‘sudo’ honors that, according to
sudoers(5).)

WDYT?

Ludo’.

Re: modprobe on guix

[Petter]

> One solution would be to provide a /etc/environment file containing the
> right value for LINUX_MODULE_DIRECTORY (‘sudo’ honors that, according to
> sudoers(5).)

Yes, this is interesting. When i considered this previously i
prematurely put it aside because it requires PAM, and i wrongly
concluded our sudo wasn't configured with PAM (based on package
definition). On second look, i see PAM is on by default for Linux
distributions when building sudo; also running  sudo -V  as root user
confirms this. However, creating /etc/environment and putting stuff
there doesn't have any effect for me. But i believe the reason is that a
module needs to be added to linux-pam, namely pam_env[1].

I'd like to have a go at this and see if i can make a patch for this.

Maybe it makes sense to put /all/ the environment variables, especially
for root operations, in /etc/environment? From what i understand
variables from outside this file will not be expanded, so if not it
would mean duplicating definitions. Also, having this as a
just-for-those-sudo-users would be easy for root users to miss
updating. Then obviously root logins would have to make use of this file
as well, but i'm sure that can be arranged. I'll look more into this.

[1] http://www.linux-pam.org/Linux-PAM-html/sag-pam_env.html

Petter

Re: modprobe on guix

[Ludovic Courtès]

Petter <petter@mykolab.ch> skribis:

>> One solution would be to provide a /etc/environment file containing the
>> right value for LINUX_MODULE_DIRECTORY (‘sudo’ honors that, according to
>> sudoers(5).)
>
> Yes, this is interesting. When i considered this previously i
> prematurely put it aside because it requires PAM, and i wrongly
> concluded our sudo wasn't configured with PAM (based on package
> definition). On second look, i see PAM is on by default for Linux
> distributions when building sudo; also running  sudo -V  as root user
> confirms this. However, creating /etc/environment and putting stuff
> there doesn't have any effect for me. But i believe the reason is that a
> module needs to be added to linux-pam, namely pam_env[1].

Oh, I see.  Presumably, you need to add ‘pam_env’ to the list of modules
for ‘sudo’, which is currently hardcoded in ‘base-pam-services’ in the
misnamed (gnu system linux) module.

> I'd like to have a go at this and see if i can make a patch for this.

That’d be great!

> Maybe it makes sense to put /all/ the environment variables, especially
> for root operations, in /etc/environment? From what i understand
> variables from outside this file will not be expanded, so if not it
> would mean duplicating definitions. Also, having this as a
> just-for-those-sudo-users would be easy for root users to miss
> updating. Then obviously root logins would have to make use of this file
> as well, but i'm sure that can be arranged. I'll look more into this.

What other variables do you have in mind?

Thanks,
Ludo’.