Welcome to Debian Stable (or more accurately, a distro with almost 1:1 tracking of the same).
Not having the latest SNS in the stable repos is not a bug, it's a feature. If a rolling-release with rapid updates is what you want, run a rolling release.

dd is simple, but it's also pretty slow as it'll copy everything, including empty blocks.

There's no need for a live distro here, regardless of the method used.
Just make the windows partition is not mounted and you can do it from Devuan (as the OP requested). dd is of course available by default, and partimage and clonezilla (which includes partimage) are in the repos.

$ cat /etc/devuan_version ; free -m
chimaera
               total        used        free      shared  buff/cache   available
Mem:          128887      102819       21226          61        4841       24548
Swap:          16383         179       16204

And this box doesn't even run a GUI

I will never understand this constant obsessing over memory, it's like some kind of religion here.

I have, and it has been. My question, i.e. are bugs in backports handled separately as they are in debian, appears to be answered by stint of said bug report being accepted.
It would still be nice if this was clearly explained on the bug reporting section of the devuan site.

That it was fixed so quickly is great. Logging being screwed up on multiple machines for multiple months before I noticed this, and me (who is not a package maintainer) being the only one who did... That isn't great at all.

I am well aware of it. Awareness does not make it any less of a problem when such borkage continues to slip through.

It happens in Devuan far more often than it does in Debian, and in far sillier ways.

You can take my word as: I am getting ever closer to migrating systems that I need to work reliably, without the intrusion of random "oops" class bugs in critical packages, over to Slackware or FreeBSD.

Apparently, Devuan derives from Debian and Veteran Unix Administrators... I took this to mean that the distro would cater to administrators (who, ya know, administer things, like production servers), and inherit the stability and reliabilty of Debian... Rather than turn into another hobby distro for anti-conformist tinkerers with old laptops.
I appear to be mistaken, if the apparent focus on desktop customisation and the attitude I see from many people here have any bearing on things.

As for my bug-tracking skills... That's kinda my point. If my relatively meagre expertise and attention are all that stands between Devuan and undetected broken packages in the repos, we have problems. How am I the only one to have noticed this, in rsyslog of all things?

I need some level of confidence that I can run headless servers, with unattended upgrades, and not have them break unexpectedly because somebody forgot to change the distro name in a default config or misplaced a patch in a shipping package version.
I especially need them not to stay broken through multiple updates - as happened here until I pointed out the borked script.

Hell, I don't have something as important as system logging go tits-up with a routine upgrade even on my bleeding-edge Gentoo desktop. If Devuan can't match the rollingist of roll-your-own rolling-release distros in terms of core package QA, I really don't know what purpose it serves.

What are we trying to achieve here anyway, Debian without the init upheaval or Debian without the stability and reliability?
Maybe FreeBSD is the answer after all.

Yeah, it's just the chimaera-backports package. Dog knows how that happened considering the backports are from daedalus to begin with.

Much as I too dislike pulseaudio, if one wants such niceties as on-the-fly switching of bluetooth sinks and whatnot, pure ALSA is a PITA.
While it is still far too complicated IMO, pipewire does at least solve some of the more glaring deficiencies of pulseaudio. Anyone wanting modern convenience features on a laptop or such will probably need one or the other.

FWIW, I have been playing with pipewire on my (openrc) Gentoo desktop too. Gentoo uses exactly the same pipewire-launcher.sh (anybody's guess who nicked it from who), and while it should work on any distro it does come with one problem - it has no facility for terminating pipewire / wireplumber when the user logs out.
That's not a big deal on a single-user system, nor is it a problem if one has logind set to kill user processes (which in turn breaks the old-school ability to background a task and leave it running after logout though).
If neither of those are true however, it results in stale pipewire processes left running and blocking the sound device when one user logs out and another logs in.

To solve this, I lifted a solution from slackware, namely using daemon to manage the equivalent of systemd "user-units".

The result is 3 autostart files (pipewire, pipewire-pulse, wireplumber), like e.g.:

[Desktop Entry]
Version=1.0
Name=Pipewire
Comment=PipeWire media server
Exec=/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
X-GNOME-HiddenUnderSystemd=true
X-KDE-HiddenUnderSystemd=true
X-systemd-skip=true

Zero launcher shell scripts or hacky anti-race sleeps, and the ability to do things like:

$ daemon --list
cdemu
pipewire
pipewire-pulse
pipewire-wireplumber
systembus-notify

As well as stopping, starting, and restarting these user daemons without resorting to pkill and co, giving them pid files, retrying failed starts, and binding to the user's logind session so they exit when they should.

Fractionally more effort (IIRC daemon is in the devuan repos already), but cleaner and more flexible IMO.
Just something to consider, FWIW I strongly suspect we're going to need something like daemon for more than just pipewire in future (I'm also using it for cdemu-daemon and the dbus-notifier part of earlyoom here), as systemd user-units become more popular.

To return to the OT, yes, this /.config and /.cache garbage is created on chimera (default desktop-live/refracta install) as well, and AFAICT the culprit is pulseaudio. Removing pulse will prevent their creation but not remove them if they exist, as they are not tracked by dpkg (for extra nastiness).

Whatever ones opinion of pulseaudio, it shouldn't be creating XDG configuration directories in the system root and so long as devuan is shipping it in the default desktop, I absolutely consider this a bug to be fixed.
I don't have a debian install to compare right now, but my suspicion is that this has to do with pulse assuming systemd and doing broken things when started as root by traditional init (i.e. when XDG_FOO isn't set).

I'd start by passing 'debug' on the kernel command line and seeing if it spits out anything more useful, then proceed to booting a different operating system to eliminate software entirely.
Most anything will likely do for that, but since the hardware was almost certainly designed to run Windows, as distasteful as it may be that's not a completely terrible option for testing.

As for isolating a hardware fault, the obvious answer would be to try to reproduce the problem in as minimal a configuration as you can. Remove expansion cards and extraneous peripherals, swap or replace PSU, memory modules, that kind of thing.
I don't see a smoking gun in your logs (though I do wonder what exactly pppd is up to at the end there), so a process of elimination would be the next logical step.

Aside, what Altoid said. I have plenty of old hardware, some of it going back to the mid '90s, and it still works just fine.
Assuming something is no good simply because it's old is kinda silly (as is insisting on DOS filename extensions when we have perfectly good magic for that matter).

IME, very little. unattended-upgrades has been available (as opposed to mandatory, ala microsoft) in debian and derivatives for as long as I can remember, and I have several machines that have been running it for well over a decade without any drama (with one notable recent exception, but that was a "devuan shipped nonfunctional configs", not "unattended-upgrades ate my lunch").

I probably wouldn't bother with it on a desktop pc, but for headless boxes, especially if you have many headless boxes you can't be arsed updating manually one at a time (or remembering they exist for that matter), it's pretty dang handy.

Wait, what? Are you telling me that this stupid "nobody uses TTYs any more" regression has actually been fixed?

Stick to the profile defaults then, and it's just Arch with more waste heat and fewer linking problems. @preserved-rebuild goes "Brrr"

As for broken compilers... Well, if you want to break your compiler that's optional as well.

Another prime example of why I'm not being nice any more. ^

If you want people to help you, ragging on the distro for not supporting the weird crap you're trying to do really isn't the way.
You come in here with an attitude like that, you're liable to get the same right back.

Reporting people who call you out is just another nail in the coffin, particularly if you're so childish as to make an exhibition of it. We don't owe you anything, and neither does Devuan - it even states such right there in the console when you log in.

Well yeah, obviously. If you tell nginx to incude a file, it's going to try to load it, and it's going to bitch if it doesn't exist.

modules-enabled should (IIRC, I actually run apache, but the config directory layout is much the same, it's a Debian thing) contains symlinks to files in modules-available, which in turn contain load_module directives pointing at dynamic module .so files.

Only you can explain the presence of that include line, it's certainly not in any default configuration shipped with Devuan.

That depends on whether or not you want to use module-geoip, no? I can't make that determination for you.

Ed. Since we're playing the edit game...

I think you should slow down, and go read the nginx manuals instead of jumping on random stackexchange and reddit posts.

Aside, while having your site definition in modules-enabled might work if you include it from some other config, it's pretty high on the list of "things that will cause a bunch of gratuitious confusion in about 2 hours time". Put it where it's supposed to go.

As HoaS implied in the very first reply to this thread, you can. With the not-refracta bootable install image.

If you insist on using the live image, a workaround has already been suggested.

Complaining about a missing feature in refracta installer achieves nothing. If you really want it, nobody is stopping you from implementing it yourself.

Because following some random blog post and using third-party executable installers rather than the repos is a sure-fire way to mess up your install?
The debian documentation and discussion boards are replete with warnings not to do this, and for good reason.

Other than that, if you want help you will need to provide a whole lot more information (with command output and such in code tags, not blurry screenshots) than just "why not working". Nobody here is psychic, and I for one am all out of patience for guessing games.