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.

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:~$ 

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.

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.

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.

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

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.

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

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.

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.

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

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