bug#61173: Wireguard and NF Tables service broken on aarch64

bug#61173: Wireguard and NF Tables service broken on aarch64

[elais]

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

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?

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

bug#61173: Wireguard and NF Tables service broken on aarch64

[elais]

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

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.

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

bug#61173: Wireguard and NF Tables service broken on aarch64

[Richard Sent]

elais@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.

bug#61173: Wireguard and NF Tables service broken on aarch64

[elais]

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

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@freakingpenguin.com>, wrote:
> elais@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.

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

bug#61173: Wireguard and NF Tables service broken on aarch64

[Richard Sent]

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