Dev1 Galaxy Forum / [SOLVED] Apt demands armmp dependencies in place of RPi kernel images.

Re: [SOLVED] Apt demands armmp dependencies in place of RPi kernel images.

dummy@example.com (EnglishMohican) — Sun, 25 Sep 2022 08:42:52 +0000

Thank you both. Knowing the foundation is concrete makes for a much happier build!

Re: [SOLVED] Apt demands armmp dependencies in place of RPi kernel images.

dummy@example.com (c0rnelius) — Thu, 22 Sep 2022 20:00:32 +0000

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.

Re: [SOLVED] Apt demands armmp dependencies in place of RPi kernel images.

dummy@example.com (vortex) — Thu, 22 Sep 2022 07:16:16 +0000

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

[SOLVED] Apt demands armmp dependencies in place of RPi kernel images.

dummy@example.com (EnglishMohican) — Fri, 16 Sep 2022 19:48:07 +0000

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?