GNU bug report logs - #61173
Wireguard and NF Tables service broken on aarch64

Previous Next

To reply to this bug, email your comments to 61173 AT debbugs.gnu.org.

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

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

From: elais <at> fastmail.com
To: bug-guix <at> gnu.org
Subject: Wireguard and NF Tables service broken on aarch64
Date: Mon, 30 Jan 2023 07:12:36 -0700

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

Right now wireguard and nftable services are broken on the aarch64 kernel due to their respective kernel config parameters not being added as modules or compiled into the kernel. I'm hesitant to call this a bug but it does mean wireguard and nftables are unavailable. A good chunk of iptables operations are missing as well. I don't have much experience configuring a kernel but perhaps there's a way to insure feature parity between the x86_64 and aarch64 kernels?

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

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

From: elais <at> fastmail.com
To: 61173 <at> debbugs.gnu.org
Subject: Wireguard and NF Tables service broken on aarch64
Date: Mon, 30 Jan 2023 22:35:15 -0700

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

after further investigation I've noticed that the latest arm64-generic kernel isnt loading the correct config file. I tested this by using the new `customize-linux` command. When trying to load the defconfig for 6.1 in the repo through customize Linux, the build fails due to divergent defconfig files.

I think linux-libre-arm64-generic just isn't packaging the correct config, and it may be the case that the wrong config is getting packaged by other versions of the kernel ass well.

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

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

From: Richard Sent <richard <at> freakingpenguin.com>
To: elais <at> fastmail.com
Cc: 61173 <at> debbugs.gnu.org
Subject: Re: bug#61173: Wireguard and NF Tables service broken on aarch64
Date: Wed, 22 May 2024 08:36:41 -0400

elais <at> fastmail.com writes:

> Right now wireguard and nftable services are broken on the aarch64
> kernel due to their respective kernel config parameters not being
> added as modules or compiled into the kernel. I'm hesitant to call
> this a bug but it does mean wireguard and nftables are unavailable. A
> good chunk of iptables operations are missing as well. I don't have
> much experience configuring a kernel but perhaps there's a way to
> insure feature parity between the x86_64 and aarch64 kernels?

I ran into this issue myself when using linux-libre-arm64-generic so
it's still around. It can cause boot problems too depending on what
exactly is missing.

qemu-binfmt-service-type adds a file-system dependency on
/proc/sys/fs/binfmt_misc, and requires the kernel to have
CONFIG_BINFMT_MISC set. The 6.8-arm64.conf file does have
CONFIG_BINFMT_MISC=m, but in the compiled kernel that option is unset.
Ergo the file-system doesn't exist and Shepherd fails to finish
initializing file systems.

Seeing as how certain config changes are made to
linux-libre-arm64-generic to improve device compatibility, I hope the
differences can be minimized between the "vanilla" linux-libre and
customized linux-libre-arm64-generic outside of device compatibility
changes to reduce surprises like this.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

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

From: elais <at> fastmail.com
To: Richard Sent <richard <at> freakingpenguin.com>
Cc: 61173 <at> debbugs.gnu.org
Subject: Re: bug#61173: Wireguard and NF Tables service broken on
 aarch64
Date: Wed, 22 May 2024 21:48:06 -0700

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

Hi. It turns out you should use a `linux-libre` kernel same as you would in x64. If you’re running arm64 then it will still build and have all the features you expect.  I forgot I filed a bug for this but it’s resolved on my end now.

Best,

Elais
On May 22, 2024 at 05:36 -0700, Richard Sent <richard <at> freakingpenguin.com>, wrote:
> elais <at> fastmail.com writes:
>
> > Right now wireguard and nftable services are broken on the aarch64
> > kernel due to their respective kernel config parameters not being
> > added as modules or compiled into the kernel. I'm hesitant to call
> > this a bug but it does mean wireguard and nftables are unavailable. A
> > good chunk of iptables operations are missing as well. I don't have
> > much experience configuring a kernel but perhaps there's a way to
> > insure feature parity between the x86_64 and aarch64 kernels?
>
> I ran into this issue myself when using linux-libre-arm64-generic so
> it's still around. It can cause boot problems too depending on what
> exactly is missing.
>
> qemu-binfmt-service-type adds a file-system dependency on
> /proc/sys/fs/binfmt_misc, and requires the kernel to have
> CONFIG_BINFMT_MISC set. The 6.8-arm64.conf file does have
> CONFIG_BINFMT_MISC=m, but in the compiled kernel that option is unset.
> Ergo the file-system doesn't exist and Shepherd fails to finish
> initializing file systems.
>
> Seeing as how certain config changes are made to
> linux-libre-arm64-generic to improve device compatibility, I hope the
> differences can be minimized between the "vanilla" linux-libre and
> customized linux-libre-arm64-generic outside of device compatibility
> changes to reduce surprises like this.
>
> --
> Take it easy,
> Richard Sent
> Making my computer weirder one commit at a time.

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

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

From: Richard Sent <richard <at> freakingpenguin.com>
To: elais <at> fastmail.com
Cc: 61173 <at> debbugs.gnu.org
Subject: Re: bug#61173: Wireguard and NF Tables service broken on aarch64
Date: Thu, 23 May 2024 09:43:25 -0400

> Hi. It turns out you should use a `linux-libre` kernel same as you
> would in x64. If you’re running arm64 then it will still build and
> have all the features you expect. I forgot I filed a bug for this but
> it’s resolved on my end now.

Thanks for the tip. In my case I'm using a certain SBC and am in a
catch-22 situation, so I still think there's a bug here:

1. Use linux-libre so kernel config options for various Guix services
are set, but not have all the config options required to boot and run
the board.

  1. Adding config options with dependencies via customize-linux can
  best be described as a pain. [1]
  
2. Use linux-libre-arm64-generic to boot the board, but need to manually
enable additional config options for every service that requires them.

I can eventually either power through 1 or piece together the options I
need for 2, but this behavior is definitely surprising. I have three
proposed solutions in order of complexity:

1. The documentation for -generic kernels can be improved so their
meaning is clearer. -generic as in "as close to upstream as possible".
See [2].

2. Add more entries to %default-extra-linux-options using config options
required by various services.

3. A "linux-config-service" or similar could be created that other
services extend with their required kernel support, if any.

Of the 3, 3 seems the most elegant. It could easily complicate the
substitutability of the kernel however. Perhaps it could simply be a
system build-time check to confirm that the kernel's .config file does
in fact have those options set.

[1]: https://issues.guix.gnu.org/66355
[2]: https://issues.guix.gnu.org/43078#2

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

Previous Next

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