You may follow that instruction without worrying about that link.

The link is likely a side effect of having installed multiple variant php*-fpm for experimentation, and then they configured nginx to use the link pathname for the socket instead of the direct pathname. In that way the nginx configuration need not be changed when the "alternatives" configuration is changed for a different php*-fpm version.

... OTOH it appears a runit boot does not start the display manager (lightdm) for a "standard" installation.

Perhaps that was your case?

I had to shift to vt2, login as root and run

/etc/init.d/lightdm start

by hand (to get a standard login happening in vt7).

@l3u: you should probably look up stuff about using su

A couple of years ago, su in Debian was changed to a variant that does not impose root's PATH without the - (login) option. That change, together with the slightly earlier change of excluding /sbin and /usr/sbin from user's default path has caused your kind of grievance for many people.

Unfortunately I didn't have any say in those changes, so here we are.

The name of the link is used to nominate the "suite" being loaded. That part of the scripting is the same for all suites. Other than that, the debootstrap software may differ between versions.

@xinomilo: Great. That mirror+file:pathname was new one for me.

My 3 TB usb disk says:

root@mini:~# hdparm -g /dev/sdb

/dev/sdb:
 geometry      = 2861588/64/32, sectors = 5860533164, start = 0

and also

root@mini:~# fdisk -l /dev/sdb
Disk /dev/sdb: 2.73 TiB, 3000592979968 bytes, 5860533164 sectors
Disk model: External USB 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

It seems an fstab entry like

none /sys/firmware/efi/efivars efivarfs ro 0 0

is fine.

Presumably because that mount is actually installed by mountkernfs.sh with the explicit label "none" but using the options as declared in fstab (if any), and the subsequent mounting by mount -a then ignores that fstab entry.

If you do want the label "efivarfs" then you'll need to touch up mountkernfs.sh accordingly.

ARM machines are typically different in their bootup for different machine types. I'm not sure exactly how your /boot looks but most likely there is a file there that identifies the kernel to boot and its initrd. It might be enough to edit that file for your new kernel and initrd.

(Possibly there is some name limitations which would force you to copy your kernel+initrd into existing names)

The newest chimaera iso for rpi3 seem to have a file /boot/config.txt identifying its kernel, and that boot kernel is named kernel8. It is an gunzip of the accompanying vmlinuz-5.10.110.

1) Afaik there is no "Devuan Desktop", and anyhow even if there were, the intent of developer choices are not always documented and readily available.

Most likely you are referring to the Desktop that you have installed with the desktop installer iso, and therefore that question might partly be answered by introspection.

2) Again, the intent of the developer choices underpinning the behaviour of "the Live version" or "the Desktop version" (i.e. "Your Desktop version") are not documented and readily available.

I also don't know what you mean in the claim that the one version allows something and the other doesn't;  presumably both are Devuan GNU/Linux systems of the same kernel version? Therefore they would offer the same potentials with respect to names of users.

Perhaps you mean that the programs you use in the two cases for adding users impose different constraints on their inputs?

E.g., if you would use adduser for adding users then it imposes constraints as documented in its man page.

@devuanuser: I'm sure you have a reason for not looking into /usr/sbin/

When you run the installer, it starts "partman" early on; a disk partitioning/setup tool.

Did you use that? Please describe the steps you took.

Since it's an UEFI boot, the machine needs at least one disk partitioned, with a GPT type partition table format, and then at least one EFI partition, which technically is a FAT type partition with a top level directory "/EFI".

Those are things you set up in the partitioning step.

In your case, you need to set up an EFI partition of, say, 100M first on one disk and use the rest as a RAID partition, and then divide the other disk similarly since RAID members need to be of the same size.

Then you set up a software raid device spanning those RAID partitions, and then you partition that to be your root filesystem (/). Unless you also want that RAID to be subdivided further.

By pkginfo.devuan.org/cgi-bin/policy-query.html?q=lxcfs it appears the coming upstream version is 5.0.2 (or later). That's for the coming release, daedalus (currently in testing) while the current stable and prior releases, chimaera, beowulf and ascii remain as they are.

You might also look it up at tracker.debian.org/pkg/lxcfs for a bit more detail of it's maintenance by Debian.

As for building it yourself, you possibly find some joy with https://backports.debian.org/