Indeed.
Once you get in (or if you image the disk before reinstalling), it would be interesting to see the apt policy and debsums for those packages... Libraries don't change themselves (this is stable, not ceres, right?), barring some proper odd variety of disk corruption.

I'm not sure exactly what you mean by "remote dpkg install" here, but all you should need for a look around is a working mount command, the minimal live image would do nicely.

Incidentally, if that's some kind of thin terminal and you have a bunch of identical installs, you might like clonezilla's bare-metal PXEboot image restore features. It sure beats lugging HDDs around IME.

Well, the netinstall image doesn't include any mouse support, which I guess is a shame (but hey, it's tiny)... So some extra keystrokes and/or gratuitous use of cat might be needed.

Both the graphical and minimal live images can install the system with refractainstaller though, and they both have mouse-driven copy-paste, so there's a viable option if you run full disk encryption or something (what else?) that needs input of long strings to the installer.

Pulling in over a million lines of code to create a single directory.
Do we need a better example of the install-bloat and complexity-creep problems systemd creates?

As a stopgap until this is patched out in the devuan repos, you can whip up such a package with equivs and a symlink. Or just use the POC helpfully provided here.
It's quicker than patching and rebuilding php-fpm locally anyway

Opentmpfiles should be a drop-in, so long as systemd and the freedesktop crowd actually adhere to their own standards...

From his response to the various bug reports on this, and his and flat refusal to consider such a trivial change even when provided a patch, I guess Ondřej Surý is going on my personal "do not bother contacting, has irreconcilable attitude problems" list.
So long and thanks for all the fish, deb.sury.org. It was convenient while it lasted.

To be fair you shouldn't have to, something must be going wrong in the byzantine mess that is oracles init script...
The init script that I didn't see on cursory examination of the package because it's copied from /usr/lib/virtualbox by the byzantine postinst-common script, which is in turn called from another postinst script...
The init script that takes 20KB of shell to load 3 frickin modules, and clearly doesn't manage to do it reliably.
Sheesh, commercial vendors and their overengineering.

You could try debugging it, or you could just stick with those 3 lines in /etc/modules... I know which one I'd choose.

VirtualBox was in the repos back then (It was dropped for buster due to oracle being "uncooperative" IIRC), so presumably you were using those packages rather than the ones from oracle, no?

Well that all looks fine. Rats.

Does the root account actually have a password?

Fortunately almost every GUI today (with the notable exception of anything related to GNOME) works just fine with plain ALSA... So long as you don't compile it against pulseaudio, which unfortunately Devuan has, and it doesn't assume pulseaudio is available because libpulse0 was installed, which unfortunately Devuan does.

I'm going to go with "not".

Pretty much every sound-related application in the repos which can be linked to pulseaudio has been...

Because apparently upstream Debian just loves needless bloat these days, and dubious "features" like lobotomising your ability to configure your system properly by burying everything behind a GUI and a wall of XML or JSON (then adding a daemon or two and a dbus interface for good measure) is progress.

This is one of the reasons I'm not running Devuan (or any "modern" binary distro for that matter) on my desktops.
A minimal server install is still quite feasible, but as soon as you want a usable web browser or a DE, the tendency for distro maintainers to compile in everything including the kitchen sink bites you in the ass.

Devuan:
apt install <pretty much anything>
...
I see you're installing $software, would you like bloat with that? Too bad, we compiled everything we could find with '--install-lennart --enable-bloat --enforce-more-latency --everyone-uses-laptops --bug-policy=redhat'
The following 900 packages you don't need or want will be installed...

Gentoo:
USE="-pulseaudio alsa" emerge --newuse @world && emerge --depclean
...
Bask in the complete and satisfying eradication of libpulse, Firefox without nasty LD_PRELOAD hacks, XFCE with full ALSA support, etc. etc.

We certainly won't if your only interaction with this community is to drop in and say "Devuan is too hard, I'm going to use Mint."

Feel free to use whatever distro you want. If no-reading one-click installs are your thing, Devuan probably isn't for you.

If you have questions about Devuan, we're happy to provide answers.
If you have a problem to solve, we'll probably enjoy helping you.
If you have constructive ideas on how to make Devuan better (ideally with some code to share), we'll gladly discuss them.

If you're just here to (passive aggressively) complain and make pointless comparisons to $newb_friendly_distro though, I'm pretty sure this conversation is over.

What is with all the noise about this "brave" browser recently anyway? Is it demonstrably better than Firefox/Iceweasel or a degoogled chromium build?
Personally I'd be highly suspicious of a new browser that is advertised as heavily as this one appears to be...

Ed. Yup, that's pretty much what I expected. "Have our ads and tracking instead of theirs". Free cryptocurrency woo and virtue signalling included.
No thanks, I'll stick to my adblockers and javascript defangers.

Gentoo

Yeah, that'll take a while.
Dunno if a modern kernel would build on that, it has grown some. Guess I try it next time I have a free week to watch paint dry...

I think you mean 8MB, LOL. My 386 had 4, and it sure couldn't run Doom. 16MHz CPU, hercules monochrome graphics, and a spacious 80MB HDD.
Another dumpster special, and the first PC I could call "mine".

I still play (GZ)Doom from time to time, and it's still awesome. Fairly sure I have enough WADs to last me until the heat death of the universe too:

~ $ du -ch `find Games/Doom/Mods -iname '*.wad'` | tail -1
3.4G    total

Aside, I highly recommend timidity++ & the soundfonts from arachnosoft for full appreciation of Dooms epic soundtrack.

Because at the time (~2000 - 2003), a hopped-up 486 (120Mhz CPU, unofficial 40MHz bus, 2(!) VLB cards, 32MB RAM) junk-bin special was all I had.

The more recent install was simply a case of finding I still had enough old parts to assemble a retro box, and doing so for the hell of it.
IBM branded SFF 486 desktop, circa 1994. All the right bits, and worth a surprising amount nowadays as they're starting to become "vintage". Runs a stripped-down Gentoo, dual booting PC-DOS for DooM and Duke Nukem.
Ed. One of these. Top spec 100MHz model.

Plenty. The pentium brought many new instructions, as well as widespread PCI bus support.
Multimedia was especially painful on 486-class boxes, if you wanted to play MP3s at realtime you pretty much had to compile mpg123 with special optimisations. MMX changed all that.

Unless you're talking about really specialised embedded boards, there's no reason to use a 486 for anything but a nostalgia trip. i586 is better in every way... Well, except for that embarrasing FPU bug in the early pentium chips of course.

Most late-model 486 boards supported 64MB, but finding compatible SIMMs wasn't particularly easy. 32MB was a lot more common.
I believe there were some server boards that supported 128MB, but I've never actually seen one.

16MB was considered a standard desktop for most of the era, and if you had more than that you usually had to map an address-space hole for the video memory... So although mine had 32MB installed, I could only use 30MB due to my 2MB graphics card. Had to bugger about with kernel patches to get that working too IIRC.