The officially official Devuan Forum!

MProG10

Member

Registered: 2026-05-27

Posts: 5  

init system is failing

Hello. I'm writing this post in requesting assistance booting Devuan GNU/Linux on an Android device. This is an ARM64 device. Upon running the init system, the system doesn't mount devtmpfs. The init system is failing. I do have CONFIG_DEVTMPFS set.

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.

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,671  

Re: init system is failing

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?

MProG10

Member

Registered: 2026-05-27

Posts: 5  

Re: init system is failing

I tried messing with the kernel boot arguments. No dice. This is my current kernel boot arguments.

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.

Last edited by MProG10 (Yesterday 11:44:44)

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,671  

Re: init system is failing

Hmm, that script; which filesystem has that script. Is that /init in an initrd?

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?

MProG10

Member

Registered: 2026-05-27

Posts: 5  

Re: init system is failing

This is an init script in an initramfs. Android is booted from an initramfs. I'm using the proprietary bootloader. The kernel does load, and does boot with Busybox init, but is failing with System V init. I don't have a serial setup. All I have is adbd.

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

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,671  

Re: init system is failing

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.

MProG10

Member

Registered: 2026-05-27

Posts: 5  

Re: init system is failing

Thank you for the help. As you pointed out, the init system loads udev. udev was missing. After installing the package, the system is booting successfully.

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

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,671  

Re: init system is failing

It may depend on which deboostrap variant you used. eudev (which provides the udev impementaiton for Devuan) is tagged as "important" so would be in the default variant, but e.g. not in the minbase variant.

MProG10

Member

Registered: 2026-05-27

Posts: 5  

Re: init system is failing

Odd. I haven't touched this flag. This is the command I issued.

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.

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,671  

Re: init system is failing

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.