@hunter0one: I don't see any signs that Void are changing anything.  I don't use elogind on Void, perhaps because I don't use any DM.

In 2015 when I used "sinit" to init Debian7 then Devuan, I used "mdev" plus "something" to effect hot-plugging devices [I forget].  Nowadays, the "mdevd" daemon is available to handle that [not used it yet]. 

The problem is in the lib[g]udev libraries, which are required by firefox, chromium AND all webkit-based browsers.  I can't see what exactly these libraries ACTUALLY do.  The Linux kernel creates static devices, and "mdevd" would respond to new devices and set correct permisions for them.  Will someone save me from reading the source code to find out.

Thanks @andyp67: for "rsync" think a better "cp" command:  I have been using it to clone file systems, moving between partitions and removable backup drives.  The issue with startx and /tmp is just an annoying thing of my own doing, and can be resolved.

Aside:  whilst I have used computers for 50 years [mainly scientific research], only since 2015 have I taken an interest  in alternative init systems [etc].  I started by replacing sysvinit with "sinit" on Debian7 and Devuan.  However, I got bored with that, and moved to Void Linux and Runit.  Recently, I have explored Runit on AntiX and Devuan:  both are complicated by re-using the sysvinit scripts.  Both mean I must learn apt, apt-get and dpkg anew.  Hence the questions here.

Good news:  "apt-get dist-upgrade --fix-missing" completed without any errors.  Bad news:  it seriously messed up my system.  For example, whereas I had stopped slim graphical login with "chmod -x /etc/init.d/slim", now nothing would stop it.  I'm not sure what other damage the dist-upgrade did.

I have decided to try and undo things from an earlier rsync backup.  Thanks anyway for your help here.

@fsmithred:  I changed /etc/apt/source.list from chimaera->daedalus according to your instructions, but the "apt upgrade" failed with error

  "libwacom9 depends on libwacom-common  2.6.0-1 but 1.8-2 is to be installed:  broken packages"

If this was the first of many breakages arising from the shock of switching the sources.list, then I may be stuck.  I will probably reverse sources.list to chiraera and hope that "apt  update" fixes things.  Ideas?

Thanks @fsmithred, I was going to just use 4.0, maybe adjusting my grub.cfg to select the most recent kernel.  However, if I can perform an upgrade to 5.0 following your instructions, I will try this [after a system backup].

By "did nothing" I just meant that no new packages were installed.  I just used

  apt-get update
  apt-get dist-upgrade

so I skipped the separate "upgrade" step, thinking "dist-upgrade" was enough.

I attempted to re-install, and it failed with a fatal error [again] in the part where it installs the boot loader.  I was only able to continue by skipping over the offending step.  I did not see any reference to UEFI, so it must have been with the failed skipped step.  On completion, and reboot, the result was as before:  it drops into a shell complaining about fsck failure on a ficticious FAT filesystem.

So, why is the installer failing in the crucial boot loader step.  I'm stuck.

Added:  plan-B is to fresh install Devuan 4 using netinstall.  Hopefully, it will let me opt out of bootloader but accept my bios choice.  Then update+dist-upgrade might just get me closer to 5.0, or not.

Added:  Devuan 4 installed without incident, but dist-upgrade did nothing.  I can't believe that I am the only user affected by Devuan 5 the fatal installer issue.

I completed a netinstall, selecting runit.  It failed configuring shim-signed.. executing "grub-install dummy failed, fatal error", but I continued to the end and I opted out of the bootloader install [I prefer my 8-line custom grub.cfg file].

On reboot, it fails with "fsck.fat error code 6", which doesn't exist.  Also, why is it attempting to do anything with FAT filesystems:  i do not use Efi on my computers.  Did I miss some Efi-related option when doing the netinstall?  I can continue through this error, but every time I reboot becomes a pain.

@fsmithred:  thanks, I am not aware of what would modify my custom grub.cfg file between boots;  on Void grub.cfg persists until I install a new kernel and then I manually revise it.  Probably Devuan does something different.

I take your point about using UUIDs when multiple drives are present.

The 177 line grub.cfg file created for Void has does not contain the strings "msdos" or "gpt", but I can see that msdos->gpt would be right;  I assume that files in /etc/grub.d/ are used by grub-mkconfig to create grub.cfg.  Unfortunately, I can't find out what Devuan would put here without actually letting the installer load the bootloader.  Lots of thinking needed.  Maybe a few experiments.

I am probably making too much of a meal of this and should just rsync backup everything to USB drive and let the Devuan installer run bootloader as its last step.

Thanks, I will try adding into /etc/apt, though I am not sure about mixing different releases.  My backup is to modify ~/.config/openbox/menu.xml .  I must be alone in using Openbox as my DE.

nomorelogic:  I saw you needed recent mesa.  Both void live image and devuan [ceres] have the latest mesa-20.3.4 package