Thanks Prowler_Gr for exposing a clearly political move, during Trixie "hard freeze" mode (and yes it's in today's Excalibur updates).

Who do these people work for? The changelog doesn't tell us much unless you dig deeper:

Thanks also Prowler_Gr for your great work with AntiX and MX, much respect to both and many fond memories from the days of sidux where anticapitalista was a superb contributor. Although I never (yet) got to understand that unique live-boot process..

True but.. The 'esp' and 'boot' flags don't need setting on the USB. UEFI will look in /EFI/ on the first partition, which must be FAT formatted.  Other files can  be on the same partition. Therefore an ISO built with UEFI support can be simply copied to a FAT formatted USB and will boot in UEFI mode.

Done like this a USB will also boot in mbr mode; with few and minor modifications, the 'boot' flag set and syslinux correctly installed.

It should boot in both cases exactly like the cdrom with the same splash and boot menu.

As for 32-bit UEFI machines, I heard of them but never seen one..

That change calls mkinitramfs. It doesn't seem to work on an extracted directory. I tried it on an extracted excalibur initrd.img (while in daedalus). The output, when itself extracted, had files from my running system, not what was expected! And I see nothing in it's man page that mentions input from a directory.

EDIT: Of course, snapshot would only  be used on a running system (unless in a chroot, never tried that). Maybe then it does work for snaphot, or at least appears to. But there is still the multiple cpio  issue to consider..

Now posted here:

https://exegnulinux.net/files/refracta2usb/

No guarantees those changes are all good, till well tested in different scenarios. It's a work in progress with Excalibur in mind but should be compatible with at least daedalus.

The git repo is a great idea. For now, maybe take a diff against the extracted, original refracta2usb-2.4.3.deb to highlight the changes.

Thanks in advance anyone who wants to test but please be warned this stuff runs as root and is experimental so far.

And thanks especially fsmithred for this and the other superb refracta tools!

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.

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?

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.

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.

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

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

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

apt update && apt install linux-image-amd64

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