You are not logged in.
Pages: 1
I just got Devuan Daedalus running on a RasbberryPi Compute module 5 with a NVMe disk using the IO board and IO case - it's more or less a RaspberryPi 5 in a differently shaped metal case; I like the form factor.
The compute module has eMMC so an SD card can't be used, to get a disk image into it you need to use rpiboot from https://github.com/raspberrypi/usbboot/ I built it from source using the instructions in the ReadMe.
rpiboot allows you to set the boot config or to make it appear as a Mass storage device. To turn it into a Mass storage device run:
./rpiboot -d mass-storage-gadget64Fit a shorting link across the two "disable eMMC Boot" pins on J2 and connect the USB C connector on the module to your computer when the display shows:
Waiting for BCM2835/6/7/2711/2712
This uploads a minimal linux image to change the function of the USB C port. It doesn't seem to like USB hubs, the first time I tried that it didn't work. You can check if it's worked by running
lsblk -p Mine showed:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
/dev/sda 8:0 0 223.6G 0 disk
\u251c\u2500/dev/sda1 8:1 0 23.3G 0 part /
\u251c\u2500/dev/sda2 8:2 0 1K 0 part
\u251c\u2500/dev/sda5 8:5 0 9.3G 0 part /var
\u251c\u2500/dev/sda6 8:6 0 976M 0 part [SWAP]
\u251c\u2500/dev/sda7 8:7 0 1.9G 0 part /tmp
\u2514\u2500/dev/sda8 8:8 0 188.2G 0 part /home
/dev/sdb 8:16 1 465.8G 0 disk
/dev/sdc 8:32 1 29.1G 0 disk
In that list /dev/sdb is the NVMe drive attached to the compute module and /dev/sdc is the eMMC. It's likely to be different on your machine, check very carefully!
I copied the rpi-5-devuan-daedalus-6.12.55-arm64-ext4-2025-10-29-0209.img file directly to the NVMe using a command like this:
dd if=raw_os_image.img of=/dev/sdX bs=4MiBI also changed the boot order using rpiboot by editing recovery5/boot.conf on my computer and running
cd recovery5/
./update-pieeprom.sh
../rpiboot -d .Details available from: https://www.raspberrypi.com/documentati … figuration
After all that removing the link across the "disable eMMC Boot" pins and powering up using the normal USB C power supply got me a running Devuan. Login as root:toor.
The welcome screen says to run menu-config to set up the basics like kernel config, hostname, network, etc.
After that I regenerated all the host ssh keys to make sure they're unique to me
rm /etc/ssh/ssh_host_*
ssh-keygen -AI also renamed the default "devuan" user. Note this won't work if "devuan" is currently logged in. First I needed a new group:
groupadd myname To change the username, home directory & group name:
usermod --login myname --move-home --gid myname --home /home/myname devuan You can also change the full name associated with the account using:
chfn -f "New Fullname" myname And, of course, set a new password using either
passwd mynameif running as root or just
passwdfor the current account.
And then on to apt to configure everything else!
I've not tried mounting the whole of home, the faq in
/usr/share/doc/libpam-mount/faq.txt.gz says that
Big desktop environments as the aforementioned make use of locking,
symbolic links, and potentially local sockets (UNIX sockets).
If the filesystem and/or the remote server do not support these,
error messages or lockups may ensue.
it also suggests that for KDE you can set it up to use /tmp for its special files.
I'd have to guess you're seeing something like that but I don't know how you'd work around any other problems.
Install the libpam_mount and libpam-mount-bin packages then edit the primary configuration file: /etc/security/pam_mount.conf.xml
to add
<volume
fstype="cifs"
server="192.168.26.1"
path="%(USER)"
mountpoint="~/Volumes/servername/"
uid="1000-29999"
/>That's from my config, I make a a share of my server available in my home directory (under Volumes/servername/). You don't need to save your password anywhere (a bad idea!) as PAM does the right thing when you login to the desktop etc. it uses the same username & password for the share and login as for the desktop and works for any normal user. It can also be made to work for remote logins over ssh.
You might need to check if replacing the whole of your home directory works without confusing anything else.
It's been a while since I installed Devuan on my XU4 but the good news is that it does work! I'm running Beowulf but with the latest kernel from backports - the last couple of versions of that seem to have finally solved the USB problems I was having.
How I got there is a bit of a memory test as it was a while ago. I ended up building u-boot from Debian along with the Odroid specific bits and tftp booting the Debian installer over the LAN. Things that helped at the time were setting net.ifnames=0 in the kernel cmdline to get sensible interface names. Having a serial interface to get a console (and a lot of patience) helped! Once I'd got Debian running I converted to Devuan.
I don't know if there's a current image available, I can't see anything in
https://pkgmaster.devuan.org/devuan/dis … nt/images/
I didn't have an older Pi to modify the Devuan image so I used qemu and chroot on a x86 PC with instructions from https://wiki.debian.org/RaspberryPi/qemu-user-static. Mounting the Devuan image and /dev, /proc, /sys & /dev/pts and chrooting in lets you run apt as if you were running on the Pi itself :-)
To get around the problem of the vc4 module and to get the second monitor output to work you need Mesa 19.1.0 or later, that means an upgrade to beowulf and fixing a few dependancies.
I downloaded libgl1-mesa-dri_19.2.0~rc1-1~bpo10+1~rpt3_armhf.deb
libglapi-mesa_19.2.0~rc1-1~bpo10+1~rpt3_armhf.deb and
libglx-mesa0_19.2.0~rc1-1~bpo10+1~rpt3_armhf.deb from http://archive.raspberrypi.org/debian/pool/main/m/mesa/
And to get those working I needed to install binfmt-support, libpfm4 and some other bits that aren't available in the Devuan archives yet:
libllvm8_8.0.1-3~bpo10+1_armhf.deb
llvm-8_8.0.1-3~bpo10+1_armhf.deb
llvm-8-runtime_8.0.1-3~bpo10+1_armhf.deb from
http://ftp.nl.debian.org/debian/pool/ma … olchain-8/
Finally in /boot/config.txt I commented out dtoverlay=vc4-kms-v3d and added:
dtoverlay=vc4-fkms-v3d
max_framebuffers=2So far beowulf seems to be running well and I have Xfce running across two 1600x1200 monitors :-)
The only other problem I had was that the HDMI 1 output on the Pi 4 doesn't seem to be as strong as HDMI 0 and really didn't like the long cable I had.
Thanks to therion23
Hi,
Thanks for the reply. Re-flashing with the release version of Ascii doesn't seem to have made any difference. Running usb-devices gives:
root@devuan:~# usb-devices
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=04.14
S: Manufacturer=Linux 4.14.48 ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=12110000.usb
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 3
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev=04.14
S: Manufacturer=Linux 4.14.48 ohci_hcd
S: Product=USB Host Controller
S: SerialNumber=12120000.usb
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=04.14
S: Manufacturer=Linux 4.14.48 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.2.auto
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 1
D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev=04.14
S: Manufacturer=Linux 4.14.48 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.2.auto
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 2
D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=05e3 ProdID=0616 Rev=22.23
S: Manufacturer=GenesysLogic
S: Product=USB3.0 Hub
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=04.14
S: Manufacturer=Linux 4.14.48 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.5.auto
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 2
P: Vendor=0bda ProdID=8153 Rev=30.00
S: Manufacturer=Realtek
S: Product=USB 10/100/1000 LAN
S: SerialNumber=000001000000
C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=180mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=00 Driver=r8152
T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 1
D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev=04.14
S: Manufacturer=Linux 4.14.48 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.5.auto
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hubI think that still shows the network interface appearing on the 480M Bus05 rather than the 5000M Bus06.
The board is in a custom case but it's certainly not been mangled. I did boot a Debian image and the network came up with no problems so I was assuming that the hardware was ok.
I think it's a Devuan problem rather than hardware but I could be wrong. My guess is that something is mixed up in the device tree blob (the bit of the bootloader that defines the hardware configuration) but I've not had the time to read up on that to figure out how that bit works.
ifconfig only shows the loopback interface:
root@devuan:~# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0and trying to bring up the interface gives:
root@devuan:~# ifup eth0
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Cannot find device "eth0"
Failed to get interface index: No such device
If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug. These pages explain the proper
process and the information we find helpful for debugging..
exiting.
ifup: failed to bring up eth0It's the lack of the interface that makes me suspect that the USB is confused.
I'm having a problem getting Devuan ASCII running on an Odroid XU4 (http://www.hardkernel.com/main/products … 3452239825), I'm not sure if I've missed something obvious or if there's a problem with the image - I've tried the ASCII beta and the RC.
I've copied the image to an SD card and it boots but the network interface doesn't come up.
As far as I can tell something is getting confused with the USB and making the network interface appear on the wrong bus / wrong speed interface:
root@devuan:~# lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480MIf I boot a Debian image and do the same thing the network works and the interface appears under the high speed Bus 06 entry rather than the 480M Bus 05 entry.
When running the Devuan ASCII image I tried plugging in other USB devices to see if I can get something to work, the USB2 interface responds with a "New USB device found" message on the console, the upper USB3 port doesn't show any sign of recognising that something has been connected and the lower USB3 port gave an error when I plugged in a disk:
[ 141.349656] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?
[ 142.319857] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?
[ 143.279971] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?
[ 144.241201] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?
[ 144.248239] usb 3-1: USB disconnect, device number 2
[ 148.321980] usb usb3-port1: connect-debounce failedThe gigabit network interface is the third USB3 device.
I'm connecting to the XU4 with a serial adapter connected to the UART.
Is it something I've done or is it a bug?
If there's any other info that would help let me know.
Thanks.
Pages: 1