Re: modprobe on guix
> 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
Petterskribis: >> 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’.
Re: modprobe on guix
Petterskribis: > (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
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 (2015-03-26 00:01 +0300) wrote: Alex Kost alez...@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
白い熊@相撲道 guix-devel_gnu@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
Mark H Weaver (2015-03-25 15:57 +0300) wrote: 白い熊@相撲道 guix-devel_gnu@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
Alex Kost alez...@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’.