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.

Well, you should rather check pkgmaster.devuan.org/merged/dists/stable/main/source/Sources.gz
(which is what you use in the config for apt-mirror),
but the question is still why apt-mirror ends up with that uninitialized array slot.

In any case, you should replace "stable" with "daedalus" in your sources.list. The name "stable" will move to something else all of a sudden while "daedalus" will remain being what it is.

It appears to be a bug in apt-mirror; but you say this doesn't happen with an equivalent mirroring of a debian repo? Which one?