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.

debootstrap --foreign --arch=arm64 stable /tmp/devuan [url]http://deb.devuan.org/merged[/url]

Could be related to the mirror? I know http://deb.devuan.org/devuan is another mirror, though I don't use.

This is odd. How come udev was missing? I installed from Debootstrap. Maybe a bug in Debootstrap?

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.

I tried running /etc/init.d/rc manually. Nothing regarding devtmpfs is logged.

Without initrd, you probably will need boot root= and rootfstype= arguments and then the kernel might be able to find that /init script on the given root. This will still require the kernel to have built-in modules to handle mmcblk device, the partition table and the filesystem involved.

Do you know that the kernel loads and starts?

Do you have serial connectors to attach to, to get bootloading logs?

console=tty0,115200 loglevel=7

I was hoping loglevel=7 to log init messages. No dice. Tried including root=/dev/mmcblk0p54 as argument. No dice.

This device is running kernel 3.18. Here are the sources and defconfig. And here's the script I use to boot Devuan GNU/Linux.

#!/bin/sh

mount -T /fstab -a
mdev -s
mount /dev/mmcblk0p54 /mnt
exec switch_root /mnt /sbin/init

Note this other Android device is running kernel 3.10. The failure is unlikely to be related to the kernel version.

Could you share your kernel boot command line arguments?

Do you happen to know which are the required kernel configurations for a successful boot? I believe I'm missing a kernel configuration, since I had success on another Android device. This other device is ARM-based.

Unfortunately, I don't have much logs to read. And I know for a fact the init system is failing, since running

adb ls /dev/

returns an empty directory. Do you happen to know of a method to show init debug messages?

From a chroot environment, I see the init system doesn't mount devtmpfs either.