The officially official Devuan Forum!

You are not logged in.

#1 Re: Other Issues » [SOLVED] Excalibur minimal-live isos need something. » 2025-04-11 00:35:10

dzz

Most recent iso, unpacked and chrooted:

mv /lib /zzzlib
ln -s usr/lib lib
apt install --reinstall linux-image-6.12.21-amd64
apt install --reinstall live-boot

Initramfs was auto generated and manually copied to /live. Rebuilt iso, booted in qemu, seems OK!

Hazy memory of a ceres bootstrap a while ago, had to include usrmerge from the start. But I use mmdebstrap. Best check your initial bootstrap before adding to it.

Missing package, makes navigating in cli-only much easier: tree

btw: desktop-base 5.9 tested OK here (so far). Don't wait, get it from ceres.

#2 Re: Other Issues » [SOLVED] Excalibur minimal-live isos need something. » 2025-04-10 17:40:20

dzz

I don't mind testing these, time permitting, if it helps.  I have custom scripts ready to unpack, inspect, chroot and rebuild iso's. Also, they help me as test beds for some things I'm working on.

Neither of the images you posted have symlinks lib > usr/lib .. Others (bin, sbin, lib64) do. Therefore usrmerge was not done right. That explains the live-* errors and probably many others not yet noticed!

Newer live-boot I know installs to merged usr locations. Probably live-config also. I see there is a devuan live-config package but I not inspected that yet.

There is no actual /boot/initrd.img* on either iso, probably for the same reason.

#3 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-04-07 14:48:57

dzz

One issue: Can't set a different background in settings dialog from anywhere except /usr/share/images/desktop-base/ .. Most of us will want a custom background after install.

If I go to init 1, delete xfce4-desktop.xml from /etc/xdg/ and /home/devuan/ then back to init 2 then only what's in /usr/share/backgrounds/xfce/ is then available. So the xml in /etc/xdg/ must be doing something. No idea yet why other locations don't work.

BTW what's with the monster initrd.img?

#4 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-04-07 12:47:53

dzz

This worked here (qemu and usb), default backgroung is the one configured by /etc/alternatives:

1) Extract the iso

2) chroot the filesystem

3):

dpkg-divert --divert /usr/share/backgrounds/xfce/xfce-x.svg.dist --rename /usr/share/backgrounds/xfce/xfce-x.svg

ln -s /etc/alternatives/desktop-background /usr/share/backgrounds/xfce/xfce-x.svg

4) Exit chroot, rebuild the iso, boot it.

devuan@devuan:~$ dpkg -S /usr/share/backgrounds/xfce/xfce-x.svg
local diversion from: /usr/share/backgrounds/xfce/xfce-x.svg
local diversion to: /usr/share/backgrounds/xfce/xfce-x.svg.dist
xfdesktop4-data: /usr/share/backgrounds/xfce/xfce-x.svg

Maybe something similar could  go in preinst/prerm of desktop-base.

devuan@devuan:~$ ls -la /usr/share/backgrounds/xfce
total 2388
drwxr-xr-x 2 root root     292 Apr  7 11:33 .
drwxr-xr-x 3 root root      27 Apr  2 16:10 ..
-rw-r--r-- 1 root root  197011 Mar  3 01:34 xfce-blue.jpg
-rw-r--r-- 1 root root   28575 Mar  3 01:34 xfce-cp-dark.svg
-rw-r--r-- 1 root root   16972 Mar  3 01:34 xfce-flower.svg
-rw-r--r-- 1 root root  160740 Mar  3 01:34 xfce-leaves.svg
-rw-r--r-- 1 root root 1428420 Mar  3 01:34 xfce-light.svg
-rw-r--r-- 1 root root  263520 Mar  3 01:34 xfce-mouserace.svg
-rw-r--r-- 1 root root  322121 Mar  3 01:34 xfce-shapes.svg
-rw-r--r-- 1 root root    4904 Mar  3 01:34 xfce-stripes.svg
-rw-r--r-- 1 root root    6791 Mar  3 01:34 xfce-teal.svg
-rw-r--r-- 1 root root    4584 Mar  3 01:34 xfce-verticals.svg
lrwxrwxrwx 1 root root      36 Apr  7 11:33 xfce-x.svg -> /etc/alternatives/desktop-background
-rw-r--r-- 1 root root    9298 Mar  3 01:34 xfce-x.svg.dist
devuan@devuan:~$ 

#5 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-04-06 23:12:49

dzz

Unfortunately the xml file edits I made don't stick for a rebuilt iso. This affects not only Devuan:

https://gitlab.xfce.org/xfce/xfdesktop/-/issues/364

Seems xml files in /etc/xdg no longer work to set default backdrop since 4.19. Default desktop is set to /usr/share/backgrounds/xfce/xfce-x.svg unless compiled differently.

#6 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-04-05 20:07:17

dzz

The cursed rat..

Inserting between line 36 and 37 in /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml-devuan-sapphire:

  <property name="monitorLVDS-1" type="empty">
        <property name="workspace0" type="empty">
          <property name="last-image" type="string" value="/usr/share/images/desktop-base/desktop-background"/>
        </property>

Gives the desired result in a laptop usb boot. For a qemu session it needs to be "monitorVirtual-1". Maybe two entries will work for either. I don't know about other scenarios but will try on a tower case later.

#7 Re: Other Issues » Preliminary excalibur desktop-live isos need testing » 2025-03-25 13:38:38

dzz

Can you get into a tty from the live-session grub screen and edit with nano?

One way is to add "1" (no quotes) to the cmdline (boot menu). Enter root password "toor" then you can run nano. That done, enter "init 2" to continue normal boot.

Confirmed here, after taking out the line for plugin 7 (EDIT: line 22) in /etc/xdg/xfce4/panel/default.xml-devuan-sapphire the error is gone.

EDIT (more):

dpkg -S /etc/xdg/xfce4/panel/default.xml-devuan-sapphire
desktop-base: /etc/xdg/xfce4/panel/default.xml-devuan-sapphire

There's the cause! Also, the offending plugin is undefined in default.xml-deepsea ..

I can't see what default.xml.dpkg-new is there for, nothing seems to own it.

#8 Re: ARM Builds » refractasnapshot-base syslinux arm64 » 2025-03-16 16:19:21

dzz

I think the OP's original question is mostly answered, i.e. refractasnapshot can work on arm64 with some very minor modification. At least for efi-capable hardware. I don't agree that isolinux/syslinux is deprecated (yet), it remains a boot iso standard for bios/mbr hardware. Most such iso's also include grub for efi including refractasnapshot. But I have still more to add, re Refracta tools + arm64

We already have tested that another grub can boot the iso image via "loopback". Now I see that, although this machine seems unable to boot a dd'd isohybrid (pukes on loading the kernel), it can boot a usb with the snapshot live iso files simply copied.

Now I discover that refractainstaller can work on arm64 without modification! A live snapshot here was installed to a dedicated partition (not on the boot drive) and can be booted with, so far, no apparent problems. I chose to not do grub-install, I have grub manually configured elsewhere.

#9 Re: ARM Builds » refractasnapshot-base syslinux arm64 » 2025-03-07 19:33:25

dzz

(Apologies, off-topic): My previous script ssh edits were unnecessary. Whatever is in the script's ssh function (hence the final iso) gets changed by live-config's openssh-server on boot. Only way round that is, disable it (and deal with the security risk yourself) or make a custom live-config script to run after it. Or use a "live-hook" script which could go in /live.

I disabled it on the cmdline. In fact I disabled live-config altogether, for this build, none of it is needed.

Or chmod -x it, dpkg-divert it or delete it.. but.. I noticed in refractasnapshot-base_10.4.2 line 824>:

# Enable or disable password login through ssh for users (not root)
# Remove obsolete live-config file 
if [[ -e "$work_dir"/myfs/lib/live/config/1161-openssh-server ]] ; then
	rm -f "$work_dir"/myfs/lib/live/config/1161-openssh-server
fi

That won't work, it's actually "1160-openssh-server" in Daedalus>!

On topic, I added near the top of the mkefi function a test for arm64

# Detect if arch is arm64
arch=$(dpkg --print-architecture)
if [ "$arch" = "amd64" ]; then

	efi_files="x86_64-efi"
	efi_binary="bootx64.efi"

elif [ "$arch" = "arm64" ]; then
	efi_files="arm64-efi"
	efi_binary="bootaa64.efi"
fi

Then replaced further down all instances of x86_64-efi with ${efi_files} and bootx64.efi with ${efi_binary}.

It works and produces arm64-efi files and bootaa64.efi in the iso.
Not that it's of much use if your hardware can't boot an iso directly..

#10 Re: ARM Builds » refractasnapshot-base syslinux arm64 » 2025-03-06 19:01:52

dzz

Refractasnapshot (sort of) working here on arm64, a Raspberry Pi 3b+.

I recompiled refractasnapshot from source tarball. Far as I can see it doesn't need dependency on syslinux. Most (all?) of the syslinux files to be copied over are actually part of syslinux-common, that's for all arches. For Daedalus at least. Kept isolinux (not arch-specific) dependency.

I also disabled in the script, the part where ssh is modified, by making it a function which doesn't actually run. Not sure if that was actually necessary but first try, I couldn't ssh it and this machine is intended to be headless.

Only other changes were refractasnapshot.conf and snapshot_exclude.list to suit.

This pi has uefi emulation boot (not uboot) therefore I can use grub to boot the snapshot iso. And boot it does, given the right cmdline (note "nocomponents" to disable live-config). It networks automatically and accepts ssh.

Snip from /etc/grub.d/40_custom:

menuentry "Refractasnapshot ARM ISO boot" {
  set isofile="(hd0,2)/home/snapshot/snapshot.iso"
  loopback loop $isofile
  linux    (loop)/live/vmlinuz-6.13.0-rc7 boot=live findiso=/home/snapshot/snapshot.iso nocomponents 
  initrd   (loop)/live/initrd.img-6.13.0-rc7

}

How useful this all is is another matter, the machine itself first needs a working grub (maybe not extlinux) to boot an actual iso. The other snapshot files, outside /live, are probably redundant in this scenario. Anyway it's a good backup and potentially installable.

#11 Re: Hardware & System Configuration » Bluetooth support on laptop » 2025-03-05 22:21:29

dzz

Blueman installs here without pulseaudio. Makes life a lot simpler to connect bluetooth devices.  Do you have dbus-x11? There is a nasty alt dependency, default-dbus-session-bus .. failing that you could apt-pin pulseaudio to -1 and see what happens.

:~$ dpkg -l|egrep "pulse|blueman"
ii  apulse:amd64                           0.1.13-2                                amd64        PulseAudio emulation for ALSA
ii  blueman                                2.3.5-2+b1                              amd64        Graphical bluetooth manager
ii  libpulse-mainloop-glib0:amd64          16.1+dfsg1-2+b1                         amd64        PulseAudio client libraries (glib support)
ii  libpulse0:amd64                        16.1+dfsg1-2+b1                         amd64        PulseAudio client libraries
ii  pipewire-pulse                         0.3.65-3+deb12u1                        amd64        PipeWire PulseAudio daemon

Another laptop here, working bluetooth sound, uses bluez-alsa. It comes with no sysvinit script but one is here: https://github.com/joe-skb7/bluealsa-sysvinit ..

#12 Hardware & System Configuration » Raspberry Pi Devuan, multiboot, uefi, grub, no uboot, no image dd » 2025-02-27 19:07:54

dzz
Replies: 0

Some interesting experiments here with a raspberry pi 3b+ I was given. Some of this may well apply to other models. It's a different way from the usual dd of someone else's image, or compilation>dd from e.g. rpi-image-builder https://github.com/pyavitz/rpi-img-builder (thanks c0rnelius).

Early days so far and I didn't document everything very well.

The sd card was partitioned, using a Devuan system, with a small fat32 "boot" partition. To this was copied (not dd'd) the "virtual" uefi from here https://github.com/pftf/RPi3 .. Other files needed were EFI/boot/bootaa64.efi (simple to make and the bootloader found it automatically) and boot/grub with the usual (arm64) layout and a custom grub.cfg ..

The rest was formatted ext2 containing Devuan Daedalus loaded via mmdebstrap (superior IMO to debootstrap), then built up in chroot, complete with standard kernel.

On boot the grub menu appears and behaves normally. Everything seems to work including wireless. Bluetooth sound was more challenging, now working with alsa only + bluez-alsa. No xserver for now.

Interestingly I can chain the grub to another grub on a usb pen which (sdcard) grub always detects as /dev/sda. Other distributions are installed there, including another Daedalus and Ceres. Alternative kernels are installed there including a self-compiled mainline 6.13 (used default arm64 defconfig) and one compiled as a deb package using rpi-image-builder. Apparently 6.13 has improved pi support but they all work. A normal update-grub enables them all in the secondary grub menu.

Another revelation: I can boot a custom live image from iso. I never saw that done for arm64.

Anyone else here tried a pi setup like that? Multiboot with uefi, grub, no uboot, no image dd. Pure Devuan except in this case some maybe unnecessary firmware. Maybe you found something I missed or have better or different ideas. If something similar was posted here before either I never found it or it's way outdated.

#13 Re: Other Issues » [SOLVED] linux-image not updated » 2025-02-02 21:05:29

dzz

Then maybe some answers (after you checked for no held packages) from:

apt update && apt install linux-image-amd64

#14 Re: Other Issues » Is it possible to install a package permanently on Live ? » 2025-01-19 18:13:26

dzz

@SpongeBOB: Why not try msdos partition table?

R2u uses syslinux/isolinux,  it's more complex to get that working for gpt (and you don't need gpt)..

#15 Re: Other Issues » Is it possible to install a package permanently on Live ? » 2025-01-19 01:10:00

dzz

Is it possible to install a package / program permanently on a Live version ?

If the package is not so large or complex and doesn't call update-intramfs, you can use live-config's "live-hook" mechanism.

You can write a simple live-hook script (which could call e.g. dpkg -i /path/to/package or even another set of subscripts) and place it on any present media/disk, inside or outside the iso. It's automatically activated via the cmdline.

man live-config

is a learning curve but very well documented.

The package would of course need all it's deps sorted first. Script those in order and it should work.

Note the need to use wget-style absolute paths (file:///whatever), that's the awkward one.

Works here..

EDIT: If you use full persistence also, maybe you can then disable your hook script, since it will be already merged into the live system.. ?

#16 Re: Packaging for Devuan » yt-dlp is very outdated » 2024-10-18 19:05:12

dzz

If you install yt-dlp as Ron suggests, the update option is already built-in. As root, simply:

yt-dlp -U

If you installed it from the repos,  that option is disabled. An error will show and it can only list the installed and available versions.

#17 Re: Other Issues » [SOLVED] Can't connect to repos » 2024-02-15 14:31:01

dzz

I run dnscrypt-proxy and choose resolvers list carefully (except when a trusted VPN is running). Rightly or wrongly, I view a corporate provider's DNS service as potentially unreliable *and* a security risk (surveillance, logging, passing data to who knows who)..

I use Ceres and update most days but never seen that problem before. Except yesterday..

I maintain a friend's machines which run chimaera (and use provider DNS):

Temporary failure resolving 'deb.devuan.org'

Immediately after editing resolv.conf with a known good alternative DNS server, all was well.

Later, at my own machine, again no problem. Why is that?

#18 Re: DIY » [SOLVED] GNU/Linux laptop as router, vpn router, or wifi repeater » 2024-02-15 13:15:49

dzz

Thanks GNUser for this thread. Useful for me as I have only wireless here (in some areas only) from a neighbour's router.

It seems create_ap is no longer maintained, so let's not bother with it.

True but its been forked, and maintained (in the last 2 months) elsewhere:

https://github.com/lakinduakash/linux-wifi-hotspot

There is a deb package with python-based GUI (but usable from cli only). Or build your own from the source, as did I. Working here, tested only on ceres so far, at least as wireless repeater. I'm using network-manager, that seems to be detected and not permanantly interfered with. I now have optional connection in a previously dead zone via another Devuan box.

Using 2x cheap usb wireless adapters, couldnt get either to work alone.

You might want to disable automatic start of dnsmasq (sysv-rc-conf) unless you got reason not to.

I will try your more minimal script at some point.

#19 Re: Other Issues » Seriously? » 2023-11-27 12:29:11

dzz

No bug here, we just needed to watch the warnings and wait. Network-manager depends on libnm0 of the same version .. libnm0 was to be upgraded to 1.44.2-5 (at 23-11-22) but it seems network-manager 1.44.2-5 wasn't available till shortly afterwards. From my log:

The following packages will be REMOVED:
  network-manager network-manager-gnome

#SNIP

Do you want to continue? [Y/n]

#20 Re: Desktop and Multimedia » dnscrypt-proxy settings » 2023-11-05 13:01:58

dzz

Seems something else is using 127.0.2.1:53 (maybe another instance of dnscrypt-proxy?) You could investigate using lsof and ps ..

Or just change 127.0.2.1:53 to 127.0.0.1:53, that's the default anyway. I only use 127.0.2.1 from an older release custom config, which simply works here. Remember to update network-manager configs also, if you use that. Should all be good after a reboot.

#21 Re: Desktop and Multimedia » dnscrypt-proxy settings » 2023-11-04 13:55:14

dzz

Working (for me) /etc/dnscrypt-proxy/dnscrypt-proxy.toml :

# Empty listen_addresses to use systemd socket activation
listen_addresses = ['127.0.2.1:53']
server_names = ['cloudflare']

[query_log]
  file = '/var/log/dnscrypt-proxy/query.log'

[nx_log]
  file = '/var/log/dnscrypt-proxy/nx.log'

[sources]
  [sources.'public-resolvers']
  url = 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md'
  cache_file = '/var/cache/dnscrypt-proxy/public-resolvers.md'
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  refresh_delay = 72
  prefix = ''

** I use network-manager. In ipv4 settings, "Method" is "Automatic (DHCP) addresses only" and "DNS servers" is "127.0.2.1" **

I have used https://ipleak.net/ to test but can't verify their reliability. Shows cloudfare dns.

root@ceres:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 127.0.2.1

#22 Re: Desktop and Multimedia » [SOLVED] Bluetooth headphone not showing in PulseAudio/pavucontrol » 2023-02-04 15:10:32

dzz

You may also need to create ~/.asoundrc wih something like this (change "Port" and device "mac address" to suit.:

pcm.Port { 

	type bluealsa
	device "77:20:1E:FE:4E:E4"
	profile "a2dp"
	hint  { show on description "Port" }
}

I used bluez-alsa for a while with reasonable success but now finding pipewire more reliable. You can have both installed but if you try pipewire  bluealsa service should stopped and disabled in sysv-rc-conf..

blueman-applet seems the easiest way to search available devices, get info, set up.  Or bluetoothctl in a terminal.  Setup sequence is trust>pair>connect .. good luck..

#23 Re: Desktop and Multimedia » [SOLVED] Bluetooth headphone not showing in PulseAudio/pavucontrol » 2023-02-01 22:16:57

dzz

You don't need pulseaudio and should uninstall if you try this.

Re bluez-alsa: it's only in unstable and not so new. And no syvinit script.
https://dev1galaxy.org/viewtopic.php?id=4612

I made updated packages for chimaera with sysvinit script and posted here (please install libasound2-plugin-bluez first):
https://exegnulinux.net/apt/pool/main/b … _amd64.deb
https://exegnulinux.net/apt/pool/main/b … _amd64.deb

A better way might be with pipewire:
https://dev1galaxy.org/viewtopic.php?id=5385

BT sound working here both ways.

#24 Re: Desktop and Multimedia » Pipewire » 2023-01-16 17:50:56

dzz

Thanks all here for the info on setting up pipewire for chimaera. Tried and failed till now.  Although  bluez-alsa does work for my BT speaker. I don't use pulse-audio.

I first installed the packages as described by Devarch. Note these packages actually get installed as deps: pipewire-bin libpipewire-0.3-modules libwireplumber-0.4-0 libpipewire-0.3-0 . These backports are almost up to current unstable versions.

With the latest packages, everything subsequently (at least after reboot) worked "out of the box" on my Toshiba laptop. No file copying no other configurations. The Debian wiki is outdated. The BT speaker is up and running, including firefox streams which failed with bluez-alsa.

Thanks HoaS for the start script. I adapted it quite a bit because I want to start/stop pipewire manually. Also, sometimes a restart is needed (here) to fix an occasional bt connection drop out. And I don't want processes not in use autostarting (I disabled also /etc/xdg/autostart/blueman.desktop).

Placed in ~/bin/ and called from a desktop launcher:

#!/bin/bash

# Script name: bluestart
# Place in ~/bin and make a desktop launcher 
# Execute "bluestart stop" to just stop pipewire and related processes without restarting.

# (in case you used "stop" parameter)
MODE="$1"

# You probably need to restart your system mixer to register/deregister the pipewire device.
# Edit (or comment) the next line to suit whatever your DE uses:
MIXER=kmix

# Don't run this as root!
if [ $EUID -eq 0 ]; then exit 1; fi

restart_mixer () {

	if [ -n "$MIXER" ]; then

		pkill -u "$USER" "$MIXER" >/dev/null 2>&1
		$MIXER &
	fi
}

stop_pipewire () {

pkill -u "$USER" pipewire-pulse >/dev/null 2>&1

pkill -u "$USER" wireplumber >/dev/null 2>&1

pkill -u "$USER" pipewire >/dev/null 2>&1

killall blueman-applet blueman-tray blueman-mechanism 2>/dev/null

# delete blueman stat files in ~/.config
for i in $(ls ~/.config|grep blueman); do rm -f $i; done

}

stop_pipewire

if [ "$MODE" = "stop" ]; then
	sleep 3
	restart_mixer
	exit 0
fi

pipewire &

until pgrep -f pipewire >/dev/null 2>&1 ; do
   sleep 1
done

wireplumber &

pipewire-pulse &

blueman-applet &

sleep 2

restart_mixer

Hope that helps someone..

#25 Re: Other Issues » [SOLVED] Exe GNU/Linux (Chimaera 4.0 ) sysv-rc-conf has a life of its own. » 2023-01-01 19:09:28

dzz

Sorted! Please mark as "solved".. Note it's actually /etc/init.d/rc2.d/ that's relevant (unless you manually changed default runlevel from 2). Disabled you will see K01cups, or enabled, S01cups..

root@exegnu:~# ls /etc/rc2.d|grep cups
K01cups

I did not touch the eudev service at all.

Please don't, for sure will break things! And I hope you're not running konqueror as root..

Board footer

Forum Software