GNU bug report logs -
#39671
Something appears to disable linux kernel modules from loading.
Previous Next
Reported by: Joshua Branson <jbranso <at> dismail.de>
Date: Tue, 18 Feb 2020 23:12:01 UTC
Severity: important
Done: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39671 in the body.
You can then email your comments to 39671 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Tue, 18 Feb 2020 23:12:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Joshua Branson <jbranso <at> dismail.de>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Tue, 18 Feb 2020 23:12:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello!
tl;dr
Something is causing linux 5.4.20 not to load kernel modules at boot.
Perhaps the culprit is the shepherd 0.7.0.
So I recently reconfigured guix on my ThinkPad T400.
#+BEGIN_SRC sh
$ guix describe
Generation 32 Feb 18 2020 16:53:46 (current)
jmacs 1a401c8
repository URL: https://notabug.org/jbranso/guix-packages.git
branch: master
commit: 1a401c81ed0617e2ca2fa37ec8caa9ca96032b7a
guix 97c6670
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 97c6670ef79bbf5e82dece2e837ed73b6462da01
#+END_SRC
After I rebooted sway refused to start. The sway error message said
#+BEGIN_SRC sh
$ sway
[backend/backend.c:339] Failed to open any DRM device.
[sway/server.c] Unable to create backend.
#+END_SRC
So sway is not starting. I believe this is because my i915 intel
driver is not loaded. I know this is the case, because the text on my
virtual console is LARGE. $ sudo modprobe i915 loads the required
driver. And I can now log into sway.
However, my ethernet driver is not loaded.
#+BEGIN_SRC sh
$ lsmod | grep e1000e
#+END_SRC
#+BEGIN_SRC sh
$ sudo modprobe e1000e
#+END_SRC
Then I ran ifconfig, and indeed I now have an ethernet device.
#+BEGIN_SRC sh :results output :exports both
$ ifconfig
enp0s25 Link encap:Ethernet HWaddr 00:1C:25:9A:37:BA
inet addr:172.16.113.199 Bcast:172.16.115.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:505 errors:0 dropped:0 overruns:0 frame:0
TX packets:570 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:143838 TX bytes:60886
Interrupt:20 Memory:fc100000-fc120000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:0.0.0.0 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 TX bytes:0
#+END_SRC
And I now have an internet connection.
#+BEGIN_SRC sh :results output :exports both
joshua <at> dobby ~/prog/org$ ping -c 3 gnu.org
PING gnu.org (209.51.188.148): 56 data bytes
64 bytes from 209.51.188.148: icmp_seq=0 ttl=56 time=35.610 ms
64 bytes from 209.51.188.148: icmp_seq=1 ttl=56 time=35.635 ms
64 bytes from 209.51.188.148: icmp_seq=2 ttl=56 time=35.501 ms
--- gnu.org ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 35.501/35.582/35.635/0.058 ms
#+END_SRC
But I do not have a working touchpad. I guess my touchpad driver is
not loaded. I'm not certain what driver my touchpad uses, so for now
I am doing with out.
I then went and asked for some tips on irc. HappyEnt claimed the
problem for him was commit 205c1e0.
janneke was also having issues with kernel modules not being
automatically booted. He said that this commit worked for him:
ef2b1d2c8b60776bf66573b0c810474e9e1a4abd. He then said that commit
d39885a8a9e0e03c2bf6277d475d384168bba642 also worked, which implied
the problem was not the linux version 5.4.20, but possibly the
shepherd.
I tried reconfiguring with commit
d39885a8a9e0e03c2bf6277d475d384168bba642, to see if that solved my issue.
#+BEGIN_SRC sh :results output :exports both
guix time-machine --commit=d39885a8a9e0e03c2bf6277d475d384168bba642 -- system reconfigure
#+END_SRC
#+BEGIN_SRC sh
$ uname -r
5.4.20-gnu
#+END_SRC
janneke's commit did solve my issue. After rebooting, sway starts, I
have internet, and my touchpad and sound work.
Man I love guix system. It really does work smoothly, even when you
have problems. So thanks for making a great GNU/Linux distro!
Thanks Joshua
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Wed, 19 Feb 2020 21:19:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 39671 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Guix!
After my system reconfigure, GDM didn't start. During boot, I saw "New
gdm session c1" followed by "Session c1 removed".
For me, the last known commit to work properly is "41884bf". Anything
after that breaks my system.
Regards,
RG.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Wed, 19 Feb 2020 21:32:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 39671 <at> debbugs.gnu.org (full text, mbox):
Hi!
Joshua Branson <jbranso <at> dismail.de> skribis:
> After I rebooted sway refused to start. The sway error message said
>
> #+BEGIN_SRC sh
> $ sway
>
> [backend/backend.c:339] Failed to open any DRM device.
> [sway/server.c] Unable to create backend.
> #+END_SRC
>
>
> So sway is not starting. I believe this is because my i915 intel
> driver is not loaded. I know this is the case, because the text on my
> virtual console is LARGE. $ sudo modprobe i915 loads the required
> driver. And I can now log into sway.
>
> However, my ethernet driver is not loaded.
On IRC, tsmish posted this bisect log:
--8<---------------cut here---------------start------------->8---
1 git bisect start
2 # bad: [bfb6c393b91dc4a236678a0682348d5b7bd77193] gnu: gwl: Build with Guile 3.
3 git bisect bad bfb6c393b91dc4a236678a0682348d5b7bd77193
4 # good: [d98f7fdabe27f3441f317af3e7f5a979edf5d741] remove sane-backends from wine inputs for now
5 git bisect good d98f7fdabe27f3441f317af3e7f5a979edf5d741
6 # good: [505b2631a9c35bbaa5ba6771ad4f646086f23cad] gnu: le-certs: Update input hashes.
7 git bisect good 505b2631a9c35bbaa5ba6771ad4f646086f23cad
8 # bad: [b4e0166e2d7d9d4b57e1caeb026936f957858ec9] gnu: Add rust-quasi-0.32.
9 git bisect bad b4e0166e2d7d9d4b57e1caeb026936f957858ec9
10 # bad: [d46646d9c772fb699ca24a56f815695eecdcb513] gnu: python-blinker: Use HTTPS home page.
11 git bisect bad d46646d9c772fb699ca24a56f815695eecdcb513
12 # good: [9469ab532fe561b8bb679ba8bf08f1c1f5f9374a] gnu: ddclient: Update home page.
13 git bisect good 9469ab532fe561b8bb679ba8bf08f1c1f5f9374a
14 # good: [3603f5536ee0223f2e15ca6c518ab922030646dd] gnu: wabt: Use Texinfo mark-up.
15 git bisect good 3603f5536ee0223f2e15ca6c518ab922030646dd
16 # bad: [205c1e04e04b9a9338c7219ff82bd13f000fb8c8] gnu: shepherd: Update to 0.7.0.
17 git bisect bad 205c1e04e04b9a9338c7219ff82bd13f000fb8c8
--8<---------------cut here---------------end--------------->8---
What does “cat /proc/sys/kernel/modprobe” return on the broken system?
I would expect 8b9cad01e9619f53dc5a65892ca6a09ca5de3447 to be suspect #1
because it potentially leads to ‘LINUX_MODULE_DIRECTORY’ being unset in
places where it used to be set before.
> Man I love guix system. It really does work smoothly, even when you
> have problems. So thanks for making a great GNU/Linux distro!
Heh. :-)
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Wed, 19 Feb 2020 21:51:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 39671 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, 19 Feb 2020, Ludovic Courtès wrote:
> What does “cat /proc/sys/kernel/modprobe” return on the broken system?
/gnu/store/daq5zs7ni529zh3xxgyhidna52wa17js-modprobe
The contents of that file are:
"""
#!/gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile --no-auto-compile
!#
(begin (setenv "LINUX_MODULE_DIRECTORY" "/run/booted-system/kernel/lib/modules")
(apply execl "/run/current-system/profile/bin/modprobe"
(cons "/run/current-system/profile/bin/modprobe" (cdr (command-line)))))
"""
> I would expect 8b9cad01e9619f53dc5a65892ca6a09ca5de3447 to be suspect #1
> because it potentially leads to ‘LINUX_MODULE_DIRECTORY’ being unset in
> places where it used to be set before.
Based on the commit message, I would have expected that too, but
205c1e04e04b9a9338c7219ff82bd13f000fb8c8 is the first bad commit for me as
well. The above modprobe script is from a system at commit
8b9cad01e9619f53dc5a65892ca6a09ca5de3447.
Best,
Jack
Severity set to 'important' from 'normal'
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Wed, 19 Feb 2020 22:09:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Wed, 19 Feb 2020 22:13:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 39671 <at> debbugs.gnu.org (full text, mbox):
Jack Hill <jackhill <at> jackhill.us> skribis:
> On Wed, 19 Feb 2020, Ludovic Courtès wrote:
>
>> What does “cat /proc/sys/kernel/modprobe” return on the broken system?
>
> /gnu/store/daq5zs7ni529zh3xxgyhidna52wa17js-modprobe
>
> The contents of that file are:
>
> """
> #!/gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile --no-auto-compile
> !#
> (begin (setenv "LINUX_MODULE_DIRECTORY" "/run/booted-system/kernel/lib/modules")
> (apply execl "/run/current-system/profile/bin/modprobe"
> (cons "/run/current-system/profile/bin/modprobe" (cdr (command-line)))))
> """
The kernel’s lazy module loading mechanism invokes this program, which
should just work.
Does /run/current-system/profile/bin/modprobe exist?
Any hints in “dmesg” or /var/log/messages?
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Wed, 19 Feb 2020 22:51:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 39671 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, 19 Feb 2020, Ludovic Courtès wrote:
> The kernel’s lazy module loading mechanism invokes this program, which
> should just work.
>
> Does /run/current-system/profile/bin/modprobe exist?
Yes, it is a symlink to
/gnu/store/d064bv2b1hrb07j2zj78i608db7qldx9-kmod-26/bin/modprobe
> Any hints in “dmesg” or /var/log/messages?
Not that jump out at me. I do see
udevd[197]: no sender credentials received, message ignored
printed in red, but that message also appears when everything is working
correctly.
The full dmesg output is attached. The bit at the end about e1000e was
after I manually ran `modprobe e1000e`.
Best,
Jack
[dmesg (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 10:19:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 39671 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Feb 19, 2020 at 04:50:06PM -0500, Jack Hill wrote:
> Based on the commit message, I would have expected that too, but
> 205c1e04e04b9a9338c7219ff82bd13f000fb8c8 is the first bad commit for me as
> well.
I can confirm this commit broke xf86-video-fbdev (no DRI support), USB
ethernet and USB modem support for me. The output of running as root
out=~florian/environ-bad ; for f in $(ls /proc); do ls -l /proc/$f/exe; cat /proc/$f/environ; done > $out; chown florian:users $out
is attached as environ-bad.
Patching Shepherd to revert 501d62c4d235045e79e5aef684b5a9250c1cf8c4
(service: Export 'default-environment-variables') leads to a kernel
panic. Doing that and reverting Guix commit
8b9cad01e9619f53dc5a65892ca6a09ca5de3447 (after a rebuild of udisks
and dependencies — why?) leads to a working system again. It is
attached as environ-good.
Regards,
Florian
[environ-bad (application/octet-stream, attachment)]
[environ-good (application/octet-stream, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 12:13:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 39671 <at> debbugs.gnu.org (full text, mbox):
On Thu, Feb 20, 2020 at 11:18:29AM +0100, pelzflorian (Florian Pelz) wrote:
> Patching Shepherd to revert 501d62c4d235045e79e5aef684b5a9250c1cf8c4
> (service: Export 'default-environment-variables') leads to a kernel
> panic. Doing that and reverting Guix commit
> 8b9cad01e9619f53dc5a65892ca6a09ca5de3447 (after a rebuild of udisks
> and dependencies — why?) leads to a working system again.
P.S. It is *not* sufficient to only revert
8b9cad01e9619f53dc5a65892ca6a09ca5de3447.
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 15:57:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 39671 <at> debbugs.gnu.org (full text, mbox):
So I just ran guix pull & reconfigure.
joshua <at> dobby /run/booted-system/kernel/lib/modules$ guix describe
Generation 36 Feb 20 2020 10:11:40 (current)
jmacs 65b1737
repository URL: https://notabug.org/jbranso/guix-packages.git
branch: master
commit: 65b17377136095935ef6da3a836142d56fecce2b
guix bf8dfe3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bf8dfe3df025e4ac80cccb87497b4f072ba10e2a
So I feel like Jack beat me to it,
but the contents of /proc/sys/kernel/modprobe are:
#+BEGIN_SRC sh
$ cat /proc/sys/kernel/modprobe
/gnu/store/daq5zs7ni529zh3xxgyhidna52wa17js-modprobe
#+END_SRC
#+BEGIN_SRC sh
cat /gnu/store/daq5zs7ni529zh3xxgyhidna52wa17js-modprobe
#!/gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile --no-auto-compile
!#
(begin (setenv "LINUX_MODULE_DIRECTORY" "/run/booted-system/kernel/lib/modules") (apply execl "/run/current-system/profile/bin/modprobe" (cons "/run/current-system/profile/bin/modprobe" (cdr (command-line)))))~ $
#+END_SRC
Then I was just poking around.
#+BEGIN_SRC sh
~ $ cat /run/booted-system/kernel/lib/modules
Read error: Is a directory, /run/booted-system/kernel/lib/modules
~ $ cd /run/booted-system/kernel/lib/modules
/run/booted-system/kernel/lib/modules $ ls
5.4.21-gnu
/run/booted-system/kernel/lib/modules $ cd 5.4.21-gnu/
/run/booted-system/kernel/lib/modules/5.4.21-gnu $ ls
build modules.alias modules.builtin modules.builtin.modinfo modules.dep.bin modules.order modules.symbols source
kernel modules.alias.bin modules.builtin.bin modules.dep modules.devname modules.softdep modules.symbols.bin
/run/booted-system/kernel/lib/modules/5.4.21-gnu $ cat modules.order
kernel/arch/x86/events/amd/power.ko
kernel/arch/x86/kernel/msr.ko
kernel/arch/x86/kernel/cpuid.ko
kernel/arch/x86/crypto/glue_helper.ko
kernel/arch/x86/crypto/des3_ede-x86_64.ko
kernel/arch/x86/crypto/camellia-x86_64.ko
kernel/arch/x86/crypto/blowfish-x86_64.ko
kernel/arch/x86/crypto/twofish-x86_64.ko
kernel/arch/x86/crypto/twofish-x86_64-3way.ko
... tons more modules...
kernel/drivers/gpu/drm/i915/i915.ko
kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
#+END_SRC
You'll notice that my i915 graphics and e1000e (ethernet) driver is
listed in that directory.
On my working system, these were the modules that lspci -v showed I was
using:
#+BEGIN_SRC sh :results output :exports both
lspci -v | grep "Kernel driver in"
#+END_SRC
#+RESULTS:
#+begin_example
Kernel driver in use: i915
Kernel driver in use: e1000e
Kernel driver in use: uhci_hcd
Kernel driver in use: uhci_hcd
Kernel driver in use: uhci_hcd
Kernel driver in use: ehci-pci
Kernel driver in use: snd_hda_intel
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: uhci_hcd
Kernel driver in use: uhci_hcd
Kernel driver in use: uhci_hcd
Kernel driver in use: ehci-pci
Kernel driver in use: lpc_ich
Kernel driver in use: ata_piix
Kernel driver in use: i801_smbus
Kernel driver in use: yenta_cardbus
Kernel driver in use: firewire_ohci
#+end_example
On the broken system, I am able to load my i915 and e1000e driver, but I
am not able to load yenta_cardbus.
#+BEGIN_SRC sh
$ sudo modprobe yenta_cardbus
modprobe: FATAL: Module yenta_cardbus not found in directory /run/booted-system/kernel/lib/modules/5.4.21-gnu
#+END_SRC
Sorry if I'm being repetitive. I am just wanting to help. :)
--
Joshua Branson
Sent from Emacs and Gnus
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 20:00:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 39671 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The attached patch fixes the issue for me. Can someone confirm?
It replaces or copies setenv calls for the udev service.
There are more service definitions that call setenv; I do not know if
they need to be moved too.
I will try if a smaller patch would suffice as well now.
Regards,
Florian
[0001-services-udev-Do-not-rely-on-shepherd-inheriting-env.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 20:35:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 39671 <at> debbugs.gnu.org (full text, mbox):
On Thu, Feb 20, 2020 at 08:59:25PM +0100, pelzflorian (Florian Pelz) wrote:
> The attached patch fixes the issue for me. Can someone confirm?
>
> It replaces or copies setenv calls for the udev service.
>
> There are more service definitions that call setenv; I do not know if
> they need to be moved too.
>
> I will try if a smaller patch would suffice as well now.
>
> Regards,
> Florian
> From 11509370049355680c815e06250afc09325c589c Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> Date: Thu, 20 Feb 2020 14:05:06 +0100
> Subject: [PATCH] services: udev: Do not rely on shepherd inheriting
> environment variables.
>
> Fixes <https://bugs.gnu.org/39671>.
>
> * gnu/services/base.scm (udev-shepherd-service)[start] Move or copy
> environment variables to 'fork+exec-command' instead of 'setenv'.
Thanks! Which commmit is this based on? I can't apply it with `git
am`...
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 20:44:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 39671 <at> debbugs.gnu.org (full text, mbox):
On Thu, Feb 20, 2020 at 03:34:02PM -0500, Leo Famulari wrote:
> Thanks!
:)
>Which commmit is this based on? I can't apply it with `git
> am`...
commit bfb6c393b91dc4a236678a0682348d5b7bd77193 (origin/master, origin/HEAD)
Author: Ricardo Wurmus <rekado <at> elephly.net>
Date: Wed Feb 19 15:44:50 2020 +0100
gnu: gwl: Build with Guile 3.
(I wonder why it does not apply; there were no changes to
gnu/services/base.scm in a long time. Strange.)
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 20:59:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 39671 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Feb 20, 2020 at 09:43:45PM +0100, pelzflorian (Florian Pelz) wrote:
> (I wonder why it does not apply; there were no changes to
> gnu/services/base.scm in a long time. Strange.)
>
It did not apply for me either. Here it is in compressed form so its
encoding is not changed.
Thank you Leo!
Regards,
Florian
[0001-services-udev-Do-not-rely-on-shepherd-inheriting-env.patch.xz (application/x-xz, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 21:08:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 39671 <at> debbugs.gnu.org (full text, mbox):
On Thu, Feb 20, 2020 at 09:43:45PM +0100, pelzflorian (Florian Pelz) wrote:
> (I wonder why it does not apply; there were no changes to
> gnu/services/base.scm in a long time. Strange.)
Oh well, I applied it "by hand" and everything seems to be working
again :) Thank you!
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 21:10:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 39671 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
pelzflorian (Florian Pelz) writes:
Hi Florian,
> On Thu, Feb 20, 2020 at 09:43:45PM +0100, pelzflorian (Florian Pelz) wrote:
>> (I wonder why it does not apply; there were no changes to
>> gnu/services/base.scm in a long time. Strange.)
>>
>
> It did not apply for me either. Here it is in compressed form so its
> encoding is not changed.
It works for me; thank you! It did not apply -- I do not have this
From 11509370049355680c815e06250afc09325c589c Mon Sep 17 00:00:00 2001
commit.
Attached is the result of my manual application...
janneke
[0001-services-udev-Do-not-rely-on-shepherd-inheriting-env.patch (text/x-patch, inline)]
From d057c431b707b26ce852d8ba692e9307248d0f63 Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian <at> pelzflorian.de>
Date: Thu, 20 Feb 2020 14:05:06 +0100
Subject: [PATCH] services: udev: Do not rely on shepherd inheriting
environment variables.
Fixes <https://bugs.gnu.org/39671>.
* gnu/services/base.scm (udev-shepherd-service)[start] Move or copy
environment variables to 'fork+exec-command' instead of 'setenv'.
---
gnu/services/base.scm | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 0c154d1c4e..706b3ae7ec 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -11,6 +11,7 @@
;;; Copyright © 2019 Tobias Geerinckx-Rice <me <at> tobias.gr>
;;; Copyright © 2019 John Soo <jsoo1 <at> asu.edu>
;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen <janneke <at> gnu.org>
+;;; Copyright © 2020 Florian Pelz <pelzflorian <at> pelzflorian.de>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -2037,11 +2038,6 @@ item of @var{packages}."
(setenv "LINUX_MODULE_DIRECTORY"
"/run/booted-system/kernel/lib/modules")
- ;; The first one is for udev, the second one for eudev.
- (setenv "UDEV_CONFIG_FILE" #$udev.conf)
- (setenv "EUDEV_RULES_DIRECTORY"
- #$(file-append rules "/lib/udev/rules.d"))
-
(let* ((kernel-release
(utsname:release (uname)))
(linux-module-directory
@@ -2058,7 +2054,18 @@ item of @var{packages}."
(make-static-device-nodes directory))
(umask old-umask))
- (let ((pid (fork+exec-command (list udevd))))
+ (let ((pid (fork+exec-command (list udevd)
+ #:environment-variables
+ (cons*
+ ;; The first one is for udev, the second one for
+ ;; eudev.
+ (string-append "UDEV_CONFIG_FILE=" #$udev.conf)
+ (string-append "EUDEV_RULES_DIRECTORY="
+ #$(file-append
+ rules "/lib/udev/rules.d"))
+ (string-append "LINUX_MODULE_DIRECTORY="
+ (getenv "LINUX_MODULE_DIRECTORY"))
+ (default-environment-variables)))))
;; Wait until udevd is up and running. This appears to
;; be needed so that the events triggered below are
;; actually handled.
--
2.24.0
[Message part 3 (text/plain, inline)]
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Information forwarded
to
bug-guix <at> gnu.org:
bug#39671; Package
guix.
(Thu, 20 Feb 2020 22:04:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 39671 <at> debbugs.gnu.org (full text, mbox):
Hi Florian,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
>>From 11509370049355680c815e06250afc09325c589c Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> Date: Thu, 20 Feb 2020 14:05:06 +0100
> Subject: [PATCH] services: udev: Do not rely on shepherd inheriting
> environment variables.
>
> Fixes <https://bugs.gnu.org/39671>.
>
> * gnu/services/base.scm (udev-shepherd-service)[start] Move or copy
> environment variables to 'fork+exec-command' instead of 'setenv'.
Good catch, it makes perfect sense. Please push!
Ludo’, who, ahem, apologizes for the inconvenience.
Reply sent
to
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>:
You have taken responsibility.
(Thu, 20 Feb 2020 23:25:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Joshua Branson <jbranso <at> dismail.de>:
bug acknowledged by developer.
(Thu, 20 Feb 2020 23:25:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 39671-done <at> debbugs.gnu.org (full text, mbox):
Thank you Jan and Leo for testing and Ludo for confirming it makes
sense, and of course to all bug reporters. Closing this bug. I guess
I will switch e-mail programs so maybe the encoding of patches I send
is not broken.
And thank you to Ludo for making important (though breaking) changes
to Shepherd, making it more functional. Other than udev, the other
uses of setenv in (gnu services …) look benign.
Regards,
Florian
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 20 Mar 2020 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 30 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.