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

@OP: Please note Devuan default runlevel is 2 (you only change that if you got a reason)

It is! (and you can generate any others needed and choose your system default)

root@exegnu:~# dpkg-reconfigure locales
Generating locales (this might take a while)...
  de_DE.UTF-8... done
  en_GB.UTF-8... done
  en_US.UTF-8... done
  es_ES.UTF-8... done
  fr_FR.UTF-8... done
  it_IT.UTF-8... done
  pl_PL.UTF-8... done
  pt_PT.UTF-8... done
Generation complete.

? It boots here with or without "apparmor=0" ..

I always found "findiso" simpler to configure than "fromiso".. here's my grub.d/40_custom entry:

menuentry "devuan5 preview" {
	insmod part_gpt
	set isofile='(hd0,gpt7)/devuan_daedalus_5.0.preview_20221022_amd64_desktop-live.iso'
	loopback loop $isofile
	linux (loop)/live/vmlinuz boot=live tzdata=Europe/London locales=en_GB.UTF-8 username=devuan findiso=/devuan_daedalus_5.0.preview_20221022_amd64_desktop-live.iso
	initrd (loop)/live/initrd.img
	}

That was the case before although the Debian packages were compatible with Devuan. TDE now have specific repos for all Devuan versions (and R14.0.11 is released today, in case anyone still thinks it's old, unmaintained code)

https://wiki.trinitydesktop.org/Devuan_ … structions