The first patch that addresses this issue was listed here
https://git.devuan.org/devuan/installer … 2e12e7251c
but then I removed that entirely (and removed other old parts), and placed rsyslog in another part to ensure it gets installed
https://git.devuan.org/devuan/installer … 37ddeb4887
Not sure that's the proper way to do it, but it did pass my initial testing at least.

The first fix could be patched into a running installer, by replacing /usr/lib/finish-install.d/18late-install-stage2

cat <<EOF | tee /usr/lib/finish-install.d/18late-install-stage2 > /dev/null
#!/bin/sh
if [ -f /target/var/lib/dpkg/info/desktop-base.list ]; then
	# desktop-base was installed.  reinstall it after other packages if possible
	if [ -n "\$(grep ^deb\ http /target/etc/apt/sources.list)" ]; then
		# there are online apt sources listed; do not use installation media
		sed -i -e 's/^deb cdrom:/#deb cdrom:/g' /target/etc/apt/sources.list
		in-target sh -c "apt-get -y reinstall desktop-base"
	elif [ -n "\$(ls /target/tmp/desktop-base/desktop-base*.deb 2>/dev/null)" ]; then
		# the deb from installation media is available
		in-target sh -c "cd /tmp/desktop-base ; dpkg -i *.deb"
	else
		# this is an offline installation, and the deb was not found
		log "(offline) unable to reinstall desktop-base: deb file is unavailable"
	fi
fi

# check if rsyslog got installed
if [ ! -f /target/usr/sbin/rsyslogd ]; then
  # not installed; try to install it if possible
  if [ -n "\$(grep ^deb\ http /target/etc/apt/sources.list)" ]; then
    # there are online apt sources listed; do not use installation media
    sed -i -e 's/^deb cdrom:/#deb cdrom:/g' /target/etc/apt/sources.list
    in-target sh -c "apt-get -y reinstall rsyslog"
  elif [ -n "\$(ls /target/tmp/rsyslog/rsyslog*.deb 2>/dev/null)" ]; then
    # offline installation; the deb from installation media is available
    in-target sh -c "cd /tmp/rsyslog ; dpkg -i *.deb"
  else
    # this is an offline installation, and the deb was not found
    log "(offline) unable to install rsyslog: deb file is unavailable"
  fi
fi

# patch for /usr/lib/udev/rules.d/90-alsa-restore.rules
# see: https://dev1galaxy.org/viewtopic.php?pid=57929#p57929
pathname="/target/usr/lib/udev/rules.d/90-alsa-restore.rules"
if [ -f "\$pathname" ]; then
  # verify if patch is required
  if [ \$(grep -c '^LABEL="alsa_restore_go"' \$pathname) -eq 2 ]; then
    # same label exists twice. patch is needed.
    linenum=\$(grep -n '^LABEL="alsa_restore_go"' \$pathname | (read first; read second; echo \$second | cut -d : -f 1))
    # delete the wrong label (2nd one) and insert the correct label
    sed -i -e "\${linenum}cLABEL=\"alsa_restore_std\"" \$pathname
  fi
fi
EOF

Or... to build your own updated ISO:

git clone https://git.devuan.org/devuan/installer-iso.git
cd installer-iso
./build-sudo.sh excalibur netinstall

replace "netinstall" with the iso you want to create (for example, "desktop")
view the README.md file there to see dependencies and other helpful info.

Probably the easiest way to achieve this is to set your current_theme to "original" (in /etc/slim.conf).  Then in a terminal, run

cd /usr/share/slim/themes/original
sudo mv background.jpg background.backup
sudo cp $HOME/newbackground.jpg ./background.jpg

That is, assuming the background image you want to use is called "newbackground.jpg" in your home directory.  Replace that part of the last command with the actual file name and path.

This should probably be a separate thread, as it's not related to desktop-live pre-release isos.  Anyway...
I experienced the same thing with a new install (from the netinstall iso).  But an upgrade from daedalus works without the package xfce4-screensaver.  The difference appears to be that the upgraded machine contains /etc/xdg/autostart/xscreensaver.desktop, while the new install does not have that, but instead has xfce4-screensaver.desktop without the xfce4-screensaver package, like you described.  So something is wrong with the default behavior - it should either have included the new xfce4-screensaver package, or else created a xscreensaver.desktop file in the autostart directory.

When I tested this (I think it was the latest / 1.4.1-1devuan4, but I'm not positive about that), it simply displayed the login window with the (incorrect) user name filled in as default.  This, I believe, should be the expected behavior.

[edit]
The latest slim/testing does crash when the user name does not exist.  Not sure what version I tested where it worked.  Maybe it was in-between versions (development).

[edit2]
I'm a little confused now.  I'm sure I'm doing something wrong/unusual here.  First I did apt source slim/unstable, then I followed the INSTALL instructions to build it (cmake ../slim-1.4.1 ; make), and auto-login with an invalid user just puts me at the login screen with the invalid username filled in (no crash).

[edit3]
It occurred to me, it's probably due to my build settings being different.  I don't think I included PAM or ConsoleKit, so the crash might be in one of those #ifdef blocks.

[edit4]
OK, as ralph mentioned above, the trick was to run debian/rules - then run make in the directory it creates.  So now at least I can test the same code line.

[edit5]
The issue seems to start with App::Login().
In the first #ifdef USE_PAM block, when the attempted autologin user does not exist, the PAM::Exception is caught, and slim exits with ERR_EXIT code.
When USE_PAM is not defined, the "pw" variable gets a value of 0, and App::Login() returns.
So, naturally, I tried changing that exit(ERR_EXIT); to a return; in the USE_PAM block.
But... that just moved things down the road a little bit.  The main loop in App::Run() continues until it hits the call to AuthenticateUser(), where we run into more troubles.  There is a separate AuthenticateUser() function for use with USE_PAM.  Once again, the call to pam.authenticate() is caught with PAM::Exception, where we find another exit(ERR_EXIT);.  Changing this to return false; just causes the main App::Run() to get caught in a never-ending loop, attempting to log into a nonexistent user account.  I'm looking at the non- USE_PAM version of AuthenticateUser(), maybe some of this code needs to be added to the USE_PAM version.  But it's getting late here now, and my time will be a bit limited the next few days...

That's part of alsa-utils package, which is not forked by devuan.  Is there an open bug report on debian about this?
FWIW, the excalibur installer iso (and I believe the live iso) files patch the 90-alsa-resore.rules file, but an upgrade from daedalus would require manual patching.

I did test the desktop dvd with virtualbox (it works there for me) but not vmware.
Is this an online installation, or offline?
When it gets stuck on the late-install-stage2, are you able to press alt-f4 (or alt + right-arrow 3 times) and report back the last few lines of that output for debugging?

Hm, here the default slim login puts me into an xfce session.  But there are several lxqt packages that got installed, including lxqt-session.  These can probably all be safely removed with apt remove lxqt*

I think, possibly, they got pulled in from network-manager-applet

aptitude why lxqt-session
i   task-xfce-desktop      Recommends network-manager-applet | connman-gtk | cmst
i A network-manager-applet Depends    policykit-1-gnome | polkit-1-auth-agent
i A lxqt-policykit         Provides   polkit-1-auth-agent
i A lxqt-policykit         Depends    lxqt-session

Someone else said those words here https://bugs.devuan.org/cgi/bugreport.cgi?bug=857
see also, https://git.devuan.org/devuan/slim/issues/9

Yes, it is unknown whether the patch will cause other issues at this point, that's what testing should help with.

Also of note, this bug is reported to debian, and they may come up with another (better) fix.
https://bugs.debian.org/1117831

Hmm... looks like grub can use any of these files:
/boot/grub/menu.lst
/boot/grub/grub.conf
/boot/grub/grub.cfg
/boot/grub2/grub.cfg

in /usr/lib/linux-boot-probes/mounted/40grub2, function parse_grub_menu() :

if [ -z "$title" ]; then
	ignore_item=1
elif echo "$title" | grep -q '(on /dev/[^)]*)$'; then
	log "Skipping entry '$title':"
	log "appears to be an automatic reference taken from another menu.lst"
	ignore_item=1
fi

That's why it skipped the entry - it matched the string.  For your particular case, the easiest fix would probably be to patch 40grub2, but that wouldn't help others who encounter the same problem.  Does arch use the same version of grub2?

Hopefully this is the problem:

In /etc/default/grub, find the line

#GRUB_DISABLE_OS_PROBER="false"

and remove the # symbol:

GRUB_DISABLE_OS_PROBER="false"

It's worded kind-of awkwardly, but that will make grub not disable the os-prober, that is, it will enable the os-prober.
After saving the file, re-run update-grub

There are a few ways to do this.  Replace command_user="radio" with command_user="$USER" is one way (probably the way that makes the most sense).  Another option is command_user="$(whoami)".  If you want a non-sensical solution, use command_user="$(env | grep ^USER= | cut -c 6-)" (but that is a very strange way to get the USER).