@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.

Commodification of software takes many forms and "appimages" is one of them.
Who cares?

Maybe having lz4 in /etc/initramfs-tools/modules (and an update-initramfs run) would work?
What's lz_4 ?

@altoid: did you dd with conv=fsync so that the program does not exit before data is actually written?

Next is to verify the USB by cmp $ISO $USB which should not find a difference until the end of the $ISO.

Yes that's the kernel version of the tar.gz. And the running system (unpacked initrd) probably has /lib/modules/5.10.0-22-686 with 687 kernel modules, but the problem seems to be that the "Download installer components" step looks online for more modules for that kernel, which it won't find.

Thanks. Yes, it would be good if that netboot could be updated to align kernel versions.

There's no easy way to come forward while waiting. Basically you'll need the kernel from kernel-image-5.10.0-32-686-di to replace "linux" from the tar.gz, and then those 687 modules to pack into the initrd.gz. All that from
http://deb.devuan.org/merged main/debian-installer
(plus a depmod run)...

EDIT: actually you might get away with just unpacking kernel-image-5.10.0-32-686-pae-di_5.10.223-1_i386.udeb and nic-modules-5.10.0-32-686-pae-di_5.10.223-1_i386.udeb (or without pae) into a directory tree. Then move /boot/vmlinuz to be your debian-installer/i386/linux and copy in /lib/modules/5.10.0-32-686-pae into an unpacked initrd tree. chroot into that to run "depmod 5.10.0-32-686-pae" before packing it up again, to become your debian-installer/i386/initrd.gz. Doing only that makes it work for "standard" network devices. I can drop a detailed command sequence if you wish.