Well this is one of the (many) reasons installing packages from random websites / PPAs / blindly pasting commands from blog posts is considered a bad idea. Doubly so if you do it as root... But then if you're installing random .debs as root you are entirely responsible for your own mess.

Orly, "Unix commands"... As opposed to some other kind of commands, or is that just to sound extra scary?

On a more constructive note, a great many archive utilities can open .deb archives in memory, such as KDE's ark or the good old midnight commander. Personally I find browsing .debs with mc a lot nicer than using dpkg to print the contents, unless I want to pipe the output of course.

I fully expect any drive to be able to operate at 100% load continuously, provided it's external environmental limits are maintained.
It's over to the manufacturer to ensure that internal components don't overheat in said external environment.

The manual does not say "never write more than 100GB/hr", nor does it say "use only in LN2 cooled enclosures". It just boasts about transfer speeds, and those are mostly lies anyway.
A drive that overheats under load even when more than adequately cooled is a pile of junk, end of story. Even with a plastic case, those SSDs more than likely would have survived had crucial spent the few cents to add a thermal transfer pad.

These were in a fan-cooled aluminium drive cage, and that cage was maintaining a ~25c environment. The case of the SSD itself couldn't have been much above that.
Other drives in the same cage, including an OCZ model from 2013 and possibly the cheapest Kingston ever made, have never exceeded 35c under exactly the same workload.

I wasn't writing to them at anywhere near the fictitious "up to 500MB/s" specification either, not even 1/4 that in fact.
All I was doing was moving 100GB-ish batches of ~5MB files to the drives and moving them off again. Not "typical desktop usage", but certainly nothing I wouldn't expect any old drive to handle.

In short, it's Crucial's (complete lack of) internal thermal design that killed these, not my usage.
They're literally just a plastic box with a bare PCB rattling around inside. No screws, no heatsinking, nothing. Not even a bit of extra copper on the board for thermal mass.
I own USB3 pen drives that have thermal pads on the chips FFS.

Smartd is good for many things, temperature included.

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.