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

Previous Next

Package: guix;

Reported by: Jesse Dowell <jesse.dowell <at> gmail.com>

Date: Tue, 26 May 2020 20:09:02 UTC

Severity: normal

Done: Ludovic Courtès <ludo <at> gnu.org>

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 41546 in the body.
You can then email your comments to 41546 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#41546; Package guix. (Tue, 26 May 2020 20:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jesse Dowell <jesse.dowell <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Tue, 26 May 2020 20:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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 1 (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 2 (text/html, inline)]

Reply sent to Ludovic Courtès <ludo <at> gnu.org>:
You have taken responsibility. (Fri, 29 May 2020 16:36:01 GMT) Full text and rfc822 format available.

Notification sent to Jesse Dowell <jesse.dowell <at> gmail.com>:
bug acknowledged by developer. (Fri, 29 May 2020 16:36:01 GMT) Full text and rfc822 format available.

Message #10 received at 41546-done <at> debbugs.gnu.org (full text, mbox):

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’.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 27 Jun 2020 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 303 days ago.

Previous Next


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