Okay, I think we can close this one. It's hardware.

The counterpart to that failed drive was taking 27s to initialise and appear on the bus. It's certainly not ideal for the initrd to spam scary errors instead of backing off and retrying, but it's not his fault either.

[rant]
Moral of the story: The Crucial BX500 series SSDs are utter crap.

Of that pair of SSDs, one is dead as a doornail (doesn't register on the bus), the other is clearly dying.
Both are less than a year old and still under warranty, but I'll be throwing them in the trash rather than returning them - the last thing I want is more of the same.
Both have history of hitting ~70c and thermal throttling under sustained write loads, despite the enclosure and the drives directly above them never breaking 26c.
The nasty plastic casing never even gets warm, and now that I've dissected one I see somebody at crucial thinks putting a thermal pad on the controller is a luxury. 70c is listed as max operating and they never exceeded it, but I'll bet a cookie heat is why they died.

Crucial, your budget SSD line gets a solid F from me. The Kingston A400 series is not only cheaper, it's also built properly and doesn't constantly try to cook itself.
I wanted budget SSDs for that filesystem, and expected budget performance. What I didn't expect was something so shitty it can't even sustain the already mediocre performance numbers without overheating.
FWIW, a BX500 reporting 70c writes at ~7MB/s.
[/rant]

Sounds like as good a plan as any, if you actually intend to use the features of LVM.

To be fair I don't use it myself, so I'm not the one to ask about LVM layouts. As nice as it's features are I've never really needed them - if I want disk-spanning or redundancy I use mdraid or zfs, everything else is old-school partitions and mountpoints.
For me, LVM is one of those things that sounds really handy in theory, but is in reality a solution to a problem I don't have.

As for encryption, I have exactly 2 encrypted stores, one dataset using zfs native encryption on my home fileserver, and the /home partition on my laptop, using dm-crypt. Unsurprisingly, one is mostly used to back up the other.

The most important thing to remember about encryption, where it applies to any threat more serious than "some random stole my laptop", is this.

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.