Re: [PATCH 0/2] init: ensure that /dev/console and /dev/null are (nearly) always available in initramfs

Rob Landley <[email protected]> Sun, 22 Feb 2026 18:17:04 -0600
Newsgroups org.kernel.vger.initramfs,dev.linux.lists.patches,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kbuild,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 2/19/26 15:03, Askar Safin wrote:
> This patchset is for VFS.
> 
> See commit messages for motivation and details.

FYI I've been using (and occasionally posting) variants of 
https://landley.net/bin/mkroot/0.8.13/linux-patches/0003-Wire-up-CONFIG_DEVTMPFS_MOUNT-to-initramfs.patch 
since 2017.

What needs /dev/null? I haven't encountered that.

The problem with no /dev/console is init launches with no 
stdin/stdout/stderr (which is what happens for static initramfs made 
with normal user mode cpio, no easy way to insert /dev nodes into the 
filesystem you're archiving up and most cpio tools don't offer an easy 
way to hallucinate nodes). The problem with having no stderr when init 
launches is if anything goes wrong you can't get debug messages.

I have a shell script I run as PID 1 that mounts devtmpfs and then 
redirects stdin/out/err ala 
https://codeberg.org/landley/toybox/src/branch/master/mkroot/mkroot.sh#L111 
but THAT's fiddly because when the shell is opening the file it 
_becomes_ stderr (with the script _itself_ usually having been opened as 
stdin because first available filehandle) so the shell needs plumbing to 
dup2() them up to a high filehandle and close the original one and that 
tends not to get regression tested when anything changes because "we ran 
with no stdin/stdout/stderr is not a common case...

Having the kernel auto-mount devtmpfs (which it already has a config 
option for and all my patch does is make it work for initramfs) fixes 
this, because /dev/console is then available before launching /init.

How is manually editing initramfs _less_ awkward that automounting 
devtmpfs when the config symbol requests it?

Rob