Honestly the thing that drove me away from Debian was the constant pandering to whatever overengineered crap GNOME and freedesktop/redhat was peddling on any given day.
Systemd is fine for those who want to use it, but because GNOME depends hard on it at compile-time it's been given special status in Debian... Where special means an unavoidable, unremovable, low-level please-link-everything-against-me bloat-kit.

I'd have much preferred that they simply stuck with XFCE and dumped GNOME3 from the repos until the relevant developers got over their NIH, one-true-way, ewontfix corporate nu-linux mentality. Then we could have kept our freedom to choose our low-level system tools, and those who want a good whacking with the UX-braindamage bat could just use fedora...
But that would have required balls, which apparently the Debian leadership lacks.

Debian has never been primarily a desktop distro, and railroading everyone running it on servers for the sake of leg-humping a DE project they don't want was a right slap in the face.

Devuan did the sensible thing and kept XFCE as the default desktop, because unlike certain others it doesn't try to dictate your choice of init system.

I would hesitate to say stinks, but it can be a bit clunky, especially with all of Debian's mods (insserv etc) on top.
Really though, sysv is just a bit old and a bit crusty. It still does what it was meant to do, and does it tolerably well.

I haven't tried openrc on Devuan yet, but I can say it's pretty nice with Gentoo. Small, simple, cleaner configuration than sysv, and it just does what an init system should without getting in the way.
If and when Devuan ships native openrc init scripts instead of relying on sysv compatibility, it'll likely be as good as it is on Gentoo. Running openrc with sysvinit as pid1 and a bunch of sysv scripts makes no sense to me, I might as well run sysv.

I for one absolutely take the KISS approach to storage. Encrypted LVM does what it says on the tin, but it also adds a couple extra layers between you and what's on your disks - complicating, as you say, data recovery when (not if!) a drive dies.

As for full-disk encryption in general, I've never really seen the point. If I have sensitive data to protect, I'll encrypt that filesystem only and skip the overhead for the rest of the system.
TBH I really don't care if someone stealing my machine can read /usr/lib or not, it's irrelevant. Just, you know, don't store the keys to your encrypted /home or whatever on the unencrypted /.

That error regarding libmount.so.1 is almost certainly the culprit, and such a library version mismatch should never happen unless a n upgrade was forcibly interrupted or one has mixed releases and/or otherwise messed about with sources.list.

You might be able to fix it by installing the correct versions of the relevant packages (mount & libmount1) from a livecd chroot, but YMMV. Depending on how the system ended up in this messed up state any number of other things may be borked as well.

Neither did I. If I need an installer I'll pick the TUI one every time, and frankly I don't understand what a GUI provides in that context besides a bigger install image and more to go wrong. Starting an X server and all the baggage that entails just to have a pretty installer nuts.

On the OP at hand:
As the patient does not belong to the tap-and-drool selfie-stick demographic, I suspect this is simply a case of classic CLI-o-phobia. For the unfamiliar, a disorder brought on when suppressed memories of CP/M, DOS, the Windows command prompt and other shells designed to torment their users are brought to light, often upon encountering a similar text-interface aesthetic years later.

For this I usually prescribe the LFS treatment, followed by a light regime of Slackware or Gentoo use. Symptoms generally resolve in short order given sufficient exposure to bash/zsh, the GNU utilities and a proper POSIX environment.

Indeed. Hell, the Gentoo "installer" is perfectly fine in 2020.

Why would you need copy-paste in the installer anyway?
I mean you can use GPM at the console, but why?

Indeed it is, but that would be off topic for this thread.

What hints? The very useful one that VirtualBox provides when you try to start a VM without the kernel module loaded?

By "the instruction" you mean

modprobe vboxdrv

?

If that works then the kernel module has been built just fine, it simply needed to be loaded.

Unless you have configured the system to load that module at startup (i.e. in /etc/modules or some init script), you will need to load it when you want to use it.
What's unexpected about that?

ED. The repo at

https://people.debian.org/~lucas/virtualbox-buster/

is probably a better option than Oracle's .debs. It looks like it includes virtualbox-dkms for automatic rebuilds against new kernel versions, as well as an init script to load the modules at system startup.

I don't see anything in there that would make those Debian buster packages problematic on Devuan beowulf, but as always, YMMV.

It's just another upstream solution in search of a problem.

'su' no longer adds /sbin and /usr/sbin to your $PATH, so you will get "command not found" for any binaries that live there.
'su -' or 'su --login' will read root's profile, so you get root's $PATH, which does include /sbin and /usr/sbin.

Stick alias su='su -' in your ~/.bash_aliases and forget about it.

Sounds like some cruft in root's .profile / .bashrc etc?

What does env say after you su to root, and what's in root's .bashrc, .profile, .bash_profile and .bash_aliases (if they exist)?

Smells like a pam screwup to me (assuming it's not some new and wonderful default).
What do /etc/pam.d/su and /etc/pam.d/su-l contain?

You should not be able to su of any kind without a password unless you are already root, or you have something like "auth       sufficient pam_<something>.so trust" in your pam su config, which would be very silly.

I kinda hoped most Devuan users were smarter than that. Aren't we here to get away from marketing and empty promises?

If I saw this request over on the *buntu forum I'd understand, but someone caring enough about systemd, KISS/UNIX principles and/or the redhat/corporate encroachment to be running Devuan ought to be well wary of such hype no?

I actually have some faith in Firefox and the Mozilla foundation, if only because they're the only independent browser vendor without a glaring conflict of interest... That and Netscape/Mozilla was once the only real option on GNU/Linux.
We're not the priority, sure. But they gave us a usable modern browser back in ~2002, and it's still all that.

Indeed. AFAICT it's nothing more exciting than YACB (Yet Another Chromium Build). So why all the yammering about it, like it's the hottest new thing?

The Devuan installer is almost identical to the Debian installer, which is thouroghly documented and has served well for many years.

Comparing Devuan to Mint/Ubuntu is disingenuous, they have very different intended audiences.
One focuses on being beginner friendly, the other on flexibility and reliability. This is why they have an easy-mode installer, while ours has lots of options. Making the install process like Ubuntu would exclude a large number of possible configurations.

If the flexible and configurable installer is "too complicated" for you, perhaps you should read the manual?
If that doesn't answer your questions, there's always the Debian install guide, which is 99% applicable to Devuan.

If Ubuntu/Mint is all you have used since then, you're still a "newcomer" to Devuan.
Both of those distros are noob-friendly Debian derivatives targeted squarely at those who are allergic to the command-line, and they exist almost entirely to make Debian (and thus Devuan) less complicated.

Nah, got down on a used Supermicro X9DRL-iF + 2x E5-2650 for cheap. Just waiting on some more RAM (also cheap) and non-obnoxious coolers. Damn virus slowing down shipping and all that.

Ryzen would be nice and all, but the price was right in this particular case, and I want the dual LAN, IPMI & 10x SATA ports more than I want another AMD machine. Haven't owned one of those since 2001.

For this box, where raw performance is less important than reliability and expansion options, I'm fine with running a couple of generations behind the cutting edge. Used server parts are readily available and IME far more reliable than even new consumer-grade stuff.

Then of course there's the small matter of scoring a board, 16GB of RAM & 2x CPUs for ~1/3 the price of that shiny AMD CPU alone...

Now that I've finally upgraded the old under-desk battleaxe to Beowulf:

   ..,,;;;::;,..                   steve@redacted
           `':ddd;:,.              --------------- 
                 `'dPPd:,.         OS: Devuan GNU/Linux 3 (beowulf) x86_64 
                     `:b$$b`.      Model: X7DCL-3 
                        'P$$$d`    Kernel: 4.19.0-9-amd64 
                         .$$$$$`   Uptime: 11 days, 19 hours, 45 minutes 
                         ;$$$$$P   Packages: 1537 (dpkg) 
                      .:P$$$$$$`   Shell: bash 5.0.3 
                  .,:b$$$$$$$;'    Terminal: /dev/pts/3 
             .,:dP$$$$$$$$b:'      CPU: Intel Xeon X5460 (8) @ 3.167GHz 
      .,:;db$$$$$$$$$$Pd'`         GPU: XGI Technology Inc. eXtreme Graphics Innovation) 
 ,db$$$$$$$$$$$$$$b:'`             Memory: 40164MiB / 48296MiB 
:$$$$$$$$$$$$b:'`
 `$$$$$bd:''`                                              
   `'''`

The best bit: 32TB storage

Soon to get a hardware update to 16 cores & 64GB. Those old dual Harpertowns are a power hog.

Good to know. I didn't see this info anywhere official, so thanks for the heads-up.