OK, thanks for the responses. I do believe my question is answered. Will try to replace SLiM with lightdm.

When I press F1 at the slim panel, the words "Session: Xfce Session" appears on the slim panel. This does not seem to do anything in my case. I have the idea from several years ago that this was meant to switch between different desktops, if one had them installed (Xfce, ICEWM, etc), but the memory is hazy.

Furthermore, I have the idea that I would only see the slim panel if I was logged out? I know I can switch users by logging out, and then logging back in as the other user, but I would prefer to avoid logging the original user out (in case it is doing something that I would prefer to not interrupt)

Thanks to all who replied.

It seems that what I was specifically interested, i.e. sharing a logical volume between linux instances in a multi-boot arrangement in exactly the same way as a normal partition, hopping between instances as the mood or need dictates, is something that our community here has no experience of.

@fsmithred and @rolfie, you seem to be describing doing it once or twice and getting away with it, without catastrophe.
That is encouraging, so thanks for that. However, I would also have been interested to hear from people who do it regularly, as part of their standard operating procedure, but it seems that we don't do that sort of thing here.

It could be that the idea is so ridiculous that it is not discussed, or is so commonplace that it is quite unremarkable.
If I ever get around to the experiment, I should probably start off with data I to which I am not too attached.

Interesting, thanks. Are these 'parts' logical volumes?

So there is an lv with "office data" which is mounted by a Beowulf LVM instance when Beowulf is running, and by the Chimaera LVM instance when Chimaera is running? This seems to be similar to what I am hoping to do. For how long has this polyamorous arrangement been on the go without crashing&burning? (No H8, Love is Love, etc)

Splitting /home into generic/sharable and instance-specific seems like it's worth a separate tutorial(hint, hint)? Or maybe you could link to the guides/tutorials you followed?

Hi oui

I see several *i386* files. It is my understanding that these are the 32-bit versions. Can you access them?

Thanks for the links, references, reminder about the LTS kernel, and the..er..simple search.  I have fired up Liferea RSS reader and Thunderbird's RSS reader for the first time. They may be trying to tell me a bit too much about how the sausage is made, though.

It is perhaps a *little* disappointing that all the links point away from Devuan, but of course this is a tiny team trying to wrangle a monstrous stampede of catsnakes, and this is actually a complicated issue. Perhaps I could ask that if ever an extra mechanism besides aptitude is needed to keep a system up-to-date with security patches, a Devuan-specific advisory is posted in News and Announcements?

Hi Camtaf

I am interpreting your statement here as doing exactly what I have been doing (for years), where I say I

Is my interpretation of your statement correct?

I feel as if the bicycle helmet that I have been using for years for brainial safety has just been revealed to be made of millimetre-thick hand-blown Venetian glass, so I am not sure I am being entirely rational here.

Because of this, I am trying to check my assumptions. (If we are agreeing, we soon find ourselves banned from the Internet for improper use of a forum)

As part of the assumption-checking progress, I need to consider that I was at fault in not becoming aware of this situation you mention here:

Perhaps it was unreasonable of me to expect the distro to phone or knock on my door, or post an alert in large flaming letters on my desktop, just for the few old duffers who don't use their newer (admittedly interesting) homegrown package installer.  I imagine that this is what the News and Announcements section of the forum is for.  I do have the idea that if an update is recommended by the The Team, the words "recommended by The Team" should be included. And perhaps "the update is only available through our homegrown package installer - I hope you're reading this, old duffers who only use aptitude".

It seems the distro has actually acknowledged a problem by moving to 'auto-updating' kernels (in "refreshes" that came after my installs) by what appears to be the mechanism of kernel metapackages like the one fsmithred describes - wasn't this revolutionary technology invented in the noughties?

Of course, sometimes a kernel reaches EOL - how do distros deal with this? It's probably beyond the metapackagers art. Is this, once again, a job for "News and Announcements"?

Thanks for the feedback

$ sudo aptitude -s remove libsystemd0
The following packages will be REMOVED:  
  libsystemd0 
0 packages upgraded, 0 newly installed, 1 to remove and 9 not upgraded.
Need to get 0 B of archives. After unpacking 786 kB will be freed.
The following packages have unmet dependencies:
 liblvm2cmd2.03 : Depends: libsystemd0 (>= 222) but it is not going to be installed
 python3-systemd : Depends: libsystemd0 (>= 233) but it is not going to be installed
 lvm2 : Depends: libsystemd0 (>= 222) but it is not going to be installed
 libapt-pkg5.0 : Depends: libsystemd0 (>= 221) but it is not going to be installed
 rsyslog : Depends: libsystemd0 but it is not going to be installed
 libpulse0 : Depends: libsystemd0 but it is not going to be installed
 openssh-server : Depends: libsystemd0 but it is not going to be installed
 rpcbind : Depends: libsystemd0 but it is not going to be installed
The following actions will resolve these dependencies:

     Install the following packages: 
1)     libelogind0 [241.4-2 (stable)]

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

     Keep the following packages at their current version:
1)     libsystemd0 [241-7~deb10u7 (now, stable)]

Accept this solution? [Y/n/q/?] n

*** No more solutions available ***

I think what made me nervous about removing was this:

lvm2 : Depends: libsystemd0 (>= 222) but it is not going to be installed
.
.
 openssh-server : Depends: libsystemd0 but it is not going to be installed
 rpcbind : Depends: libsystemd0 but it is not going to be installed

Does that mean lvm2 and openssh-server will stop working? That would be a bit of a trainstopper.
Or, does it mean libelogind0 will simply take over all the functions of libsystemd0, and all apps continue smoothly?
I get the impression that is what you are telling me --- I did not pick that up on first read.

OK, I see a thread on elogind's github which appears to confirm that libelogind0 is a replacement for libsystemd0. https://github.com/elogind/elogind/issues/97

I tried just the reinstall:

sudo apt install libelogind0 --reinstall -s
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  libsystemd0
The following NEW packages will be installed:
  libelogind0
0 upgraded, 1 newly installed, 1 to remove and 9 not upgraded.
Remv libsystemd0 [241-7~deb10u7] [liblvm2cmd2.03:amd64 python3-systemd:amd64 lvm2:amd64 libapt-pkg5.0:amd64 rsyslog:amd64 libpulse0:amd64 openssh-server:amd64 rpcbind:amd64 ]
Inst libelogind0 (241.4-2 Devuan:3.0/stable [amd64])
Conf libelogind0 (241.4-2 Devuan:3.0/stable [amd64])

May the [] in the "Remv" line be interpreted to mean it will REMOVE the package in the first set of [] while the second set of [] show the packages that depend on it?

I think I might be running out of steam for today. Did I install this pain in my life by choosing runit? Or by choosing the server install? I have an older Beowulf install which, it seems, does not have libsystemd0. If I try to install it there, it offers to rip out libelogind0 and some fellow travellers.

Your comments have given me a thread to pull on, thanks. I might try the replace you suggest. If that does not work, it might be necessary to take off and nuke the entire site from orbit.