Oh and bleachbit/wicd-gtk also. But yeah minor issues easily fixable. GO DEVUAN! hehe.

I don't see how uuid has anything to do with mice and keyboards freezing up on xorg.
But what is now in ascii may not be what was there yesterday and today 12hrs ago I did not see any updates.

------------------- edit this note so I don't add another ---------------------------------------------

Did check on ascii, nothing yet to upgrade and the suspected 3 pkgs are of the same edition on ascii and ceres.
So what the heck made a difference in ceres?  Only difference is the kernel I can think about, but this hasn't
changed recently in relation to the problem and after last update of Linux412 the problem was not affected.
While the problem started first in ceres, I kept switching DMs to see whether it was DM/login screen related.
So the only thing different is in ceres I had last stayed with LXDM, instead of my usual lightdm.
So I installed lxdm in miyo-ascii but it did the same thing there too as it did on lightdm.

Note:  It only freezes up when the DM/login screen "first" comes up.  If I logoff to login to another account
the mouse and keyboard never lock up a second time.  So it all happens when X starts and passed control to
the DM.

Also, while on Openbox, the logout breaks up the dm, and as openbox is shut-down and no longer exists,
I am stuck on a half broken session where a terminal and other windows can still be initiated (like task
management).  If I then kill the lxdm-session then it exits out to the DM/login screen.

I guess I will have to wait for September when the dev-dev-team returns from vacating

Installed the following packages:
libminizip1 (1.1-8+b1)

Upgraded the following packages:
dmsetup (2:1.02.137-2+b1) to 2:1.02.142-1
libdevmapper1.02.1 (2:1.02.137-2+b1) to 2:1.02.142-1

Without too much investigation just the name devmapper sounds like very related.  But dm stands for device mapping as well.
Should I break rank and forwardport it to ascii?  I suspect you are thinking "of course you should if you want things fixed".
I think I shall!  If it is fixing things it will come down anyway in a few days (what happened to weeks in the mothership "borg").

Whatever the dev1 technicians are changing, for me at least, it seems to be working.
I wondered if it is linux-kernel related and in an arch based distribution I had tried
Linux4.13 in its early 2 steps and the mouse would freeze.  I never tried then to
unplug it and plug it back to see whether it gets fixed.  But I am wondering whether
a patch to fix something else would break something different and it flowed down
the kernel development assembly line.

Single-user is runlevel 1. If you want a runlevel that's multi-user non-graphical (like 2 or 3 in rh or suse) disable the display manager in one runlevel. (3 is most commonly used for this)

Correction: Debian doesn't use runlevels anymore.