After ~6 years of using refracta-tools, I finally ran into the first problem creating a snapshot.  I do not know what to make of this:

The terminal output that displayed immediately after rsync copy completed:

The refractasnapshot_errors.log file noted:

This occurred after a dist-upgrade from ascii to beowulf with the xfce4 desktop.  Missing dependency perhaps?  This upgrade was done remotely on a friends computer in a ssh terminal.  A lot of packages were removed with "apt autoremove", so something could have been removed. 

Thanks for any ideas.

Sorry for such a long post, but I wanted to include all that I thought was relevant to my issue.  I am trying to use nested X-sessions between a client and server using the Xephyr-xserver package.  The Xephyr program appears to be working but I keep seeing these errors when I try to ssh into the server machine with the following command:

$ ssh -v -Y user@xxx.xxx.xxx.100

TL/DR-
- xauth is installed on both the client and server
- .Xauthority file is located on both client and server and it has the correct permissions
- sshd_config on server and ssh_config on client "appear" to have all needed options active.

These are the commands used with Xephyr,

This loads a blank black screen, which is normal.

user@host:~$ DISPLAY=:2 ssh -Y user@xxx.xxx.xxx.100

...
Warning: No xauth data; using fake authentication data for X11 forwarding.
...

Common configurations of client and server:

# xauth is installed on both the client and server

       
# xorg is installed on both client and server

# Xauthority has the proper permissions on both the client and server

I added this to both the server and client in the ~/.bashrc file just to try "something"

The username on the account is the same for both server and client.

Server setup

# sshd_config contains

# Client setup

# ssh_config contains in ~/.ssh/config

There is a lot written about this on the web and it seems rather straightforward to implement.  However, I am overlooking something.  I have tried several examples that I found on the web, but still I get these errors.

Additional info:
Even with the ssh x-forwarding errors, the ssh connection will succeed, so if I go ahead and issue the command to "startxfce4" in the terminal window connected to the server, I expect the xsession to start in the blank black Xephyr window.  Instead, I get this output:

But if I go into /etc/X11/Xwrapper-config and change

allowed_users=console

to

allowed_users=anybody

then the xsession will start, but not within the Xephyr nested x window.  It starts on the monitor connected to the physical machine. 

It is not forwarding the xsession to Xephyr, and I am out of ideas on what to check and I can not find anything new on the web to help me out, yet.  So I am asking for help.  Any ideas?

FlibberTGibbet mentioned that the Buster to Beowulf migration did work in WSL.  I had read about WSL but never tried it, so I gave it a spin.  It works.

This process is divided into three main parts:
Activate WSL in Windows 10 > Install Debian from MS Store > Migrate to Beowulf

Why do this?  > Why not?  It is there, give it a try and see if it helps with your productivity in some way.  My purpose was to run a native linux app "Virtual-Manager" (virt-manager) within windows for a friend of mine who wants to access KVM and its vhosts.  Your purpose may be different.

Install/Activate WSL in Windows

You will need to install an xserver in windows if you wish to display native linux apps.  After all, this is my reason for testing this WSL.  Xming seems to be the most popular, but this page mentioned that vcxsrv was the most pure opensource xserver for windows available.  It seems to work fine.

Install Debian in WSL

Boot up the "program" Debian in Windows 10.  You should have sudo rights by default, but if you want a root user, set the root password with:

sudo passwd root

Migrate Debian Buster to Devuan Beowulf:

My migration steps, mostly taken from the link above.

This step may be optional, but I have done it on all Beowulf upgrades and migrations that I have done.
export the PATH in /root/.bashrc with:

Change apt sources:

nano /etc/apt/sources.list

Make your sources.list look like the one provided. Comment out all other lines.

deb http://deb.devuan.org/merged beowulf main
deb http://deb.devuan.org/merged beowulf-updates main
deb http://deb.devuan.org/merged beowulf-security main
#deb http://deb.devuan.org/merged beowulf-backports main

Now you have to update the package lists from the Beowulf repositories.
Recent changes in APT mean this is not allowed but we can override this behaviour.

apt update --allow-insecure-repositories

The Devuan keyring should now be installed so that packages can be authenticated.

apt install devuan-keyring --allow-unauthenticated

Update the package lists again so that packages are authenticated from here on in.

apt update

Upgrade your packages so that you have the latest versions. Note that this does not complete the migration.

apt upgrade

Once this is done eudev needs to be installed.

apt install eudev

The last command is known to cause package breaks but we will fix this as part of the migration process.

apt -f install

The command to install eudev pulled in sysvinit-core, but not sysvinit, so:

apt install sysvinit

Just to make sure all is updated:

apt dist-upgrade

Systemd* packages were removed during this process, but just to make sure:

apt purge systemd libnss-systemd

apt autoremove --purge

apt autoclean

Before you start installing any packages in WSL, I recommend that you make apt to not install recommended packages. 
I suspect this will help keep the WSL smaller and leaner.  Add the following to /etc/apt/apt.conf.d/00norecommends:

Reboot  >  But the shutdown/reboot commands do not work in WSL.  The WSL process has to be stopped/started like any other service in Windows.

If you install openssh-server, you will notice that it does not start automatically with WSL, nor will most, or all, other linux services that you think should start.  Installing sysv-rc-conf and rcconf programs do not help, unless I did something wrong.  This may be a bug but I see no error message anywhere, yet.  However, this little script seems to control the start/stop of both WSL and its system services at the windows boot.  Beware, this script will start WSL with Windows, and it will start the (linux services) that you add to the command.txt file list.  I don't know about the security of this, but it seems to work.

Like FlibberTGibbet said, there is a niche group of people who would want or need this.  I feel this is true, but I am only tinkering.

I did not take exact notes during this testing, so if I made a mistake or overlooked something, please add your input.  After finding some good links, this was pretty easy.  And FlibberT was right, it is nice to have a (Devuan) linux terminal available in windows.  If I am going to use windows, I do want some Devuan on it. 

The option to use virtualization in windows still stands, but the ability to use a native linux program in windows without using a virtualization program is pretty neat too.  It removes a layer of complexity for the end user.  Instead of learning an entire program like virtualbox, the user only has to learn a couple of terminal commands to keep the WSL updated.  I hope my friend appreciates this new capability, and others may as well.

The only problem that I have seen thus far, is that the virt-manager program does not read the keys from the preferred $HOME area of the WSL user.  It reads the keys from the global /etc/pki/libvirt location within WSL.  The program "virt-manager" does work.  Will need to look into this more, later on.