I've checked the release notes.
In particular, the part that refers to "Session management and policykit backends"

I was able to verify that my installation complies with all the requirements ie: the "recommended default
combination of login manager (either slim or lightdm) and session management system."

As to "Starting X from a console (TTY)", although I was being able to do it in the manner described ...  (in spite of having consolekit and not elogind installed)

... it was with the Shutdown and Restart options being greyed out, probably the effect of not having elogind installed.(?)

So I just in case, to comply with the Release Notes requisites, I installed SLiM (which I had previously removed) and reinstalled consolekit, in case it had become mucked up somehow.

The consequence was that the working desktop described above recovered the ability to Shutdown and Restart from the panel. =-)

Afterwards, looking closely at the screen output for a few reboot cycles made me aware of an issue regarding one of the services I had not been able to start.
The thread can be read here

It turns out that the service checkroot-bootclean.sh was failing to execute properly and, not seeing anything else that could have been giving me trouble, I went for it.

Being a script that apparently runs at boot and then exits (?) does not seem like a service to me, it looks more like what it is: a start up script.
No wonder querying it with service --status-all | grep -i checkroot- did not list it as running and me making a fuss over that.
Shouldn't there be a Script Starting Service with a list of scripts to check as needed?

But I digress ...
The fact was that it was being executed at boot and it was failing.

The graphical interface for Services was of no help whatsoever so I looked for the script and edited the .sh in the name. ie: *.sh -> *.old and rebooted.

Sure enough: it was the culprit.
Now I had recovered a fully working desktop.

Which meant that apparently, apt-get clean and apt-get autoclean were not at fault.
At least not this time.

But I was still getting boot time warnings about the bootclean script failing albeit with no apparent ill effects.

I tried to use chkconfig to sort that out, but could not find it: it seems to have been dropped from ASCII (I clearly recall using it in Jesse).

Then I found out about update-rc.d, which was installed.
I thought using it would clean things up for me and that would be it.

So I did update-rc.d -f /etc/init.d/checkroot-bootclean.sh remove but doing so left me without any screen output.  =^/

At that point this whole thing was getting old and I was needing my dose of espresso so I decided to take the easy way out.
But I'm not too happy about that.

I went to my Timeshift folder and recovered all the rcX.d folders in /etc from last saturday's snapshot and after renaming the existing ones as rcX.old, copied the backed up versions over to /etc and that was that. 

Things seem to be back to normal, whatever that is in this installation.

But I'd like to ask a couple of questions, if I may:

1. did I use update-rc.d correctly?
2. was it the proper approach to the problem at hand? ie: to clear out a script that I wanted to stop being run.
3. why can't the script be stopped with the graphical interface  ie: Applications -> System -> Services = [service]

Thanks in advance.

Cheers,

A.

I see ...
And how was I to know that ...

I have a stock-out-of-the-box Devuan ASCII that began as Jessie. 
Xfce and the rest came with it, nothing fancy save for the non-free Nvidia legacy 340 drivers.

Sure ...
But apt did not give me/print ou any data or warnings related to what was being nuked that I could check or heed.
I can be reckless but (I think ...) I'm a few years past being dumb.   ;^D!

In any case, if I trust apt-get update, apt-get install, apt-get upgrade and apt-get dist-upgrade to do things properly and not screw up anything, it stands to reason that I should be able to trust apt-get clean, apt-get autoclean and apt-get autoremove to also do things properly.
 
I'll call it the TTAG (Transitive Trust Apt-Get) theory, which unfortunately has not stood up to peer scrutiny. LOL!!!

I'll pour over the release notes in detail tonight or tomorrow morn, but in the meantime I really need to recover from this unfortunate blunder.

Any suggestions as to how I can go about it?
Any additional info you need to be able to appraise the situation?

Thanks in advance,

A.

Read the release notes.

After running apt-get clean && apt-get autoclean and rebooting I was left with a totally unresponsive mouse and keyboard.
The only way out is a hard reboot.

The exact same situation repeats itself if I boot into recovery mode and try to do startx as root: I get a desktop with a totally unresponsive mouse and keyboard and needing a hard reboot to get out.

But ...

If from the grub screen I hit 'e' and add a 1 to the end of the command line and then, instead of logging in as root, I continue with the boot process ie: with ctrl-d I can do startx and get a perfectly working desktop.

This same thing (yes, I never learn) happened to me with another distribution but only now realise that is is/may be related to running apt-get clean && apt-get autoclean.

Thinking it was a initscript problem, I reinstalled the package but no cigar.
Same with xfce. I even uninstalled SLiM with the same result.

Is it possible that running apt-get clean && apt-get autoclean has cleaned in excess?
Is there a log for apt?

Running apt-get check says everything is OK, so apparently nothing is broken. (?)

There is one noticeable difference in this desktop: Shutdown and Restart options are greyed out.
Only Log Out is available as the only user in this installation.

So I have to do sudo shutdown from a terminal but it asks me for the admin PW.

Any ideas as to what I may have mucked up now?  :^,

Thanks in advance.

A.