Yes, something is very odd. eudev is actually tagged as optional in the excalibur/main Packages file whereas it's tagged important in the ceres/main Packages file, and yet they have the same version code. Very odd but it does explain why it's not included in debootstrap.

Separately, I have a different note, that you might want to use binfmt_misc for "seamless" CPU emulation, in which case you can avoid the "foreign + second-stage" steps of debootstrap. The setup recepie on the build host for that would be like the following:

# apt-get install binfmt-support qemu-user-static
# modprobe binfmt_misc
# cat /usr/lib/binfmt.d/qemu-aarch64.conf > /proc/sys/fs/binfmt_misc/register

After that, your amd64(?) processor will execute arm64 binaries (within arm64 filesystem). I.e, it would let you run debootstrap in a single run, without the --foreign argument. Also, following the completed debootstrap, you may chroot into that filesystem (seamlessly) and run additional  apt-get install and whatnot, to complete the setup.

Either way you will need to add --include=eudev explicitly.

Ok, understood. Sounds good.

The very first thing to do in that init script is to mount /proc. Without that nothing else can be mounted. Possibly that is sufficient, but I think it should also mount /dev before any auto-mounting and mdev. Thus I suggest it starts as:

#!/bin/sh
mount -t proc proc /proc
mount -t devtmpfs devtmpfs /dev
mount -T /fstab -a
....

Just to note that all that mounting happens within the initrd (unpacked filesystem) and switch_root will unmount all before switching root.

Therefore you might need to also add a bind-mount onto /mnt/proc just before switch_root

It is the right thing to exec the openRC init binary, though of course the root filesystem needs to be duly populated. If you want to rely on the early /dev population by mdev, then that switch_root init script might further need to bind-mount /mnt/dev as well before switching.

Hmm, the sysvinit scripts for eudev (or udev) seems to mount the kernel's devtmpfs onto /dev (of the post-pivot root filesystem), so apparently your system boot-up doesn't include those.

Could you share your kernel boot command line arguments?

The point is that initscripts installs an ifupdown networking  "event handler", /etc/network/if-up.d/mountnfs, that processes /etc/fstab when interfaces are brought up, and both the daedalus and ceres versions of network-manager link up to that by means of the indicated script,
/etc/NetworkManager/dispatcher.d/01-ifupdown.

The excalibur version however lacks that script.

Why do you want to use the command seatd-launch dwl.
Is seatd running already?
Is there a dwl running already?

Why shouting?

libncurses5 is found in daedalus/main.
Assuming you are now on excalibur, one option is to add the old repository sources to your sources.list, e.g., by adding the following lines:

deb http://deb.devuan.org/merged daedalus main
deb http://deb.devuan.org/merged daedalus-security main

Then run

# apt-get upate aupdate
# apt-get install --no-install-recommends libncurses5

to get it installed (without including any "recommends" for it).

hth

Note that the alsa configuration for a program is loaded only once, at program start. So a configuration change like that will be in effect for the programs started after the change (only).

There is however a "refer" element that can be used in the configuration, to be expanded upon sink creation rather than just once initially. Your configuration must include such a "refer" element in order to have a configuration change take effect within an already started program.

Yes, Devuan installer ISOs since daedalus have included syslinux bootloaders only.

Quite possibly a Ventoy boot loader fails, especially if the newer versions have lost their syslinux ability, but in any case, Ventoy doesn't present the media as a bootable device so they might not work fully anyhow.

If you make sure that the Ventoy partition is labelled "Ventoy", and is of type exfat, then Devuan's Ventoy patching might kick in to make it work for you.

The "problem" for partitioning tools is probably that for a hybrid ISO, the first partition spans the whole disk, from sector 0 and to the last ISO sector. That span of course includes both the partition table and the second partition.  It also has the additional quirk, that the iso9660 interpretation has a block size of 2048 bytes per block, whereas the disk image view used in particular for the second partition is of 512 bytes per block.

I guess it's not easy for a graphical tool developer team to present and manage that kind of partition overlap which barely is understandable for normal people.

Did you update your copies of the repository meta files first (apt-get update)?

It does sound like you did, and then perhaps something has been removed from debian's pool. I'm not sure the chimaera merge is still happening automatically, so we'll need to check that.

@curranjm, yes, the init programs themselves are not, and should not be, very complicated.

All complexity around "init" comes with the designed/intended framework of the particular init system idea. This is a matter of documenting that framework clearly and openly so that service devlopers can shoe-horn their service control into that framework. The framework itself would be concerned with the ordering of service control activity, and how to detect and handle failure situations. Complex stuff.

I don't think anything much is gained by conflating the complexity of an init framework abstraction with (ideally) the simplicity of the technical operation of an init program.