GNU bug report logs - #41546
Shepherd network activation failures on armhf

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jesse Dowell <jesse.dowell <at> gmail.com>
Subject: bug#41546: closed (Re: bug#41546: Shepherd network activation
 failures on armhf)
Date: Fri, 29 May 2020 16:36:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#41546: Shepherd network activation failures on armhf

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 41546 <at> debbugs.gnu.org.

-- 
41546: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=41546
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jesse Dowell <jesse.dowell <at> gmail.com>
Cc: 41546-done <at> debbugs.gnu.org
Subject: Re: bug#41546: Shepherd network activation failures on armhf
Date: Fri, 29 May 2020 18:35:29 +0200

Hi Jesse,

Jesse Dowell <jesse.dowell <at> gmail.com> skribis:

> I was able to track my issue down to recently introduced code in
> guix/build/syscalls.scm related to the GNU Hurd.
>
> The following patch fixes the problem for me. The core of the issue is that
> the new Hurd related  checks use string-suffix? rather than string-contains
> like the code elsewhere in the module.
>
> Whan string-suffix? is used it doesn't match my system %host-type which is
> "arm-unknown-linux-gnueabihf" and the xxxx-socket-address!/hurd branch is
> taken rather than xxxx-socket-address!/linux.

Indeed, great investigation work!

> I don't know if this is only a problem on my unsupported device. I'm
> running guix system on a Raspberry Pi 4b.
>
> Here's the patch that fixes the issue for me.
> -------------------------
> diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
> index 8070c5546f..6be322d68f 100644
> --- a/guix/build/syscalls.scm
> +++ b/guix/build/syscalls.scm
> @@ -1404,7 +1404,7 @@ bytevector BV at INDEX."
>             (error "unsupported socket address" sockaddr)))))
>
>  (define write-socket-address!
> -  (if (string-suffix? "linux-gnu" %host-type)
> +  (if (string-contains %host-type "linux-gnu")
>        write-socket-address!/linux
>        write-socket-address!/hurd))
>
> @@ -1436,7 +1436,7 @@ bytevector BV at INDEX."
>             (vector family)))))
>
>  (define read-socket-address
> -  (if (string-suffix? "linux-gnu" %host-type)
> +  (if (string-contains %host-type "linux-gnu")
>        read-socket-address/linux
>        read-socket-address/hurd))

I pushed it as b56cbe8974c328a6c7bc28906478ef1b191ada4c on your behalf.

Thank you!

Ludo’.

[Message part 3 (message/rfc822, inline)]

From: Jesse Dowell <jesse.dowell <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: Shepherd network activation failures on armhf
Date: Tue, 26 May 2020 16:02:10 -0400

[Message part 4 (text/plain, inline)]

Hello,

I recently experienced a problem with the latest master branch code on an
armhf device. I was able to track down and fix the issue but it required
changes to guix/build/syscalls.scm.

My system previously booted correctly but after a recent 'guix pull' and
'guix system reconfigure' my device would fail to activate all networking
related services on boot including loopback.

The error message on failure in the terminal when trying to 'herd start
networking' was unhelpful but manual management of the network interfaces
could be completed successfully so it seemed to be an issue specific to the
way Shepherd was activating the loopback interface.

I was able to track my issue down to recently introduced code in
guix/build/syscalls.scm related to the GNU Hurd.

The following patch fixes the problem for me. The core of the issue is that
the new Hurd related  checks use string-suffix? rather than string-contains
like the code elsewhere in the module.

Whan string-suffix? is used it doesn't match my system %host-type which is
"arm-unknown-linux-gnueabihf" and the xxxx-socket-address!/hurd branch is
taken rather than xxxx-socket-address!/linux.

I don't know if this is only a problem on my unsupported device. I'm
running guix system on a Raspberry Pi 4b.

Here's the patch that fixes the issue for me.
-------------------------
diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 8070c5546f..6be322d68f 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -1404,7 +1404,7 @@ bytevector BV at INDEX."
            (error "unsupported socket address" sockaddr)))))

 (define write-socket-address!
-  (if (string-suffix? "linux-gnu" %host-type)
+  (if (string-contains %host-type "linux-gnu")
       write-socket-address!/linux
       write-socket-address!/hurd))

@@ -1436,7 +1436,7 @@ bytevector BV at INDEX."
            (vector family)))))

 (define read-socket-address
-  (if (string-suffix? "linux-gnu" %host-type)
+  (if (string-contains %host-type "linux-gnu")
       read-socket-address/linux
       read-socket-address/hurd))
 ---------------------------

Best Regards,
Jesse

[Message part 5 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.