Colour me not at all surprised. While SLiM is indeed "slim", it's functionality is eclipsed by even the venerable XDM. User switching, bah, who needs that?

Don't ask me how, but SLiM somehow manages to not register login, session nor seat properly. At least that means it doesn't unexpectedly inhibit logind idle actions, unlike certain other disasters (SDDM).

If lightdm had a greeter (in the repos) that didn't drag in a bunch of gnome/GTK3 dependencies I'd be all for it...

For such a relatively simple function as a display-manager / graphical greeter, there really is a dearth of options that don't suck in some fundamental way.

I don't use nvidia, because the drivers are a constant source of aggravation... Much as ATI drivers used to be. How the tables have turned.

Because IGPU is too slow, lacks features, or is absent entirely?

Current GPU is using less than 5w, while writing this and doing general desktop stuff. When I want performance... You get what you pay for (in watts).

I don't understand obsessing over idle power consumption, particularly when it's on-par with a network card or additional SSD.

Depends on SKU, both have options with and without an IGPU.

Confusing to say the least, and not least because of the large number of RAID'ed partitions... Likely in squarely in the "easy to fix if I was sitting in front of it, very difficult to diagnose remotely" category.

To (attempt to) clarify:
Where is your /boot supposed to be? Is it a RAID array? If so, which disks/partitions should comprise it?
Where is your boot MBR/PBR and where is GRUB stage1 installed?

So sda1 and sdb1 are supposed to be independent devices, not part of an array? They contain duplicate but independent /boot filesystems, yes?

Partition type doesn't really decide whether a device is part of a RAID array, it's just a hint. Mdadm will scan for signatures and assemble what it can.
What does 'blkid' and/or 'wipefs -n' say about those disks (sda, sdb) and partitions (sda1, sdb1)? Do any of them have RAID signatures on them?

---

Both "legacy" BIOS (MBR) and UEFI (GPT) can usually boot just fine from MDRAID1, since the RAID headers (v<1.1) are at the end of the member devices and they are otherwise indistinguishable from normal partitions.
The latter (along with putting EFI on MDRAID1) is very much "unsupported" though, and will require diddling with GRUB config and/or use of the '--removable' flag when installing EFI entries.

MBR just needs an MBR/PBR (and some free blocks for the stage1 loader) and a partition GRUB can read, UEFI just needs an EFI/ESP partition the firmware can read. RAID1 works for both.

For (NVME/GPT) example:

nvme0n1     259:0    0 931.5G  0 disk  
├─nvme0n1p1 259:1    0   256M  0 part  
│ └─md0       9:0    0 255.9M  0 raid1 /boot
├─nvme0n1p2 259:2    0 927.3G  0 part  
│ └─md1       9:1    0 927.1G  0 raid1 /
└─nvme0n1p3 259:3    0     4G  0 part  [SWAP]
nvme1n1     259:4    0 931.5G  0 disk  
├─nvme1n1p1 259:5    0   256M  0 part  
│ └─md0       9:0    0 255.9M  0 raid1 /boot
├─nvme1n1p2 259:6    0 927.3G  0 part  
│ └─md1       9:1    0 927.1G  0 raid1 /
└─nvme1n1p3 259:7    0     4G  0 part  [SWAP]

/dev/nvme0n1p1       2048     526335     524288   256M EFI System
/dev/nvme0n1p2     526336 1945131007 1944604672 927.3G Linux filesystem
/dev/nvme0n1p3 1945131008 1953519615    8388608     4G Linux swap

/dev/nvme1n1p1       2048     526335     524288   256M EFI System
/dev/nvme1n1p2     526336 1945131007 1944604672 927.3G Linux filesystem
/dev/nvme1n1p3 1945131008 1953519615    8388608     4G Linux swap

/boot/EFI
├── BOOT
│   └── BOOTX64.EFI
└── gentoo
    └── grubx64.efi

Another box around here has a near idential layout with BIOS/MBR boot, /boot on RAID1, and grub stage1 installed to the MBR of both member devices... I'd have used that one as an example, but it's got 19 drives so it's a mite messy to wade through the lsblk output

Logind manages resources for interactive logins/physical "seats", and replaces the likes of consolekit for managing access to devices and executing privileged tasks on behalf of the user.
So yes, you can ask logind to do things like shut down the machine without sudo/being root - so long as logind knows you are logged in to a physical session ("seat"). You can do the same over e.g. ssh, but in that case it will ask you to authenticate.

As previously mentioned, network-manager is already a forked packge proivided by Devuan.

Cause: Failure to read the NEWS file or sufficiently test the default desktop install.
FTFY.

Why are you tring so hard to assign blame? This is not a Debian bug, nor is it Debian's fault. Rather it was an intentional, documented change (2 years ago at at that), which Devuan failed to react to.

Bug found, bug fixed. Case closed. If you really feel the urge to couch it in terms of the "us vs. them" nonsense so popular around here, at least try to get the facts straight.

Choice of init/rc makes very little difference to shutdown/reboot invocation, and none at all to suspend (unless you have some init scripts wired up to suspend/resume hooks ofc).

Suspend / hibernation has nothing to do with "hardware keys", beside the latter often being assigned to trigger such through ACPI button events.

Actually suspending the system is kernel functionality (usually with firmware help for bootstrapping a suspended system), with optional high-level interfaces (pm-utils etc.).
Those can be called however you like, be it a dedicated (i.e. pre-assigned) "hardware" key, remapping a "hardware" key with acpid, a custom key combination in X / whatever DE you use (I like meta+s), or a script / menu / whatever.

You'd set those up the same way as you ever would when writing to sysfs or running any other priveliged command. Sudo / doas / groups / suid / polkit / logind are all a matter of taste for giving normal users permission.

---

In general, I'd suggest [e]logind as  being the most convenient / compatible. I don't see any real reason for not wanting a login/seat manager of some kind on a primarily desktop/GUI setup, and it's also the easiest way to get X running as not-root (i.e. providing dynamic permissions for the nodes in /dev/ X needs)...
Unless of course you're going for knee-jerk "but it comes from systemd, no way" idological nonsense or hair-shirt level "minimalisim", in which case figuring out how you want to do seat management and permissions is up to you.

Likely well after every other BSD has, and one little bite at a time. FreeBSD has been arguing about allowing rust in base-system for a while (random typical example), but OpenBSD is conservative enough that they'll almost certainly wait and see how it goes there before even considering it.

In any case, the real arguments from devs and core maintainers (as opposed to the usual uninformed zealotry from joe-internet-rando in both camps) are more to do with the additional toolchain / build-times / maintainer workload than any of rust's supposed *magic security fixing* properties, "new"ness (or whatever idiotic, uninformed, non-technical objection zapper is still banging on about) or cult-like following.

Much as with rust in Linux, the debate among those at the coal-face is far more akin to "Rust can reduce common memory-management bugs, we should use it for (select) stuff where that's valuable" vs. "Multi-language codebases are a pain in the arse to maintain and I have much work already, if you want to do that, ensure you don't make a mess and/or make it my problem."

Rust is, after all, just another programming language. It's a programming language with better safeties on the common footguns than C, but one can write bad code in pretty much anything if so inclined. Hell, there's a bunch of low-level stuff you simply can't do in rust without some variety of 'unsafe foo ()', at which point the *safety magic* is off anyway.

---

Oh, the huge manatee.

When all you bring to a discussion is speculation based on personal "beliefs" or vague "someone once said" hearsay, random insults and outbursts of spite, and unsubstantiated value-judgements... Right or wrong really isn't the question, it's simply noise.

As for arrogance... No, the 10/10 arrogance award goes to people who shit on someone else's choice of tools and call them "newbs", without the slightest idea what it is they do, how to do it, or why choice of tool might matter to them.

Does one who does not know how to plumb (let alone in copper) trash-talk plumbers over their preferred brand of flux or filler rod? Would you listen to them if they did?

So maybe stop inviting it, by properly researching things before opining loudly and spitefully on them and the character of anyone who uses them?
Ya know, like the way "don't judge someone until you have walked a mile in their shoes" maps pretty well onto "don't judge a programming language until you have written some code with it"?

Also,

I should probably thank you for the entertainment, it's not like there's much else going on around here.

I read it the other way:

        # Using 'no !=' instead of 'yes =' to make sure async nfs
        # mounting is the default even without a value in
        # /etc/default/rcS

/etc/default/rcS as shipped with initscripts has '#ASYNCMOUNTNFS=yes', so

87          if [ no != "$ASYNCMOUNTNFS" ] ; then

is true, and the do_wait_async_mount loop runs until timeout or all mounts appear.

i.e. async mount (AKA just loop while waiting for the network initscript / manager / whatever to call the mountnfs hook) is default behaviour as per the comment, and /etc/init.d/mountnfs.sh only calls /etc/network/if-up.d/mountnfs itself if the user has explicitly disabled async mount.

...which neatly explains the conspicuous lack of attempts to mount NFS in Andre's logs on a fresh install with networkmanager, and the "works same as it always did" for those using ifup and static definitions in /etc/network/interfaces (me, and I suspect you as well).

Seems to me that if Devuan is going to use networkmanager in the default desktop install (connman is going away and all that) and we want fstab NFS mounts to work, the obvious solution would be for Devuan to fork the networkmanager package and put /etc/NetworkManager/dispatcher.d/01-ifupdown back where it belongs.

Of course. The whole 3 ancient architectures that are a "problem" have been using old kernels and custom patches so far, but whichever way you slice it their days are numbered. Nobody really cares, because the only productive use for such machines is as museum exhibits.

@zapper I'm not about to legitimize that childish outburst with a meaningful reply, if the best you have is "but your face" we are done here. Go back to kindergarten.

This kind of unsubstantiated, over-generalised speculation is exactly why

Do you code in rust? How about java? What have you written in python?
Do you personally know these "newbies" you claim are "enabled" by rust? Do you have the expertise to critique their code, or are you just talking out your arse on subjects you have no experience with (again)?

I suspected as much.

The traditional ifupdown setup runs /etc/network/if-up.d/mountnfs to scan fstab once the network interface is up.
I don't have a Devuan install with NetworkMangler to check, but IIRC NM should call the same via /etc/NetworkManager/dispatcher.d/01-ifupdown...

Which is suspiciously absent in the Excalibur package.

Poking about...

I don't use the thing myself, perhaps someone who does might explain how mountnfs is intended to be called by NM now (sans systemd, which would otherwise handle all this)? I dont see a new dispatcher hook file in initscripts (which provides /etc/network/if-up.d/mountnfs), or the Excalibur network-manager package itself.

@ralph.ronnquist: Unless I'm missing some other mechanism, I don't see how the setup in Excalibur is going to work as packaged, at least without a bunch of (somewhat arcane) end-user shenanigans creating a new hook to call mountnfs.
NFS in fstab isn't unusual and should really work OOTB for the default desktop install, was this configuration tested prior to release?

Without logs, crystal ball says boot service ordering issue - i.e. netmount runs before network is up. Especially likely if using some newfangled network "manager" rather than ifupdown.

Any pastebin or fileshare service that isn't obnoxious... or just use pastebinit.