× nftables.service - nftables
Loaded: loaded (/lib/systemd/system/nftables.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Sat 2023-08-05 18:34:37 CEST; 1s ago
Docs: man:nft(8)
http://wiki.nftables.org
Process: 3577 ExecStart=/usr/sbin/nft -f /etc/nftables.conf (code=exited, status=1/FAILURE)
Main PID: 3577 (code=exited, status=1/FAILURE)
CPU: 50ms
Aug 05 18:34:37 starfive nft[3577]: ^^^^^
Aug 05 18:34:37 starfive nft[3577]: /etc/nftables.conf:9:8-14: Error: Could not process rule: Operation not supported
Aug 05 18:34:37 starfive nft[3577]: chain forward {
Aug 05 18:34:37 starfive nft[3577]: ^^^^^^^
Aug 05 18:34:37 starfive nft[3577]: /etc/nftables.conf:12:8-13: Error: Could not process rule: Operation not supported
Aug 05 18:34:37 starfive nft[3577]: chain output {
Aug 05 18:34:37 starfive nft[3577]: ^^^^^^
Aug 05 18:34:37 starfive systemd[1]: nftables.service: Main process exited, code=exited, status=1/FAILURE
Aug 05 18:34:37 starfive systemd[1]: nftables.service: Failed with result 'exit-code'.
Aug 05 18:34:37 starfive systemd[1]: Failed to start nftables.
The StarFive Debian 202306 image is an engineering release, the kernel enough to bring the board up to allow work for upstreaming to the Linux kernel. And because of that it does not have all the bells and whistles, it is a longterm 5.15 kernel with enough modules enabled to support the unique hardware of the board.
An engineering release is intended to bring up the hardware for software developers to be able to work. Adding ALL modules would just slow the speed of test builds. Even though it may only add a few minutes there or seconds here to each test build, that cumulatively will all add up to a substantial amount of wasted time which ultimately will slow down how fast the unique features are upstreamed. <<== StarFive have been doing totally amazing work, in upstreaming.
If you want more bells and whistles but do not mind loosing hardware accelerated GUI then look at the current alternatives (At least until Debian Trixie, which will be the very first official Debian release to support for ANY RISC-V hardware). Or else just add the modules you want yourself to the existing kernel (VisionFive2->Software Document->SDK Quick Start Guide).
So you want to say that for the next two years till Debian Trixie, the person, who wants to use the Vision Five 2 e.g. as gateway or router or just have a plain firewall or Ethernet over USB for an additional network interface is not supported? Then, who is the users for this platform for the next two years? For the few crappy things one can do with the provided kernel, one does not need a RISC-V platform. The Raspberry Pi OS had not routing functions in the kernel, but at least the firewall was working. This world really needs a lesson it never forgets…
You could use the openSUSE Tumbleweed nightly builds if you do not mind not having a GUI and configure that as a router. Or armbian. Or ubuntu server. Or …
There are lots of options, it IS a new architecture, so do not expect the same level of OS support as hardware that has been about for 30+ years. RISC-V is getting supported faster than any other new architecture in the history of computing. But it does not happen overnight, temper your expectations closer to reality.
The Raspberry Pi has not upstreamed any of their custom kernel modifications, they maintain their own independent kernel which pulls in changes form the mainline kernel.
And StarFive is upstreaming its modifications and kernel into the mainstream Debian → in two years? That seems to me not a lack of support or a catching up a new platform, but a serious attack on open-source culture. As far as i know the RISC-V platform was very much anticipated. The hardware on the Vision Five is pretty much out-of-the-box standard and the gpu is supported nicely. A firewall is an absolute necessity for even the most basic system. This is a clear case of completely wicked obstruction to prevent the Vision Five 2 get a good reputation, that is all.
You have bought a Formula 1 vehicle and complain that there is no room in the vehicle for your children, mother-in-law and dog and that you cannot attach your camping trailer. I’m sorry, but you are not fair in your statement.
Debian is just one Linux Distribution. I’m sure that StarFive is not upstreaming to Debian, they would typically upstream changes to the Linux kernel and some software applications. Upstreaming to only one distribution, would make sense if that was the only distribution that you ever wanted to run on the hardware. There are many Linux distributions, not all are based on Debian.
Your options today are use any Linux Distribution (with support for RISC-V), that has the exact functionality that you want/need, with the custom starfive 5.15 longterm support kernel.
Or speed reading the accepted upstreamed hardware, and kernel versions, (minimum system - 6.4), SDIO/EMMC(6.3), GMAC (6.4), USB (6.5), Power Management IC (6.5) and looking at kernel.org you might possibly be able to get just about enough functionality out of any Linux Distribution for RISC-V using the current stable: 6.4.8 kernel, as long as you do not expect GUI support, and some other things not to be available (yet).
I found the most recent custom starfive longterm support kernel 5.15 as included in Debian-202306 image to fail to start nftables and i also found the most recent custom starfive longterm support kernel 5.15 as included in Debian-202306 image to not support USB subsystem, especially Ethernet over USB module driver…
The kernel probably supports exactly what you want without any software modifications, but no one has tested it all on a RISC-V architecture (because no one owns every brand/make and model of hardware - and fully testing each and every feature of hardware, or software, takes a lot of time), just re-compile the kernel and/or add the modules you want/need. You can complain all you want about an “engineering” release of a kernel provided to help coders not supporting very many modules outside of the core hardware, but that is why it exists to help coders write and test source code for software and hardware. I’m sure that StarFive could upload a larger image file with untested and possibly broken modules that at bare minimum compile but do not necessarily work as expected, that would also be frustrating.
No, they don’t need nftables on the early stage target system they are developing for, they only need nftables on the workstations and servers they are working with.
I would add that this is Linux, not a commercial ready-made product: you are supposed to experiment and do things yourself.
You must add the drivers that you want in the kernel, it is the way it is supposed to work.
I wanted some bluetooth and other drivers and added them myself.
The developers have been gracious enough to explain how to recompile the kernel.
Personally I don’t want the firewall modules in the kernel, because I don’t plan to run VMs on the boards and won’t expose it directly to the internet, so I prefer speed to unused functions.
You are mixing things up here a little bit. The system firewall “nftables” is an essential part of the linux kernel for many useful and common applications. As the people like me, who are after being a long-term user of GNU/Debian Linux not so experienced in compiling a working kernel themselves, less even of being a kernel developer themselves, have not so much choice than accepting the upstream kernel provided by StarFive, it seems to be a legitimate request to me, to have a fully functional kernel including routing and USB subsystems support as well as the kernel firewall. Indeed, maybe a lot of people are expecting to be able to install their very own unrestricted firmware in the QSPI flash of the Vision Five 2 in order to make its hardware constellation (2 x Gigabit Ethernet, 4 x USB 3, M.2, eMMC, SD, GPU, …) completely available to free computing, otherwise there would not be so much point in switching from ARM to RISC-V at all i guess.
That time in 2020 that was still RaspBian. In 2022 i tried for a months time without success to get my Raspberry Pi 4 4B set up and working as a router/gateway. Whereas the nftables firewall was working on Raspberry Pi OS that time, ip packet forwarding was not working on that kernel. Thus, it seems, it is taken care to render such SoC systems incapable of serving as servers, firewalls, routers and gateways. With the international open RISC-V standard coming to the home user, the question poses itself, whether and for how long the trend will continue for such obstructions of most basic and elementary functions of linux-driven SoC computers.
