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

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