Sometimes one can use https://pkginfo.devuan.org to learn about packages and their dependencies. It doesn't offer much in terms of reflections on underlying motivations though.

You might want to try the newest devuan_excalibur_6.0-20250605_amd64_netinstall.iso which does include very recent firmware that possibly could help with the keyboard issue. That ISO is further improved to support boot via a Ventoy stick boot loading, which I'm guessing will suit you.

Use the shell phrase $((0x100)) to specify offset value 256; and similarly $((0x35feed63)) for offset value 905899363.

The parameters would be skip=?? for the infile and seek=?? for the outfile. The value is in block size counts.

The -nolisten tcp gets added to the Xorg command line by the /etc/X11/xinit/xserverrc start up script when invoked by startx. Aaccording to man startx the start up script may be overridden by the user (root?) who starts Xorg.

For experimentation you could edit that file, changing it to -listen tcp before restarting Xorg to see that it works. (It should)

@igorzwx if you know it all so well, why don't you turn that into helping rather than spewing innuendo and flaffing about other ways of doing things?
Or at least, keep it to your own threads.

Thanks. So when I installed it and try to use it, it does indeed complain. I have pure ALSA only on an excalibur installation.

Preliminary strace suggests it needs a "mixer" PCM

What does "Alsa complains of no sound server" mean?

Good find; appears to be a sysctl default with linux-image-6.1.0-28-amd64 (current daedalus). I guess someone found a "security" sticker and needed somewhere to put it so decided that "Oh! non-root users shouldn't be allowed to 'ping' willy-nilly"... or something.

Slightly odd though that you don't have the same with your debian setup, but perhaps that non-root user is more capable(?). (As we often find repeated: the packages in devuan are mostly debian's packages directly and not changed, other than the few that are forked and compiled by devuan)

Which kind of interface is set up for 192.168.26.252 ?

If it uses some pcap connection (like "user" networking in qemu), then it would only support IP level networking and ICMP would not be supported. I agree it's an LXC (on Devuan) issue although it may also be an admin choice of local networking. (I don't know LXC well enough to tell).

How is your networking set up?

Well, doesn't it actually depend on what one think of as "devuan"?

I think one should have a broad interpretation that aims to include everyone who think of themselves as a Devuan person. "Devuan Infrastructure" would include any and all means such a person would use for acting as Devuan person; in particular it then does include IRC groups at libera.chat even though the underlying networking and server equipment for that has a broader context than just for Devuan. (golinux likely meant only that the people providing libera.chat do so independently from any Devuan discussion group)

So in my mind, "Devuan infrastructure" would also include all mirroring of packages and ISOs and DNS service as well as the "health checking" of that, in addition to the git store and the build system and other services that explicitly are maintained in the name of Devuan.

The "central" part, i.e., the equipment paid by the registered devuan organisation, currently comprises three bare-metal hosts in Europe that together hold 28 virtual hosts with different service roles. Some of those are "inwards facing", such as package, ISO and docker image building (not to forget "amprolla", which prepares the repository indexes for the Devuan repositories) as well as the git store, bug tracking and more. A few services are for organisational purposes, such as email and backup, and some other are "outwards facing", such as web, forum, wiki and mailing list(s).

You should use the devuan-proposed-updates repository, and the soures.list line for that is

deb http://deb.devuan.org/merged daedalus-proposed-updates main contrib non-free non-free-.firmware

Pay special attention to the /merged URI which is what all devuan repositories have because devuan provides a merge of debian packages with an overlay of certain forked packages.

You tried to use the URI /devuan and that didn't work because that is wrong.

EDIT: you may omit some sections, like e.g. non-free but should at least include main.

To be a bit security minded, the script would rather isolate the one or two command(s) that actually require root, and make due wrapping for them, instead of "user transition wrapping" let root run X (display) programs.

And in a normal linux OS there is good use of the disk group, which would be a sufficient permission for running those disk device manipulation commands. (Possibly this has got lost since there are so many M$ heads putting their fingers into linux s/w nowadays; does your udev rules assign group permission for removable devices?)

I.e., to become root is just a "lazy convenience" in this case; easy to do, easy to talk about but sacrificing on security. (Though umount will require root). I do it all the time myself

Also, @greenjeans, (and for the benefit of the grandkids) the blkid verification does not in any way verify the result of the partition formating (by mkfs.vfat), but rather the result of sfdisk, i.e., that the partition table declares a vfat partition. You may use fsck for that although it'd typically be sufficient to accept the successful run of mkfs.vfat as evidence that formatting went well.