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