Re: [PATCH 2/2] init: ensure that /dev/null is (nearly) always available in initramfs

Rob Landley
2026-02-23T01:25:20Z

On 2/19/26 15:03, Askar Safin wrote:
> Binaries linked with bionic libc require /dev/null to be present,

Elliott fixed that one back in 2021:

http://lists.landley.net/pipermail/toybox-landley.net/2021-October/028766.html

https://android-review.googlesource.com/c/platform/bionic/+/1869594

Are you saying it's reoccurred, or that you plan to run a 5 year old
userspace with a current kernel?

> otherwise they will crash before entering "main", as explained
> in https://landley.net/toybox/faq.html#cross3 .

Oops, my documentation is out of date. Sorry. Added to the todo heap.

(Although I can't say I've regression tested an init task statically
linked against bionic launching itself in an empty chroot recently
either. last I checked I still hadn't convinced the android guys to use
initramfs at all, and then they had those 12k layoffs (apparently
copying twitter's mass layoffs) and I largely gave up on the idea of
turning Android into a self-hosting development environment any time soon.)

> So we should put /dev/null to initramfs, but this is impossible
> if we create initramfs using "cpio" and we are running as normal
> user.

You could just automount devtmpfs using the existing plumbing (and
touching far fewer files, and having common behavior between the static
and initrd loader codepaths).

I've been using this trick since 2015:

https://landley.net/notes-2015.html#01-01-2015

And first submitted it to linux-kernel in 2016:

https://lkml.org/lkml/2016/6/22/686

And resubmitted a half-dozen times since then. I linked to my most
recent one (tested against 6.17) last message, it's generally at
https://landley.net/bin/mkroot/latest/linux-patches/

Debian had a bug back in something like 2017 (when its initramfs
script's attempt to mount devtmpfs on /dev failed -- because it was
already there -- the untested error path would rm -rf everything) but
they said they were fixing it ~8 years ago, so...

I added workarounds to my reposts for a while (so new kernels could work
with old debians):

https://lkml.org/lkml/2020/5/14/1584

I don't remember if there's a newer post to this list than
https://lkml.iu.edu/2201.2/00174.html but nobody else ever seemed to
care. Oh well. I've posted new ones on my website every mkroot release,
regression tested against the then-current kernel.

It would be great if I didn't have to worry about
https://github.com/landley/toybox/commit/0b2d5c2bb3f1 again, but special
case code instead of using an existing generic mechanism? Eh, I suppose
that _is_ the modern Linux way...

Rob