bug#41546: Shepherd network activation failures on armhf

bug#41546: Shepherd network activation failures on armhf

[Jesse Dowell]

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

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

[-- Attachment #2: Type: text/html, Size: 2640 bytes --]

bug#41546: Shepherd network activation failures on armhf

[Ludovic Courtès]

Hi Jesse,

Jesse Dowell <jesse.dowell@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’.