I really can't think of any reason /var/run/dovecot would be a problem, and it's working that way just perfectly at the moment - stopping and starting (both via the init script and doveadm) does what it should WRT master.pid.
I guess it wouldn't hurt to try though.

/var/run -> /run
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=6593300k,mode=755)

Pretty sure that's a default config from the Debian init scripts... somewhere, sometime. This install has been a rolling upgrade since at least as far back as Squeeze.

I'll give that a poke and see how it goes (will involve much patient waiting OFC). At least there's no 'rm -f $PIDFILE' in it anyway...

Frankly I'm wondering why anyone would ship an init script that does rm -f on a pidfile without checking to see if the relevant process is really gone to begin with, but presumably this one has been working for people for some time, right?
I mean, at least the smbd init script does a basic 'ps $PID' check, but here there's nothing.
Unless I'm missing something obvious, it looks like it will remove the pidfile even if start-stop-daemon returns non-zero (i.e. returns early only on "2"). That isn't even half-arse fail-safe.
This looks like some generic template script TBH, one intended to be tweaked for things like dovecot that fork a bunch of processes.
And yes, I checked, it's the one shipped in the Debian package.

Then again, I guess I should probably shut up about the fragile init script untill I know it's really the problem.

Not sure what you're getting at here, I have no systemd anything anywhere socket activated or otherwise.

The only reason for 8.3 filenames is compatibility with operating systems and legacy software that lack LFN support... Those all went the way of the dinosaur in 1995.
Do you really have a need to read your files with 35+ year old DOS software?

I don't know about NTFS, but on VFAT at any rate these alternate filenames are autogenerated, so there's nothing to loose.

Probably, but I doubt it will be very useful as it depends on the native Windows drivers to access the hardware.

If fan and clock controls are what you're after, IIRC (I don't have any nvidia cards any more) that stuff is available in the GNU/Linux native nvidia control panel after setting the appropriate "coolbits" values. Check the arch wiki and/or the documentation that comes with the driver for details.

I'm sure your pet bats just love it.

Sarcasm and HiFi religious wars aside (though I think Harry would like a word), sure. If you just want to chuck the PCM stream at something else to make sense of, ALSAs default conversions are probably unhelpful.

In this case though, it appears we're dealing with a motherboard codec, and a realtek one at that. This is precisely the kind of device the ALSA defaults are aimed at.

That realtek chip has considerably worse SNR and frequency response than the last amp I built... And that one was based on a design from the early '80s.
Direct hardware access and high sample-rates would be completely pointless here even if the chipset supported hardware mixing, which it doesn't.

The notes I left myself in my asound.conf suggest that I have had problems in the past with Firefox (and apulse) using a default device that isn't a plug. I don't remember exactly why, but it gels with FF working if the OP removes that direct hw: routing.
The other problem, i.e. not using dmix with motherboard audio, should be pretty obvious.

It is indeed, but it's probably worth noting that the old soundcard-shuffle can also be prevented by passing the 'index' option to the module, e.g. in /etc/modprobe.d/alsa.conf.

It has nothing to do with systemd.
Many windows applications (especially games) like to use zillions of mutexes for synchronisation, this is not particularly well supported or performant on GNU/Linux, largely because native applications tend to use other methods.
Wine has three approaches for dealing with this: Internal emulation, which is slow, esync, which fakes it using filesystem calls but requires you to raise the maximum number of open file handles in /etc/security/limits.conf, or kernel futex support (fsync), which requires patches as I mentioned some posts back but provides near-native performance.

You don't strictly need esync or fsync, but IIRC lutris defaults to enabling esync for performance reasons. Failing to either turn this off in lutris or raise the open files limit will likely result in the kernel summarily killing your wine application.

Probably because it doesn't fit Debian's packaging requirements. It's documented in the wiki and readily available though. vOv

You have DXVK enabled for this game in lutris, but DXVK can't find the vulkan extensions it requires.
My guess (assuming you have GPU drivers installed and functioning correctly), is that the game you are trying to run is 32bit, your wine prefix is 32bit, and you are missing the 32bit vulkan libraries.

Maybe missing 32bit libgnutls, maybe missing .NET or other dependencies within wine...
Was this using the lutris install script?
I've never had any interest in the series in general, so I can't offer any specific advice for that game. The lutris script looks like it installs a bunch of stuff with winetricks to get the Epic Launcher (crapware I have no time for TBH) to run though.

In any case, you'd probably be better served by the lutris board and / or winehq for problems like this, they have far more to do with wine than Devuan. If this board had an "Unsupported Software" sub (kinda surprised it doesn't TBH), that's where Windows applications would belong.
Personally, I make a point of checking winehq and the lutris script repo to see if anyone has managed to get a particular game working before spending (and potentially wasting) any time on it.

FWIW, when setting up RAID systems I always keep /boot (and usually root as well) on a small RAID1.
A software RAID1 (mirror) is indistinguishable from a pair of identical partitions as far as the BIOS, bootloader and initrd is concerned, so even a rescue disk with no RAID support whatsoever can still get you into your boot/root FS.
One can even set up the two drives as alternate BIOS boot disks, so as to have bootloader redundancy as well.

As for the problem at hand, there seems to be some confusion as to whether this is a fakeraid or mdraid setup. If it's the former, you'll likely want to use dmraid and access your disks under /dev/mapper/. Mdadm has nothing to do with sata/fake/dmraid.
I have no experience with this personally, I've never used it, and I probably never will. The only time it has any benefit over software (md)RAID is when you're sharing an array with Winblows... And that's a dodgy proposition to begin with IMO.
There is a Debian wiki page on the matter though. Might be worth a read if you haven't already, looks like there are some traps regarding GRUB installation and UUIDs.

If this is actually an mdraid array, (much mention of mdadm in this thread)... I know Devuan can boot from RAID1 just fine, and I've set it up that way many times. I have no experience with RAID0 though, IMO an array that reduces reliability is an oxymoron, especially for the root filesystem.
One has followed the steps in the Debian wiki WRT to generating mdadm.conf and updating the initrd, no? IME that's all it should need.

Good to know sanity (and simplicity) still prevails.

It's kinda hard to keep up with this constant reinventing of the sound-server wheel TBH, I stopped paying attention years ago.
Didn't pulseaudio only recently graduate from buggy, CPU hungry, latency-inducing mess to something somewhat usable? And we're replacing it again already?

Maybe we can do pipewire-pulse-esd-arts-alsa-oss as well? I mean it's only frickin' audio, everyone needs more layers of confusion in their lives, right?

Well, if you can see the disk but booting from it fails to find the rootfs, that suggests that either your bootloader and/or fstab is incorrectly configured, or there are drivers missing from the initrd (but available and loaded later).
Either way, I'm having quite some difficulty understanding your posts.

Aside, I don't know why you keep mentioning PAE, it's completely irrelevant here.

In aid of ruling out PCMCIA issues (itself a very old standard not widely used any more), the docs for that board indicate it has a standard IDE port. Again I suggest trying to boot from that, passive adapters for CF cards are cheap, readily available, and should require no special driver or configuration.
Your PCMCIA-CF adapter almost certainly includes an IDE controller of it's own, and that's only going to complicate matters.

You're entitled to think whatever you want, of course.
My opinion on defragging ext* remains unshaken all the same though, and it's nothing to do with being a "purist". Ext* simply doesn't have the same rampant fragmentation issues that FAT and NTFS do.

At this point, I'm really starting to suspect ReFS is vaporware.

Solaris native, actually. But it does have a very nice BSD port.

Sun Microsystems released the ZFS source under their own take on a FOSS licence (the CDDL) shortly before they were devoured by Oracle, and actively developed ports are available for most BSD variants, MacOS and Linux.
Unfortunately It's not entirely clear whether the CDDL is compatible with the GPL, and there have been claims both ways. The FSF says it isn't, while the SFLC and Ubuntu claim that it is... As such, most GNU/Linux distros don't ship ZFS out of the box, requiring users to install it later.

For personal use the licence shenanigans is largely irrelevant, and full support on debian-based distros is just an 'apt install zfs-dkms zfsutils' away. You can even boot a GNU/Linux system from a ZFS pool, though I can't comment on Devuan's support for that specifically.

Uhh, defragging a volume causes "excessive" wear as well... But hey, if you really want to do that kind of thing, go nuts.

Yes and no, and it's a complete pain in the ass.
Fortunately, TK-Glitch maintains a wine build-system with features backported from proton, and compatibility is usually just as good as the real thing.
AFAIK there are no convenient binaries for debian-based distros (TK-Glitch is an Arch user BTW), but if you don't want to compile stuff yourself you can get also get them through Lutris. This is probably the easiest, most compatible option outside of installing Steam, and it's in the Devuan repos...
Or just swipe the Lutris wine tarballs for use with your frontend of choice. I get the distinct impression the Lutris devs don't like people doing this (an attitude that pisses me off no end), but they aren't particularly well hidden.

Aside, if you want optimal gaming performance with Wine, you'll probably want a kernel with the fsync and/or futex2 patchset. These can also be found on TK-Glitch's github, and IIRC the Xanmod and Liquorix kernels include them if you don't want to patch/build by hand.
I can't comment on how well those kernels behave with Devuan though, since the only machine I actually game on runs Gentoo.

IME the biggest problem with gaming on GNU/Linux isn't compatibility or performance any more (I get framerates within 1-2% of native), it's the rise of intrusive kernel-level anti-cheat / DRM.
Unfortunately there's no easy fix for that, so if your MMO habits include games that install ring-0 malware for "security" purposes or auto-ban wine users for "cheating", you'll probably want to keep a windows partition around...
Or better yet, vote with your wallet and just refuse to buy games that spy on you or try to hijack your system.

That's why there are so many warnings WRT the storage saving vs memory usage trade-off of dedup. In my case that trade isn't worth it, so I don't enable it.
IIRC the 64GB of RAM in my machine cost me ~120USD, and frankly I only installed 64 because I could. For a reasonable home-server pool size, ZFS (without dedup) will run just fine with 4.
More is better of course, as with most things. ZFS will use whatever it can get for its adaptive cache.

Of bigger concern hardware-wise is ECC and a UPS, though if you're serious about data integrity you'll have those already, regardless of filesystem choice.

On a Devuan-powered server, of course.

More specifically, on a largish (24TB usable) RAIDZ6 pool, served via NFS, SMB, and nextcloud. That machine lives in my house, where it should.
No Google, no Microsoft, no random "cloud" filestores. Includes webmail, dropbox-like filehosting & link sharing, PIM (contacts, calendar, tasks, notes) synchronisation to desktop and mobile, browser bookmark sync, password management, automated full-system backups for several other machines, the whole nine yards.

It doesn't have to, but it's probably a good idea.

There used to be a couple of defragmentation tools for ext4, but in 20+ years as a GNU/Linux user and unrepentant data-hoarder, I've never needed or wanted them.
Yes, you will get some fragmentation if you run your storage at 90+% capacity. The easiest answer is "don't do that", but even if you do the performance impact is nothing like the nightmare you get on a fragmented NTFS volume.

I will plug ZFS at any opportunity. It's kinda heavy on hardware requirements (particularly memory if you want good performance), but it more than makes up for that in featureset, reliability, and data integrity. No other filesystem comes even remotely close.
If you don't want to deal with ZFS (and out-of tree kernel modules), there's nothing wrong with ext4 on top of RAID and/or a sensible backup strategy either.

I never really had a life in the MS ecosystem, at least not the way it is now. The last version of Windows that stored any of my personal data was '98.
To be fair, I do still have an XP install on my old netbook, but that's strictly a tool for dealing with ancient hardware and holds no personal information whatsoever.

Oh, but it is

23-ish years here, and mine started out as a Slackware install, on a 486, in a (literal) pizza box.
Now it's an ebay-special dual xeon, shoehorned into a desktop case. New times, same old recycled hardware policy.

Indeed. Seconded.