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.

(I guess you didn't pick up spelling of both chimaera and devuan

Yes there is the problem that netboot has packaged kernel 5.10.0-22-686 (Debian package version 5.10.178-3) while the current chimaera repository sports kernel 5.10.0-32-686 (Debian package version 5.10.223-1).

But the distributed kernel + initrd.gz pair up in that version.
Which kernel + initrd do you use?

initramfs-tools.

Isn't it supposed to come with the SDK ?

Afaict, grub2 is too large to fit into the traditional 440 bytes of MBR and it does require a boot loader space of at least 1Mb prior to the first partition.
https://www.gnu.org/software/grub/manua … b.html#MBR

EDIT: There is however the issue of accessing an nvme drive which for grub requires a bios that implements the driver. This may mean that you must use the UEFI bios for booting with grub2, unless the legacy bios implements the nvme driver.

For UEFI boot, the boot loader is kept in a FAT filesystem, and the UEFI bios provides nvme driver support. grub2 documentation is not very clear about UEFI boot as it mixes it up with the notion of "secure boot", which is an optional function for UEFI boot. It also mingles it up with having a GUID Partiion Table (GPT) which is a different choice.

If you use UEFI boot, you install a different grub package, like grub-efi-amd64 and let it spin its magic.

Any serious attempt requires someone or a few to commit to put in the effort as well as maintain it into the future.

I think the best place to discuss seriously would be IRC #devuan-dev at libera.chat; perhaps set up a project at git.devuan.org to start with.