Firstly, thanks Devuan team for Excalibur. I have already Excalibur installs but still mostly run Daedalus, while I get Excalibur all configured how I want it.

Trying the new ISO in qemu I can't get it to boot from a syslinux USB in my usual way (using the
*.c32 modules from /isolinux). Although qemu does boot the ISO directly.

Undef symbol FAIL: init_fpu
Failed to load libcom32.c32
Failed to load COM32 file vesamenu.c32

On investigation I found the md5sums of /isolinux/*.c32 are different from what is in the (system's) /usr/lib/syslinux/modules/bios ..

They also differ from my own /usr/lib/syslinux/modules/bios/ in both excalibur and daedalus.

If I replace those modules in my USB's /syslinux with the ones from the system, everything works as expected.

I already have verified the sha256sum of the ISO.

Where do /isolinux/*.c32 in the ISO originate from and why are they different?

More info (please don't request support there if you don't run siduction):

https://forum.siduction.org/index.php?topic=9864.0
https://forum.siduction.org/index.php?topic=9854.0

Looking here from a  live session (qemu, usb booted) of exegnu64_excalibur-20251119.iso .. This is the only published ExeGNU Excalibur.

user@exegnu:~$ dpkg -l|grep libdb5.3t64
ii  libdb5.3t64:amd64                    5.3.28+dfsg2-9                               amd64        Berkeley v5.3 Database Libraries [runtime]
user@exegnu:~$ ls /usr/lib/x86_64-linux-gnu|grep libdb
libdb-5.3.so
libdbus-1.so.3
libdbus-1.so.3.38.3

Shows that libdb5.3t64 is installed and the suspect file is actually present. Also:

user@exegnu:~$ dpkg -l|grep mpv
ii  mpv                                  0.40.0-3+deb13u1                             amd64        video player based on MPlayer/mplayer2

Shows mpv to be already installed.

So far I can't reproduce this error and mpv (here) works as expected.

The correct md5sum of exegnu64_excalibur-20251119.iso is: 3c606f377ac22b56ea4981ebeb54c25b

Does this match the ISO you used to install?

I know exactly what you mean and saw it. It's because refracta-lang exits if locales= was used but only after running the older lightdm fix, which has issues in Excalibur. The latest 1065-refracta-lang does it differently (in ~/.xsessionrc not /etc/X11/Xsession.d/). This seems to work in all cases.

EDIT I did try running with 'locales=en_GB.UTF-8 nocomponents=refracta-lang' (refracta-lang disabled, no .xsessionrc). The correct locale was set for user but on relogin the lightdm switcher failed to reset the new session to en_US, even though ~/.dmrc was updated. Therefore the bug still exists but can be fixed in ~/.xsessionrc ..

Strangely, the custom background shows in qemu, usb or grub boot you get the rat. Similar issue to https://dev1galaxy.org/viewtopic.php?id=7133&p=2 .. Seems upstream is uninterested in fixing that. But we can locally, in chroot:

# Convert a copy of /usr/share/backgrounds/xfce/deepsea_173556_640x480.png to svg (used png2svg)
# Copy the new svg to /usr/share/backgrounds/xfce/deepsea.svg .. Then (in chroot):

dpkg-divert --divert /usr/share/backgrounds/xfce/xfce-x_orig.svg --rename /usr/share/backgrounds/xfce/xfce-x.svg
cd /usr/share/backgrounds/xfce
ln -s deepsea.svg xfce-x.svg

Language selector fix (even better to see a keyboard selector also) done here in chroot:

sed -i 's/#indicators=.*/indicators=~session;~language;~clock;~power/' /etc/lightdm/lightdm-gtk-greeter.conf

The mtp boot noise is fixed by installing libmtp-runtime. The alsa error fix is as https://dev1galaxy.org/viewtopic.php?id=7400

Updated 1065-refracta-lang : https://paste.debian.net/1411823 .. Remember to name it correctly and +x it.

BTW there is no point showing fixed-disk icons on the desktop if they give no information and mount permission is denied!

EDIT How does Thunar actually do mounts? This needs sorting to assist use as a rescue image

With 'python-is-python3' installed (16kb), ps_mem.py runs here without changing anything.

Thanks Devuan team, great work. It's solid. Although some of us impatient ones have ran Excalibur for 2 years already!

No announcement yet but its imminent. Previously only 'preliminary stable builds' or 'preliminary testing builds' were available for Excalibur. Today:

# Trinity R14.1.x Stable Release (not for testing/unstable)
deb http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-r14.1.x excalibur deps main

is up and running. New packages show up as 4:14.1.5 and will upgrade from previous 'preliminary stable builds'.

If you already run Excalibur with TDE, maybe best make that change now if you want TDE stable release 4:14.1.5 ..

EDIT: Also, my thanks to the Trinity Desktop project, which has maintained packages for us since the early days of Devuan Jessie!

Hazy memory.. now long defunct, the alternative Debian forum (~Etch or Lenny?) set up by banned and/or disgruntled users in response to mainstream forum censorship..

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!