Me too. I don't use fstab, I wrote a cron script that is executed @reboot on the clients. My setup is a bit special anyhow. The server is shut down at nigth when all clients are off, and woken up in the morning by the first client in the morning. It checks if the network is available, if the server can be pinged, if the shares have been setup. Then the shares are mounted on the client(s). Server and clients are encrypted, the server is on a RAID6.

I do not see any big difference between Debian and Devuan regarding the implementation of a nfs server and client. The guides you can find on the internet do apply for both in general.

I have started a file server on Sarge, first of all with Samba for the Windows PCs on my family network. When I started with dual booting with Linux on my home PC, I discovered that I could export the shares I had prepared for Samba easily for nfs too. I started off with nfs(3), and moved to nfs4 some years later. There are a few differences in the way you export the shares, but there is no relation to any init system.

On the client side, I wasn't successful with mounting the shares via fstab due to the fact that the file server was put to sleep at night, and it would wake up past the client, and it needed some additional time for decrypting the shares. So I created a script that is invoked by cron @reboot. The script checks if the server is online, then if the shares are exported, and then it mounts the shares. When the server is off the operation of my workstation isn't affected, just the shares aren't there. I am still using this proven and reliable approach nowadays.

That hash at the front is there to indicate that this is a command to be used with root priviligues.

Well, that does not happen by chance or arbitrary. There is a definite command at least in Excalibur:

apt modernize-sources

Has to be called deliberately.

Thanks, didn't know that. Good news, makes things a bit easier.

Not quite, there is one more thing to do and some remarks.
Before changing the sources to excalibur, you need to run the usrmerge app (I use apt instead of apt-get, I like the progress bar). If you don't do that you get an error message and the upgrade is stalled.

# apt install usrmerge

Then, as long as Excalibur still is testing, the sources.list must contain just one line:

deb http://deb.devuan.org/merged/ excalibur main contrib non-free non-free-firmware

And the usual precautions do apply: make a backup and remove/deactivate all foreign repos from your sources.list.

A check if the memory on the stick really is the advertized one can be done with the f3 utility.

The first thing I do with any USB stick I buy.

The Devuan installer is a pure text based installer, it does not need any graphics driver like nouveau ...

I never had any issues booting 5.0.0 or 5.0.1 on one of my PCs, no matter if legacy or uefi, except for when using Ventoy.

My guess: your PC has some strange configuration that does not like the basic settings the installer uses. Maybe related to your NVidea card (I only use AMD). And if 5.0.0 works, install with it, an apt update/apt full-upgrade installs everything to the latest version in the repo.

I regularly see this "Stopping early crypto disks" during system shutdown. But I consequently use encryption. Tells me the system is mostly down, and now cryptodisks are being closed as one of the last steps in the shutdown process.

Maybe this is a step that happens all the time? I don't know.

I have just raised a bug report against Debian:

Bug#1117664: lightdm: Per default it is possible to login as user root graphically

I do my partitioning before installation with gparted live. In a VM I use the installer but manual partitioning. I do not like the automatisms build in, in my eyes they are outdated in terms to size allowed. Usually too little. I want to determine size, order etc. myself based on a long time experience.

I have done that since the first tools came up on DOS like Partition Magic.

Definitely lightdm has a leak. lightdm allows root login. Since I do not use other DM's, I can't speak for their performance.

Based on a web research and a chat on the Devuan Developers IRC, I have identified two possible fixes.

1.) Add a line to /etc/pam.d/lightdm

auth required pam_succeed_if.so user != root quiet

2.) Set up a group that is allowed to login:

# groupadd dmlogin
# usermod -aG dmlogin urmel # urmel is a dummy. Replace with real usernames. Repeat for all other users that shall be permitted

Change /etc/pam.d/lightdm and add:

auth required pam_succeed_if.so user ingroup dmlogin

In both cases trying to login as root returns "wrong password".