You are not logged in.
I recently installed wireguard on my Raspberry Pi running Devuan. I managed in the end but only after some troubled moments. The problem is that wireguard wants to install wireguard-dkms - which wants to install dkms - which depends on linux headers. It appears that the linux headers installed on the Pi as part of devuan_chimaera_4.0.0_armhf_rpi2.img.zip dont match the requirement, so apt starts to install one of the armmp header files from Debian together with the matching armmp linux-image.
At that point I stopped it and built the modules from source - which was what the dkms was all about and got everything running but getting rid of the partly installed armmp stuff did get scary.
That experience leaves me with two questions:-
1. I assume that the chimaera armhf-rpi2 image is targeted specifically at the Pi and includes some or all of the kernel optimisations included in the Raspberry Pi OS. As such it should run better than a generic kernel. Am I right? Does it include the optimisations?
2. What is the state of Debian's multi-platform linux-images? Are they the horse designed by committee, that became known as a camel? Can device trees encapsulate all of the differences between different boards using an arm processor or do we lose a lot as simplifications have to be made?
Opinions? Experiences? Facts?
Offline
Hi,
Thanks for your post.
I've also experienced the same issue with wireguard on chimaera on armel, armhf & arm64 with the latest Devuan Pi builds here https://arm-files.devuan.org/RaspberryPi%20Latest%20Builds/
Informally some time back, I did not experience this with daedalus latest builds.
I maintain these builds which are built here https://ci.free2air.net/job/Images/job/rpi-img-builder/ based on the toolchain work done by c0rnelius. So I can answer 1.
1. These builds optimize for each RPi hardware model and use RPi foundation kernel where mainline kernel is not yet available. The builds also include a minimal blend of drivers and userspace tools built to allow for a functional use of each models' hardware even in a desktop environment.
BTW the build of the pulled in kernel & RT dependencies fails & the extras do not install, and wireguard works on the existing kernel anyway. My *suspicion* is that wireguard under the older kernel was still immature and the issue is caused upstream(?) outdated kernel dependencies(?). I've been meaning to check with c0rnelius on this as I extensively use wireguard on these builds ...
Offline
The kernels used by the Devuan Pi Images are built from source, pulled from the Foundation github. The only changes I make to the build is a few modules ticked on here or there. Sometimes by request. The major difference between these builds and say a typical pi or debian kernel package, is we are using custom packaging. What the post and pre scripts of the deb package does during the install. Things like this.
What the wireguard package is trying to do is beyond my control and yes, these kernels support wireguard out of the box. My guess would be that Bullseye/Chimaera's default kernel doesn't have built in wireguard support, so the default packaging for this is pulling in garbage not needed in this use case.
Speaking of packaging. I have some thoughts on changing it, which would provide optional UEFI / Grub support for future PI images. Unfortunately the change would also render kernel upgrades on current Chimaera images not supported due to the changes.
The new boot layout would be as such and would come with a "use if you want too" u-boot.bin. This would support arm64, as well as arm to a degree.
Devuan GNU/Linux 4 (chimaera) 5.15.68 #1 Tue Sep 20 22:07:00 EDT 2022 aarch64
Raspberry Pi 3 Model B Plus Rev 1.3
== DISK
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p2 30G 1.0G 28G 4% /
/dev/mmcblk0p1 253M 72M 182M 29% /boot/efi
== NETWORK
Hostname: raspberrypi
Wireless: wlan0 UP 10.0.0.98
== SYSTEM
Processor: Cortex-A53 @ 1400MHz 45.6°C
Governor: performance
Memory: 910M 76M
Entropy: 256
Uptime: 21:01:20 up 6 min, 0 users, load average: 0.00, 0.05, 0.02
Last login: Thu Sep 22 20:57:51 2022 from 10.0.0.252
patrick@raspberrypi:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 29.7G 0 disk
├─mmcblk0p1 179:1 0 253M 0 part /boot/efi
└─mmcblk0p2 179:2 0 29.5G 0 part /
zram0 254:0 0 1G 0 disk [SWAP]
patrick@raspberrypi:~$ sudo blkid
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI" LABEL="EFI" UUID="E7A2-D2DC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="81fee591-01"
/dev/mmcblk0p2: LABEL="ROOTFS" UUID="3120022f-ddcc-40d3-85f8-5c598f5e6ee4" UUID_SUB="f4c78c7d-9cd5-42a9-8729-1d21709cb0c9" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="81fee591-02"
/dev/zram0: UUID="c29fee97-5599-47cf-9db5-54fcc1790ed4" TYPE="swap"
patrick@raspberrypi:~$ ls /boot
config-5.15.68 grub initrd.gz System.map-5.15.68
efi Image initrd.img-5.15.68 vmlinuz-5.15.68
patrick@raspberrypi:~$ ls /boot/efi
bcm2710-rpi-2-b.dtb cmdline.txt fixup_x.dat start_db.elf
bcm2710-rpi-3-b.dtb config.txt Image start.elf
bcm2710-rpi-3-b-plus.dtb COPYING.linux initrd.gz start_x.elf
bcm2710-rpi-cm3.dtb EFI kernel8.img u-boot.bin
bcm2710-rpi-zero-2.dtb fixup_cd.dat LICENCE.broadcom
bcm2710-rpi-zero-2-w.dtb fixup.dat overlays
bootcode.bin fixup_db.dat start_cd.elf
patrick@raspberrypi:~$ ls /boot/efi/EFI/BOOT
BOOTAA64.EFI
By editing the /boot/efi/config.txt, one could enable uefi support "grub".
kernel=u-boot.bin
If its not enabled, the boards just boot as normal.
Last edited by c0rnelius (2022-09-23 01:05:13)
Offline
Thank you both. Knowing the foundation is concrete makes for a much happier build!
Offline