Seen posting by someone mentioning the us. for the code when a person was having problem and figured I would try mine, it worked as well as the us. did when I tried it. I went through every mirror in the listing of them they have when I first installed to find good one and quite frankly it is not impressive errors all over the place with them. Ranging from timeouts/404 errors to not having release files or the gpg signing of them.

Well if it is then upgrade your kernel you are four versions behind, the -31 kernel just came out yesterday. For the sleep problem no clue I never use it.

Debian stable never updates packages like that, any OS based on it, which daedalus is,  has the same limitations. If you want newer version then you need to upgrade to excalibur which has the version 32. This is always the main complaint about the Debian stable versions the software is frozen at the time of release not getting updated versions until the next stable release in about two years time they aim for these days.

root@9600k:~# apt policy lxqt
lxqt:
  Installed: (none)
  Candidate: 32+b1
  Version table:
     32+b1 950
        950 http://ca.deb.devuan.org/merged excalibur/main amd64 Packages
        600 http://ca.deb.devuan.org/merged unstable/main amd64 Packages

Well you seem fine with editing the distro.py, what is the problem with editing the other file need in this the os-release to match what is expected/required of it to work as you need. Make the two changed needed in it and it will work like you need it to do.

Follow the instructions below to fix the windows time, it make it use the UTC.

https://doc.iosenag.net/windows/utc-clock.html

As you have figured out their broken installer will not let you do that, you are stuck with the work around you have used. Just like I finally figured out last year why the damn thing does not respect your choice for the /boot/efi partition you get to set when using manual partitioning as I always do. The damn thing per-selects every efi partition in the system for use as an efi system partition. Unless you go to every single one of them and de-select your choice is ignored depending on its position in the drive listing on that page. If your drive is third in the list then you damn well better make certain that one and two is not selected or those will be used before your choice. If last in list with more drives then every other partition needs to be de-selected before your choice will be used.

As they say around here " there is more than one way to skin a cat" no clue why they pick a cat but the gist of it is there is always more than one option. Go to the source Debian, get the netinstall .iso do a minimal install then convert it to Devuan. That is how I got it on the box the Devuan installer will not boot on my machine, actually I just cloned my machine's Debian install and did the conversion. You get to test if the changes made by Devuan are the problem or if the Debian installers are the problem. Or do the cloning I have suggested before.

At this point looks like it is the installer itself then with it passing all those tests. An idea since you have grub installed on the disk just clone your install to the stick either while booted into it or booted from an install disk. The install disk is simplest way to do it as it is a straight up rsync command from the mounted install partition to the USB stick partition. As root or with sudo in front of the commands.

mkdir /tmp/oldroot
mkdir /tmp/newroot
mount /dev/sd?? /tmp/oldroot
mount /dev/sd?? /tmp/newroot
rsync -avP /tmp/oldroot/* /tmp/newroot/
blkid                <---- use to get old and newroot drive UUIDs
sed -i "s/oldroot_UUID/newroot_UUID/g" /tmp/newroot/boot/grub/grub.cfg
sed -i "s/oldroot_UUID/newroot_UUID/g" /tmp/newroot/etc/fstab

Now when I do this on EFI system never having done a MBR I have to change the UUID to the new root in the /boot/efi/EFI/debian/grub.cfg. Once that is done I have identical copy of the drive in the machine ready to boot on the drive it was cloned to. It works without fail so many times I have lost count of the times I have used that script I wrote to do this. If there are no other files that grub uses in booting a MBR drive other than those I show it should just boot your present install that was cloned onto the USB disk when put into your SUN machine. If wanting to do it from running machine then the rsync becomes this from my script. If logged into a graphical session with the /home directory in use then there are many other things that need to be excluded in that situation.

rsync -ahPHAXx --delete --exclude={/boot/efi/*,/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/swapfile,/lost+found} / /tmp/root/

This excludes everything that should not be copied from a running system as it is recreated on every boot unique to that boot. In my script the target for the copy is the /tmp/root/ that gets created by it. Something to try if it turns out the install disk is the problem as a way to get an OS on the USB stick. Now I look over it again if you have any other partitions being used you need to change them UUIDs as well on the USB stick fstab to those new UUIDs as well as copy them over.

I find it hard to believe you could have file system errors on first boot of the operating system. That to me suggest corruption during the install. Have you created a memtest86+ boot disk and let it run a few passes to confirm the memory is still in good shape. Also where does the 6.10 kernel come from? That is not the stock kernel on that install disk.

@kapqa Yeah computers can be damn strange at times, good to read it now works for you.

I used a different one from that thread, it test to see if already running and kills it off so you do not get two running at the same time. That would really only happen with a logout and X server restart but none the less better safe than sorry.

zeus@9600k:~$ cat .xsessionrc 
# Added when  startx to start pipewire on login to desktop
# https://dev1galaxy.org/viewtopic.php?id=5867

# kill any existing pipewire instance to restore sound
pkill -u "$USER" -fx /usr/bin/pipewire-pulse 1>/dev/null 2>&1
pkill -u "$USER" -fx /usr/bin/wireplumber 1>/dev/null 2>&1
pkill -u "$USER" -fx /usr/bin/pipewire 1>/dev/null 2>&1

exec /usr/bin/pipewire &

# wait for pipewire to start before attempting to start related daemons
while [ "$(pgrep -f /usr/bin/pipewire)" = "" ] ; do
   sleep 1
done

exec /usr/bin/wireplumber &

exec /usr/bin/pipewire-pulse &

Distributions have taken to black listing the pcspkr module as it some kind of inconvenience to be alerted to potential problems, the noise offends their sensibilites.

To get your beep in the console back.
https://askubuntu.com/questions/19906/beep-in-shell-script-not-working

edit the /etc/modprobe.d/blacklist.conf and comment out the black listing of
the pcspkr module.

# ugly and loud noise, getting on everyone's nerves; this should be done by a
# nice pulseaudio bing (Ubuntu: #77010)
blacklist pcspkr

Put a # in front of the blacklist pcspkr and on next boot the module should load. A modprobe pcspkr as root or using sudo in front should load it and have it available without the reboot.