Wired networking problems after guix system reconfigure

Wired networking problems after guix system reconfigure

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 6290 bytes --]

Hi,

I recently reconfigured my GuixSD system by running the following
commands (I've attached all logs mentioned below, in their entirety, in
files.tar.gz):

--8<---------------cut here---------------start------------->8---
sudo guix pull
sudo guix system reconfigure my_config_file.scm
--8<---------------cut here---------------end--------------->8---

The commands completed successfully, but the next time I booted my
laptop, I found that I had no network connectivity.

Before the change, I saw messages like this when running "dmesg -T -x"
after boot (b44 is my ethernet driver):

--8<---------------cut here---------------start------------->8---
kern  :info  : [Mon Feb 15 21:48:05 2016] b44: Broadcom 44xx/47xx 10/100 PCI ethernet driver version 2.0
kern  :info  : [Mon Feb 15 21:48:05 2016] b44 ssb0:0 eth0: Broadcom 44xx/47xx 10/100 PCI ethernet driver 00:19:b9:7e:b4:cd
kern  :info  : [Mon Feb 15 21:49:03 2016] b44 ssb0:0 eth0: Link is up at 100 Mbps, full duplex
kern  :info  : [Mon Feb 15 21:49:03 2016] b44 ssb0:0 eth0: Flow control is off for TX and off for RX
kern  :info  : [Mon Feb 15 21:49:12 2016] b44 ssb0:0 eth0: powering down PHY
kern  :info  : [Mon Feb 15 21:49:12 2016] b44 ssb0:0 eth0: powering down PHY
kern  :info  : [Mon Feb 15 21:49:19 2016] b44 ssb0:0 eth0: Link is up at 100 Mbps, full duplex
kern  :info  : [Mon Feb 15 21:49:19 2016] b44 ssb0:0 eth0: Flow control
is off for TX and off for RX
--8<---------------cut here---------------end--------------->8---

After the change, b44 only emitted these lines in dmesg:

--8<---------------cut here---------------start------------->8---
kern  :info  : [Mon Feb 15 22:20:16 2016] b44: Broadcom 44xx/47xx 10/100 PCI ethernet driver version 2.0
kern  :info  : [Mon Feb 15 22:20:16 2016] b44 ssb0:0 eth0: Broadcom 44xx/47xx 10/100 PCI ethernet driver 00:19:b9:7e:b4:cd
--8<---------------cut here---------------end--------------->8---

Digging deeper, I noticed that my system appears to be using wicd to
manage the network interfaces. When I checked the wicd logs, I found
that before the reconfigure, it was successfully doing its job, but
after the reconfigure, it was failing.

Here, before the reconfigure, you can see wicd successfully configuring
eth0:

--8<---------------cut here---------------start------------->8---
2016/02/15 21:48:54 :: automatically detected wired interface eth0
2016/02/15 21:48:54 :: setting wired interface eth0
[ ... some lines omitted ... ]
2016/02/15 21:49:00 :: Autoconnecting...
2016/02/15 21:49:02 :: No wired connection present, attempting to autoconnect to wireless network
2016/02/15 21:49:02 :: Unable to autoconnect, you'll have to manually connect
2016/02/15 21:49:05 :: Autoconnecting...
2016/02/15 21:49:12 :: Attempting to autoconnect with wired interface...
2016/02/15 21:49:12 :: Putting interface down
2016/02/15 21:49:12 :: Releasing DHCP leases...
2016/02/15 21:49:17 :: Setting false IP...
2016/02/15 21:49:17 :: Stopping wpa_supplicant
2016/02/15 21:49:17 :: Flushing the routing table...
2016/02/15 21:49:17 :: Putting interface up...
2016/02/15 21:49:19 :: Running DHCP with NO hostname
2016/02/15 21:49:19 :: Internet Systems Consortium DHCP Client 4.3.1
2016/02/15 21:49:19 :: Copyright 2004-2014 Internet Systems Consortium.
2016/02/15 21:49:19 :: All rights reserved.
2016/02/15 21:49:19 :: For info, please visit https://www.isc.org/software/dhcp/
2016/02/15 21:49:19 :: 
2016/02/15 21:49:20 :: Listening on LPF/eth0/00:19:b9:7e:b4:cd
2016/02/15 21:49:20 :: Sending on   LPF/eth0/00:19:b9:7e:b4:cd
2016/02/15 21:49:20 :: Sending on   Socket/fallback
2016/02/15 21:49:20 :: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
2016/02/15 21:49:23 :: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
2016/02/15 21:49:24 :: DHCPREQUEST on eth0 to 255.255.255.255 port 67
2016/02/15 21:49:24 :: DHCPOFFER from 192.168.1.1
2016/02/15 21:49:24 :: DHCPACK from 192.168.1.1
2016/02/15 21:49:24 :: bound to 192.168.1.112 -- renewal in 38530 seconds.
2016/02/15 21:49:24 :: DHCP connection successful
2016/02/15 21:49:24 :: Connecting thread exiting.
2016/02/15 21:49:24 :: Sending connection attempt result success
--8<---------------cut here---------------end--------------->8---

However, after the reconfigure, wicd fails to configure eth0:

--8<---------------cut here---------------start------------->8---
2016/02/15 22:20:49 :: automatically detected wired interface eth0
2016/02/15 22:20:49 :: setting wired interface eth0
[ ... some lines omitted ... ]
2016/02/15 22:20:55 :: Autoconnecting...
2016/02/15 22:21:03 :: Error checking link using /sys/class/net/eth0/carrier
2016/02/15 22:21:03 :: Wired Interface is down, putting it up
2016/02/15 22:21:07 :: No wired connection present, attempting to autoconnect to wireless network
2016/02/15 22:21:07 :: Unable to autoconnect, you'll have to manually connect
[ ... repeats forever ... ]
--8<---------------cut here---------------end--------------->8---

So, it seems wicd is having trouble with /sys/class/net/eth0/carrier. As
it turns out, before the reconfigure, I could read this file just fine:

--8<---------------cut here---------------start------------->8---
[0] marusich@garuda:~
$ cat /sys/class/net/eth0/carrier
1
[0] marusich@garuda:~
$ 
--8<---------------cut here---------------end--------------->8---

However, after the reconfigure, something is wrong with the file:

--8<---------------cut here---------------start------------->8---
[0] marusich@garuda:~/guix
$ cat /sys/class/net/eth0/carrier
cat: /sys/class/net/eth0/carrier: Invalid argument
[1] marusich@garuda:~/guix
$ 
--8<---------------cut here---------------end--------------->8---

This is pretty weird. My understanding is that the sysfs entries are a
userspace interface to the kernel data structures, so my guess is that
something is wrong with the Linux-libre kernel or the b44 driver. I'm
not sure how to investigate further, though.

What can I do? My goal is to have network access even after running
"guix system reconfigure". All the data I've gathered so far, including
the system configuration file that I used to instantiate the new GuixSD
system, is contained in the attached file (files.tar.gz). I hope with
your help I can figure out what the problem is and fix it.

Thank you,
Chris Marusich


[-- Attachment #2: files.tar.gz --]
[-- Type: application/octet-stream, Size: 33583 bytes --]

Re: Wired networking problems after guix system reconfigure

[Chris Marusich]

Hi,

Can I pin my system to a specific kernel version without modifying the
files in my local guix git repository?

Here's why I want to do this. By using git bisect, I've determined that
the following change introduced the regression I mentioned in my
previous email:

6b0d24b gnu: linux-libre: Update to 4.4.

This change updated linux-libre from 4.3.3 to 4.4, so the problem was
introduced somewhere inbetween.

As a temporary workaround, I've added a linux-libre-4.3 variable to the
(gnu packages linux) module in my local guix git repository, which
allows me to use that variable in my GuixSD system configuration
file. This is basically the same thing that was done in commit adddd5b,
in which a linux-libre-4.1 variable was added to enable Libreboot X200
users to work around a different known kernel regression [1].

This is great! Now networking works again in GuixSD on my Dell Inspiron
1520 laptop. However, this workaround is a little awkward. Because it's
a patch in my local guix git repository, I'll have to tediously re-apply
it every time I update the git repo. In addition, judging by commit
adddd5b, it looks like the linux-libre kernel versions in (gnu packages
linux) are somehow intertwined with other parts of the system. For
example, that commit also modified Makefile.am (but I'm not sure why).

This makes me wonder: Is it possible to define my own kernel version
outside of the guix checkout (perhaps by way of GUILE_LOAD_PATH) for use
in my GuixSD operating system configuration file? I believe this can be
done for packages in general, but I'm not sure if it's easy to do for
the linux-libre kernel specifically. I'd like to do this, since it would
make it easier to keep using my workaround, and it might also make it
easier to perform a git bisect of the linux-libre changes between 4.3.3
and 4.4 to determine the exact cause of the regression and report it
upstream.

If anyone has experience doing this, I'd love to talk with you.

Thank you,
Chris

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22274

Re: Wired networking problems after guix system reconfigure

[Ludovic Courtès]

Chris Marusich <cmmarusich@gmail.com> skribis:

> Can I pin my system to a specific kernel version without modifying the
> files in my local guix git repository?

Of course!  :-)

> Here's why I want to do this. By using git bisect, I've determined that
> the following change introduced the regression I mentioned in my
> previous email:
>
> 6b0d24b gnu: linux-libre: Update to 4.4.
>
> This change updated linux-libre from 4.3.3 to 4.4, so the problem was
> introduced somewhere inbetween.
>
> As a temporary workaround, I've added a linux-libre-4.3 variable to the
> (gnu packages linux) module in my local guix git repository, which
> allows me to use that variable in my GuixSD system configuration
> file. This is basically the same thing that was done in commit adddd5b,
> in which a linux-libre-4.1 variable was added to enable Libreboot X200
> users to work around a different known kernel regression [1].

Perfect.  To avoid modifying files in the Guix tree itself, you could
put this ‘linux-libre-4.3’ in a module of its own that you keep in
$GUIX_PACKAGE_PATH, just for your own uses.

Now, if the regression is serious and widespread, you might want to
start an argument on guix-devel as to whether we should provide this
particular kernel version in Guix proper.

Thanks,
Ludo’.

Re: Wired networking problems after guix system reconfigure

[Chris Marusich]

ludo@gnu.org (Ludovic Courtès) writes:

> Perfect.  To avoid modifying files in the Guix tree itself, you could
> put this ‘linux-libre-4.3’ in a module of its own that you keep in
> $GUIX_PACKAGE_PATH, just for your own uses.

OK. I'll try that! Can you tell me why commit adddd5b updates
Makefile.am? That wasn't clear to me, and I don't want to accidentally
forget to do something necessary for installing a custom kernel.

> Now, if the regression is serious and widespread, you might want to
> start an argument on guix-devel as to whether we should provide this
> particular kernel version in Guix proper.

I don't think it's necessary. I haven't heard complaints from anyone
else yet, and I'm pretty sure the linux-libre-4.1 variable that already
exists will work for me, also. I'll consider starting a thread if that
is not the case. I mainly just want to know how to define my own custom
kernel so I can try bisecting the kernel myself to pinpoint the problem.

To help others in the future find this thread if they encounter the same
problem, here are my wired network card specs, according to lspci:

Laptop: Dell Inspiron 1520
Network card: Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

Oh, by the way: there is a wireless network card, also, but it has never
worked (dmesg shows iwl3945 complaining: "Direct firmware load for
/*(DEBLOBBED)*/ failed")), so that isn't a viable alternative for me.

Thank you for the help,
Chris

Re: Wired networking problems after guix system reconfigure

[Ludovic Courtès]

Chris Marusich <cmmarusich@gmail.com> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Perfect.  To avoid modifying files in the Guix tree itself, you could
>> put this ‘linux-libre-4.3’ in a module of its own that you keep in
>> $GUIX_PACKAGE_PATH, just for your own uses.
>
> OK. I'll try that! Can you tell me why commit adddd5b updates
> Makefile.am?

It’s just because it adds new kernel configuration files.  You don’t
have to worry about that if you maintain things out of the tree.

> To help others in the future find this thread if they encounter the same
> problem, here are my wired network card specs, according to lspci:
>
> Laptop: Dell Inspiron 1520
> Network card: Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
>
> Oh, by the way: there is a wireless network card, also, but it has never
> worked (dmesg shows iwl3945 complaining: "Direct firmware load for
> /*(DEBLOBBED)*/ failed")), so that isn't a viable alternative for me.

Right, that means that there is no free firmware for this NIC.

I would recommend using one of the WiFi dongles that has the Respect
Your Freedom stamp, typically things based on Atheros chipsets (the
‘ath9k’ driver) for which there exists free firmware.  See for instance:

  https://www.fsf.org/news/ryf-certification-thinkpenguin-usb-with-atheros-chip

Thanks,
Ludo’.

Re: Wired networking problems after guix system reconfigure

[Chris Marusich]

ludo@gnu.org (Ludovic Courtès) writes:

> I would recommend using one of the WiFi dongles that has the Respect
> Your Freedom stamp, typically things based on Atheros chipsets (the
> ‘ath9k’ driver) for which there exists free firmware.  See for instance:
>
>   https://www.fsf.org/news/ryf-certification-thinkpenguin-usb-with-atheros-chip

Thanks for the tip! I'll get one for my Inspiron 1520 if I can't fix it.

Chris

Re: Wired networking problems after guix system reconfigure

[Andreas Enge]

On Mon, Mar 07, 2016 at 10:50:51AM +0100, Ludovic Courtès wrote:
> I would recommend using one of the WiFi dongles that has the Respect
> Your Freedom stamp, typically things based on Atheros chipsets (the
> ‘ath9k’ driver) for which there exists free firmware.  See for instance:
>   https://www.fsf.org/news/ryf-certification-thinkpenguin-usb-with-atheros-chip

Or this one:
   https://www.fsf.org/resources/hw/endorsement/tehnoetic
to be vendor neutral. I have one of them and it works out of the box
with Guix(SD).

So let us point to the RYF webpage:
   https://www.fsf.org/resources/hw/endorsement/respects-your-freedom
Whatever ends up there should be supported by us, I think.

Andreas