kernel-related question

rbit · 2022-11-25 19:16:14

I've been reading a few topics on this forum, but haven't yet come across a satisfactory answer.

Here's my situation:
I've got a raspberry pi 3b+. I originally used the devuan ascii image on sd card, later moved to external usb drive. After running this setup for a few years, I finally (today) decided to dist-upgrade to beowulf, and then to chimaera. It all went pretty smoothly. The one issue that I've noticed during startup now is that iptables refuses to load the rules I have stored in a script. An example rule is: iptables -A INPUT -s 1.2.3.4 -j DROP and the message that was returned on beowulf is: iptables: Invalid argument. Run `dmesg' for more information.. dmesg contains nothing useful or related to the iptables command. On chimaera the error is: iptables v1.8.7 (nf_tables): Could not fetch rule set generation id: Invalid argument.

From some internet searching, I believe that the problem is due to an outdated kernel. uname -a result is: Linux devuan 4.16.14-v8+ #1 SMP PREEMPT Tue Jun 5 18:50:10 CEST 2018 aarch64 GNU/Linux.

I then tried: apt install linux-image-arm64 which proceeded to download and install linux-image-5.10.0-19-arm64_5.10.149-2_arm64.deb
This did create the files in /boot, but they were not loaded upon a system reboot, it's still on 4.16.14-v8+.

I *believe* (but may be mistaken) that the newer rpi images contain a newer kernel. Could I download the chimaera image, and copy the contents of its /boot to my /boot in order to load a newer kernel? Or is there another way to perform a kernel upgrade on a running system? Any help is greatly appreciated.

alexkemp · 2022-11-25 20:33:39

By the sound of it you want backports. Here my setup but remember, YMMV:

$ cat /etc/apt/sources.list | head -8
deb http://deb.devuan.org/merged chimaera main non-free contrib
deb http://deb.devuan.org/merged chimaera-security main non-free contrib
deb http://deb.devuan.org/merged chimaera-updates main non-free contrib
# changed next line following https://dev1galaxy.org/viewtopic.php?pid=38033#p38033
# deb http://deb.devuan.org/devuan chimaera-proposed-updates main non-free contrib
deb http://deb.devuan.org/merged chimaera-proposed-updates main non-free contrib
deb http://deb.devuan.org/merged chimaera-backports main non-free contrib

$ uname -a
Linux ng3 6.0.0-0.deb11.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.3-1~bpo11+1 (2022-10-29) x86_64 GNU/Linux

ralph.ronnquist · 2022-11-25 22:55:07

ARM machines are typically different in their bootup for different machine types. I'm not sure exactly how your /boot looks but most likely there is a file there that identifies the kernel to boot and its initrd. It might be enough to edit that file for your new kernel and initrd.

(Possibly there is some name limitations which would force you to copy your kernel+initrd into existing names)

The newest chimaera iso for rpi3 seem to have a file /boot/config.txt identifying its kernel, and that boot kernel is named kernel8. It is an gunzip of the accompanying vmlinuz-5.10.110.

rbit · 2022-11-26 02:10:27

OK, here's where I'm at now.

First, I edited /boot/config.txt and attempted to change the kernel line to the version that I had installed via apt as follows: kernel=vmlinuz-5.10.0-19-arm64
The "file" command reported both files (the previous kernel8.img and the vmlinuz-5.10.0-19-arm64) as "Linux kernel ARM64 boot executable Image, little-endian, 4K pages" -- so I thought it just might work.
When I rebooted, the system was stuck at the initial color "rainbow" screen.

I resized my boot partition (it was 128MB on the ascii image, but 256MB on the chimaera image). I downloaded the file rpi-3-devuan-chimaera-5.10.110-arm64-ext4-2022-11-25.zip from the page https://arm-files.devuan.org/RaspberryPi%20Latest%20Builds/ ... then using dd I overwrote my boot partition with the one from that image. At first it would not complete the boot due to missing partition (I forgot to edit cmdline.txt). After I got that straightened out, it did boot into Linux devuan 5.10.110 #1 SMP PREEMPT Fri Nov 25 00:43:14 CET 2022 aarch64 GNU/Linux

So I guess that part is solved, sort of. I was hoping there would be a simpler way to just upgrade the kernel (like it works in amd64).

Also, upgrading the kernel didn't even fix the iptables problem.

# iptables -A INPUT -s 1.2.3.4 -j DROP
iptables/1.8.7 Failed to initialize nft: Protocol not supported
# iptables -V
iptables/1.8.7 Failed to initialize nft: Protocol not supported

I think I've got the solution for this, though.
I found on https://superuser.com/questions/1480986/iptables-1-8-2-failed-to-initialize-nft-protocol-not-supported:

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

I had to copy the /lib/modules/5.10.110 from the latest image file to my live system, too (which of course I forgot to do previously).

Now, iptables seems to be functioning correctly.

The only question remaining is, whether or not there's a simpler kernel upgrade process. At least things are working again, and it is possible to upgrade kernel, just a bit more time-consuming than I'm used to :-)

ralph.ronnquist · 2022-11-26 05:33:56

The first editing could have worked, but the kernel to load need to be gunzip-ed first; make it a vmlinx instead of vmlinz.

I.e., gunzip the kernel and edit config.txt.

The officially official Devuan Forum!

#1 2022-11-25 19:16:14

kernel-related question

#2 2022-11-25 20:33:39

Re: kernel-related question

#3 2022-11-25 22:55:07

Re: kernel-related question

#4 2022-11-26 02:10:27

Re: kernel-related question

#5 2022-11-26 05:33:56

Re: kernel-related question

Board footer