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.

I have, once. I was not particularly impressed.

If we're talking about the desktop livecd, I expect that would be refracta installer.

Ditto.
I've never seen the traditional debian installer do anything funky either, but IME it's pretty trivial to screw up refracta, since it's really just a bunch of shell scripts, rsync, and yad/zenity.
There's no option go back if you miss something, precious little in the way of confirmation, and skipping or closing any of the random dialogs and terminal windows it spawns is likely to have it just truck on and copy the system regardless. i can totally imagine how one might end up in this kind of mess.
Perhaps I'm being unduly harsh here, but considering I was able to accidentally break the install process on my very first go (though not as badly as this example) it sure doesn't inspire much faith.

If the OP had provided proper reproduction steps, I might even be able to prove it too... oh well.

Random thought, I don't suppose we did anything... unexpected in the live session before running the installer, like, say mounting the existing /home filesystem somewhere?
It's just a thought mind, while I am looking at what I think is the current refracta scripts with one eye, I'm far too lazy to properly dig through that bunch of bash right now.

And another random thought, because I know HoaS just loves shellcheck...

shellcheck ./refractainstaller-gui | grep ^In | wc -l
143
shellcheck -S warning ./refractainstaller-gui | grep ^In | wc -l
52
shellcheck -S error ./refractainstaller-gui | grep ^In | wc -l
5

Ouch.
Yeah, I just use d-i. You should too.

If your install dates back to ascii (and you haven't let dpkg clobber the config files) you would have correct distro name, as this predates the fix getting lost and the package reverted to upstream Debian.

That's kinda my point WRT using ${distro_codename} instead of a hardcoded release. That's how Debian does it, and it allows unattended-upgrades to track the new release after a dist-upgrade with no manual changes to its configuration at all.

Ditto for the devuan-security line, I see no reason not to use ${distro_codename} there either, unless to create more packaging work.

I use "hack" and derivatives in their original meanings, always have.
Media droids conflating "hack" and "hacker" with the correct "crack" and "cracker" is not my problem, nor are ignorant muggles who do the same.

My problem with "Freedom Hacks" is the same problem I have with this board in general - a tendency to slap "freedom" on everything Devuan, as if it were some kind of philosophical fight against an oppressor, rather than a 90%+ Debian fork that retains support for multiple init implementations... Which is functionally what it is and always has been.
... That and it apparently being irresistible to preachers, rebels, "free thinkers", free speech advocates, conspiracy theorists and anti-establishment/anti-conformists in general.

Call that tutorial/howto sub something less ridiculous and I might be inclined... But not for this, because this is a packaging bug that got swept under the rug, plain and simple. It doesn't need a hack, it needs to be fixed.
Besides, if somebody needs a "freedom hack" post for a word replacement as obvious as this, I expect they probably need spoon-feeding and burping as well.

Sure. Unless everything has changed since I last used it, there's no requirement to actually use those functions though.

You can try and sell me on Wayland all you like, but until it does all the things X can do I really have very little use for it.

A simple framebuffer for the TTY? that I'll use, if infrequently. A rich networked display server for more complex GUI environments? cool.
Something in-between, whose primary targets appear to be "high refresh rate" (aka gaming woo) and better support for "devices"... Yeah, I don't really need that at all.

If Wayland was X+, I'd be keen. Right now it appears to be X- with a number of missing features, and were I to switch to it I'd end up running something in xwayland ~80% of the time anyway.
Why is replacing X with something that can't do all the things X can useful?

Debian/Devuan unstable is not a rolling release like Arch, it it a playground for new packages before they move to testing. Unstable and testing are not subject to the same quality control as stable, they can and do break at any time, and they are categorically not recommended for inexperienced users.

Do you actually need a 6.x kernel? Unless you have a very good reason for running 6.x, you're only setting yourself up for problems - particularly when coupled with third-party trash like nvidia's proprietary driver, and even more so with a bunch of patches nobody else here would touch with a long stick piled on top as well.

Even my non-mission-critical-canary gentoo desktop is still running 5.15. Why you ask? Because unless you have bleeding-edge hardware, there's nothing whatsoever to be gained from a shiny-new-shit kernel except aggravation.

This again? Seriously? Please keep your political trolling out of support threads.