Wireguard and NF Tables service broken on aarch64

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?

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.

elais@fastmail.com writes:

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.

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:

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.