You are not logged in.
Pages: 1
Note that for compatibility and usability of all RPi hardware interfaces, these images are not 'bare minimum', but a pragmatic blend that allows use of networking, bluetooth & video devices, etc. out-of-the-box across all RPi hardware models.
Thanks for sharing this Tobias.
It looks like the README file has reverted to an old copy.
I'll revert and update it with RPi Zero 2 info when I can.
You can find nightly builds of Devuan Pi for chimaera & daedalus at
https://arm-files.devuan.org/RaspberryP … %20Builds/
where the armhf builds also support RPi Zero 2s.
ZIP files because most RPi users expect and some image flashers only support ZIP compression.
Thanks again for sharing your experience.
@zapper the hardware specific, systemd-less devuan images will be faster than stock generic raspios, but for performance review, check out https://www.phoronix.com/review/raspber … benchmarks
@rgsidler To get up and running now, two options include taking the advice of @Camtaf for adding bcm2712.dtb or try the beta image I posted above which does boot on a RPi5.
On that beta image, I'm currently researching some some odd RPi5 specific behaviour with sddm & KDE rendering before adding images to the arm-files site (as it's likely to impact other desktops in some way).
@c0rnelius As always, thanks. The build for RPi5 is/will be built for bcm2712.
All the builds in https://arm-files.devuan.org/RaspberryP … %20Builds/ are built using the variant for the specific hardware and archictecture.
I'm currently updating the nightly build system for RPi images that are uploaded to https://arm-files.devuan.org/RaspberryP … %20Builds/ and this will include RPi5 images. I expect to include chimaera & daedalus RPi5 nightly builds in the next week or so.
For those who can't wait, there is a beta image here http://exaybachay.free2air.net/transfer … 6-1332.zip
Hi jas,
Thanks for posting. This is interesting work!
Further to golinux's post, there is
https://git.devuan.org/devuan/documenta … nvironment
which claims
The jenkins build pipeline uses git-buildpackage, pbuilder and cowbuilder. This ensures more flexible and reproducible builds in a cleaner environment than other build approaches.
Given the results of your work, likely there is something in the jenkins build pipeline that is losing reproducibility (or the claim is mistaken/out-of-date)?
What would really help are if Devuan published *.buildinfo files for their builds, has this been considered?
Best approach for this request would be to raise issue on Devuan gitea instance. Maybe initially on
https://git.devuan.org/devuan/documentation
to question/correct the statement quoted above?
Hi Michel,
From a raspberrypi forum moderator at https://forums.raspberrypi.com/viewtopi … 63#p441963 in 2013
Don't do it.
rpi-update was a quick hack made back in the day before the kernel and firmware was not properly packaged. apt-get upgrade is enough in 99% of the cases.
This thread also documents how to install rpi-update if you chose to ignore this advice.
For documentation on the on-going effort to bring UEFI to some RPi hardware platforms (RPi3/4), see https://github.com/pftf
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 ...
Hi Sponge,
Any Raspberry Pi (well, except a Pico ... for now) *can* run Devuan ... and XFCE, so it depends on your preference and further usage needs.
Here's a screenshot of Devuan running XFCE on a RPi0 https://twitter.com/AdamPeterBurns/stat … 5593417731
Most recent (beowulf, chimaera, daedalus) images compiled for all RPi hardware available here
Thanks for the tip!
Tried out, required yet a bit of extra work, but finally without systemd. Solely the WiFi adapter is not recognised. Anyone suffering from the same problem? Any hints?
Thanks to c0rnelius' builder work, Devuan Pi RPi4 images are located at arm-files.devuan.org.
At least for these images, the onboard WiFi interface is recognised, but you will need to configure
/etc/wpa_supplicant/wpa_supplicant.conf
for your WiFi network, or use the script mentioned in previous post.
Devuan Beowulf 3.1.0 Raspberry Pi SD card images tuned for RPi specific hardware variants have been added to https://arm-files.devuan.org/ for testing. Please refer to the updated README.txt for test image details.
This 64-bit gentoo-on-rpi-64bit project may help ...
(unfortunately looking for a new maintainer now)
Pages: 1