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

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

[Askar Safin]

This patchset is for VFS.

See commit messages for motivation and details.

Askar Safin (2):
  init: ensure that /dev/console is (nearly) always available in
    initramfs
  init: ensure that /dev/null is (nearly) always available in initramfs

 .../filesystems/ramfs-rootfs-initramfs.rst    |  4 +--
 init/do_mounts.c                              | 11 ++++++++
 init/do_mounts.h                              |  2 ++
 init/initramfs.c                              |  2 ++
 init/main.c                                   |  6 +++-
 init/noinitramfs.c                            | 28 +++----------------
 usr/Makefile                                  |  2 +-
 usr/default_cpio_list                         |  6 +---
 8 files changed, 28 insertions(+), 33 deletions(-)


base-commit: 2961f841b025fb234860bac26dfb7fa7cb0fb122 (mainline)
-- 
2.47.3

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

[Askar Safin]

If we generate external initramfs as normal user using "cpio"
command, then we cannot put /dev/console there.

Fortunately, in this case default builtin initramfs will
contain /dev/console (before this commit).

But if we generate builtin initramfs instead, then we will
not have /dev/console at all. Thus the kernel will be unable to
open /dev/console, and PID 1 will have stdin, stdout and stderr
closed.

This problem can be solved by using gen_init_cpio.

But I think that proper solution is to ensure that /dev/console
is always available, no matter what. This is quality-of-implementation
feature. This will reduce number of possible failure modes. And
this will make easier for developers to get early boot right.
(Early boot issues are very hard to debug.)

So I put to the beginning of function "do_populate_rootfs" a code, which
creates nodes /dev, /dev/console and /root. This ensures that
they are always available even if both builtin and external
initramfses don't contain them.

The kernel itself relies on presence of these nodes. It uses
/dev/console in "console_on_rootfs" and /root in "do_mount_root".
So, ensuring that they are always available is right thing to do.

But then code in the beginning of "do_populate_rootfs" becomes
very similar to the code in "default_rootfs". So I extract
a common helper named "create_basic_rootfs".

Also I replace S_IRUSR | S_IWUSR with 0600 (suggested by checkpatch.pl).

Then nodes in usr/default_cpio_list become not needed,
so I make this file empty.

(In fact, this patch doesn't ensure that /dev/console is truly
always available. You can still break it if you create
bad /dev/console in builtin or external initramfs. So I
update comment on "console_on_rootfs".)

This patch makes default builtin initramfs truly empty.
This happens to match description in ramfs-rootfs-initramfs.rst.
But that description says that size of this initramfs is 134 bytes.
This is wrong. I checked: its size is 512 bytes (and default
builtin initramfs is always uncompressed). So I just remove that
number. While I'm there, I remove word "gzipped",
because builtin initramfs may be also uncompressed or compressed
using different algorithm.

Signed-off-by: Askar Safin <safinaskar@gmail.com>
---
 .../filesystems/ramfs-rootfs-initramfs.rst    |  4 +--
 init/do_mounts.c                              |  8 ++++++
 init/do_mounts.h                              |  2 ++
 init/initramfs.c                              |  2 ++
 init/main.c                                   |  6 +++-
 init/noinitramfs.c                            | 28 +++----------------
 usr/Makefile                                  |  2 +-
 usr/default_cpio_list                         |  6 +---
 8 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.rst b/Documentation/filesystems/ramfs-rootfs-initramfs.rst
index 165117a721ce..c6451692294f 100644
--- a/Documentation/filesystems/ramfs-rootfs-initramfs.rst
+++ b/Documentation/filesystems/ramfs-rootfs-initramfs.rst
@@ -133,9 +133,9 @@ All this differs from the old initrd in several ways:
 Populating initramfs:
 ---------------------
 
-The 2.6 kernel build process always creates a gzipped cpio format initramfs
+The kernel build process always creates a cpio format initramfs
 archive and links it into the resulting kernel binary.  By default, this
-archive is empty (consuming 134 bytes on x86).
+archive is empty.
 
 The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig,
 and living in usr/Kconfig) can be used to specify a source for the
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 55ed3ac0b70f..f911280a348e 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -519,3 +519,11 @@ void __init init_rootfs(void)
 			is_tmpfs = true;
 	}
 }
+
+void __init create_basic_rootfs(void)
+{
+	WARN_ON_ONCE(init_mkdir("/dev", 0755) != 0);
+	WARN_ON_ONCE(init_mknod("/dev/console", S_IFCHR | 0600,
+			new_encode_dev(MKDEV(5, 1))) != 0);
+	WARN_ON_ONCE(init_mkdir("/root", 0700) != 0);
+}
diff --git a/init/do_mounts.h b/init/do_mounts.h
index a386ee5314c9..907e9af77464 100644
--- a/init/do_mounts.h
+++ b/init/do_mounts.h
@@ -16,6 +16,8 @@ void  mount_root_generic(char *name, char *pretty_name, int flags);
 void  mount_root(char *root_device_name);
 extern int root_mountflags;
 
+void __init create_basic_rootfs(void);
+
 static inline __init int create_dev(char *name, dev_t dev)
 {
 	init_unlink(name);
diff --git a/init/initramfs.c b/init/initramfs.c
index 6ddbfb17fb8f..678b5050a7ac 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -717,6 +717,8 @@ static void __init populate_initrd_image(char *err)
 
 static void __init do_populate_rootfs(void *unused, async_cookie_t cookie)
 {
+	create_basic_rootfs();
+
 	/* Load the built in initramfs */
 	char *err = unpack_to_rootfs(__initramfs_start, __initramfs_size);
 	if (err)
diff --git a/init/main.c b/init/main.c
index 1cb395dd94e4..76f5320d3d4c 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1645,7 +1645,11 @@ static int __ref kernel_init(void *unused)
 	      "See Linux Documentation/admin-guide/init.rst for guidance.");
 }
 
-/* Open /dev/console, for stdin/stdout/stderr, this should never fail */
+/*
+ * Open /dev/console, for stdin/stdout/stderr, this should never fail,
+ * unless you intentionally make it fail, for example, by supplying
+ * wrong /dev/console in initramfs
+ */
 void __init console_on_rootfs(void)
 {
 	struct file *file = filp_open("/dev/console", O_RDWR, 0);
diff --git a/init/noinitramfs.c b/init/noinitramfs.c
index d1d26b93d25c..00bcf59cf05d 100644
--- a/init/noinitramfs.c
+++ b/init/noinitramfs.c
@@ -6,37 +6,17 @@
  * Author: Jean-Paul Saman <jean-paul.saman@nxp.com>
  */
 #include <linux/init.h>
-#include <linux/stat.h>
-#include <linux/kdev_t.h>
-#include <linux/syscalls.h>
-#include <linux/init_syscalls.h>
 #include <linux/umh.h>
 
+#include "do_mounts.h"
+
 /*
- * Create a simple rootfs that is similar to the default initramfs
+ * Create a simple rootfs
  */
 static int __init default_rootfs(void)
 {
-	int err;
-
 	usermodehelper_enable();
-	err = init_mkdir("/dev", 0755);
-	if (err < 0)
-		goto out;
-
-	err = init_mknod("/dev/console", S_IFCHR | S_IRUSR | S_IWUSR,
-			new_encode_dev(MKDEV(5, 1)));
-	if (err < 0)
-		goto out;
-
-	err = init_mkdir("/root", 0700);
-	if (err < 0)
-		goto out;
-
+	create_basic_rootfs();
 	return 0;
-
-out:
-	printk(KERN_WARNING "Failed to create a rootfs\n");
-	return err;
 }
 rootfs_initcall(default_rootfs);
diff --git a/usr/Makefile b/usr/Makefile
index e8f42478a0b7..de1ee4e78ef4 100644
--- a/usr/Makefile
+++ b/usr/Makefile
@@ -22,7 +22,7 @@ ramfs-input := $(CONFIG_INITRAMFS_SOURCE)
 cpio-data :=
 
 # If CONFIG_INITRAMFS_SOURCE is empty, generate a small initramfs with the
-# default contents.
+# contents, specified in default_cpio_list, which is currently empty.
 ifeq ($(ramfs-input),)
 ramfs-input := $(src)/default_cpio_list
 endif
diff --git a/usr/default_cpio_list b/usr/default_cpio_list
index 37b3864066e8..1df1ef08e504 100644
--- a/usr/default_cpio_list
+++ b/usr/default_cpio_list
@@ -1,6 +1,2 @@
 # SPDX-License-Identifier: GPL-2.0-only
-# This is a very simple, default initramfs
-
-dir /dev 0755 0 0
-nod /dev/console 0600 0 0 c 5 1
-dir /root 0700 0 0
+# Default initramfs is empty
-- 
2.47.3

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

[David Disseldorp]

On Thu, 19 Feb 2026 21:03:11 +0000, Askar Safin wrote:

> If we generate external initramfs as normal user using "cpio"
> command, then we cannot put /dev/console there.
> 
> Fortunately, in this case default builtin initramfs will
> contain /dev/console (before this commit).
> 
> But if we generate builtin initramfs instead, then we will
> not have /dev/console at all. Thus the kernel will be unable to
> open /dev/console, and PID 1 will have stdin, stdout and stderr
> closed.
> 
> This problem can be solved by using gen_init_cpio.
> 
> But I think that proper solution is to ensure that /dev/console
> is always available, no matter what. This is quality-of-implementation
> feature. This will reduce number of possible failure modes. And
> this will make easier for developers to get early boot right.
> (Early boot issues are very hard to debug.)

I'd prefer not to go down this path:
- I think it's reasonable to expect that users who override the default
  internal initramfs know what they're doing WRT /dev/console creation.
- initramfs can be made up of concatenated cpio archives, so tools which
  insist on using GNU cpio and run into mknod EPERM issues could append
  the nodes via gen_init_cpio, while continuing to use GNU cpio for
  everything else.

Thanks, David

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

[Askar Safin]

David Disseldorp <ddiss@suse.de>:
> I'd prefer not to go down this path:
> - I think it's reasonable to expect that users who override the default
>   internal initramfs know what they're doing WRT /dev/console creation.
> - initramfs can be made up of concatenated cpio archives, so tools which
>   insist on using GNU cpio and run into mknod EPERM issues could append
>   the nodes via gen_init_cpio, while continuing to use GNU cpio for
>   everything else.

This cannot be done in proper way.

Let's assume we want to build *builtin* initramfs using GNU cpio and
then concatenate to it an archive made by gen_init_cpio.

Then we want CONFIG_INITRAMFS_SOURCE to accept already existing cpio
archive AND file in gen_init_cpio format. But, according to
CONFIG_INITRAMFS_SOURCE docs in usr/Kconfig, this is not possible
(I didn't check whether this is true, I just have read the docs.)

This means that we should do this:

1. Generate an archive by invoking gen_init_cpio and concatenate it to
our preexisting archive
2. Create kernel config, while specifying resulting archive in
CONFIG_INITRAMFS_SOURCE
3. Build the kernel

Unfortunately, this will not work, because to invoke gen_init_cpio you
should build it first. And you cannot build it if there is no config
(I checked this).

So, we should do this:

1. Create kernel config, while specifying an archive in
CONFIG_INITRAMFS_SOURCE, which *DOES NOT EXISTS YET*
2. Build gen_init_cpio by invoking "make usr/gen_init_cpio"
3. Create an archive by invoking gen_init_cpio and concatenate it to
our preexisting archive. Put resulting archive to the path specified in
CONFIG_INITRAMFS_SOURCE
4. Build the kernel

Unfortunately, this will not work, either, because command
"make usr/gen_init_cpio" doesn't work in clean kernel tree even if
config exists (I checked this).

This means that the only remaining way is this:

1. Create *fake* kernel config
2. Build whole kernel (!!!)
3. Create an archive by invoking gen_init_cpio and concatenate it to
our preexisting archive
4. Create config, this time for real. Specify archive created in previous
step as CONFIG_INITRAMFS_SOURCE
5. Build the kernel, this time for real

I hope you agree that this is totally insane.

So, there is no proper way to create builtin initramfs by concatenating
archives created by GNU cpio and gen_init_cpio.

I think this is a bug in kbuild, and it probably needs to be fixed.

But I think that my patchset is a better approach. My patchset simply
ensures that /dev/console and /dev/null are always available, no matter
what. And thus my patchset side steps the whole issue.

Here are additional arguments in favor of my patchset.

* The kernel itself relies on presence of /dev/console in console_on_rootfs.
There is even comment there that currently says that opening of /dev/console
should never fail. (The comment is wrong, and this patchset fixes it.) So, if you
happen to supply builtin initramfs without /dev/console, then you will
build kernel, which violates its own assumptions. This will not be
detected until we actually try to boot the kernel. And even then it will
be hard to understand what exactly went wrong.

Why should we allow this failure mode? Let's instead ensure that this will
never happen. I. e. let's make sure that the kernel's asssumptions are always
true!

* My patchset makes the kernel not more complex, but more simple!
(28 insertions(+), 33 deletions(-).) Moreover, my patchset makes it
simpler not only in LoC sense, but in conceptual sense, too!
Currently codes in usr/default_cpio_list and init/noinitramfs.c are
very similar. It is possible that they will be out of sync in
some point of future.

By the way, noticing that they are out of sync is *very* hard. Consider
this scenario: usr/default_cpio_list contains this line:

nod /dev/null 0666 0 0 c 1 3

and init/noinitramfs.c contains this line:

init_mknod("/dev/null", S_IFCHR | 0666,
                        new_encode_dev(MKDEV(1, 3)));

Are these lines equivalent? You may think they are, but they are not.

init_mknod function above in fact creates node with different rights
due to umask of kernel thread. (And thus unprivileged users will be unable
to write to /dev/null...)

My patchset merges both codes into a single helper, thus making sure they
will never be out of sync. And thus my patchset reduces complexity of
the kernel.

* Currently it is okay not to put /dev/console to external initramfs.
But it is not okay not to put it to builtin initramfs. Why creating
builtin initramfs is harder than creating external initramfs? Why we make
lifes of developers in one of these cases harder without any reason?

Consider this scenario: somebody built kernel and external initramfs.
Everything works. Now they make this initramfs to be builtin.
Of course, they expect that everything will continue to work as before.
But it doesn't work. PID 1 doesn't print anything to console,
and you cannot even debug this, because it doesn't print anything to
console and you cannot see your debug printfs!

This clearly violates principle of least surprise.

-- 
Askar Safin

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

[David Disseldorp]

On Fri, 20 Feb 2026 22:11:50 +0300, Askar Safin wrote:

> David Disseldorp <ddiss@suse.de>:
> > I'd prefer not to go down this path:
> > - I think it's reasonable to expect that users who override the default
> >   internal initramfs know what they're doing WRT /dev/console creation.
> > - initramfs can be made up of concatenated cpio archives, so tools which
> >   insist on using GNU cpio and run into mknod EPERM issues could append
> >   the nodes via gen_init_cpio, while continuing to use GNU cpio for
> >   everything else.  
> 
> This cannot be done in proper way.
> 
> Let's assume we want to build *builtin* initramfs using GNU cpio and
> then concatenate to it an archive made by gen_init_cpio.
> 
> Then we want CONFIG_INITRAMFS_SOURCE to accept already existing cpio
> archive AND file in gen_init_cpio format. But, according to
> CONFIG_INITRAMFS_SOURCE docs in usr/Kconfig, this is not possible
> (I didn't check whether this is true, I just have read the docs.)

...

> This means that the only remaining way is this:
> 
> 1. Create *fake* kernel config
> 2. Build whole kernel (!!!)
> 3. Create an archive by invoking gen_init_cpio and concatenate it to
> our preexisting archive
> 4. Create config, this time for real. Specify archive created in previous
> step as CONFIG_INITRAMFS_SOURCE
> 5. Build the kernel, this time for real
> 
> I hope you agree that this is totally insane.

A two-phase build isn't insane alongside a custom internal initrams -
consider the case where the user wants to bundle kernel modules.
Buildroot has logic for this kind of two-phase build:
https://gitlab.com/buildroot.org/buildroot/-/blob/master/linux/linux.mk?ref_type=heads#L408
IIUC buildroot doesn't change the kernel config but uses an initial
dummy cpio which is updated for the final (incremental) build stage.

> So, there is no proper way to create builtin initramfs by concatenating
> archives created by GNU cpio and gen_init_cpio.

There are still other options:
- use a different initramfs archiving tool
- point GNU cpio at an existing /dev/console, or call mknod as root

> I think this is a bug in kbuild, and it probably needs to be fixed.
> 
> But I think that my patchset is a better approach. My patchset simply
> ensures that /dev/console and /dev/null are always available, no matter
> what. And thus my patchset side steps the whole issue.

I remain unconvinced. To me it still feels like a workaround for GNU
cpio's poor archive-contents-must-exist-locally interface.

Thanks, David

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

[Askar Safin]

On Mon, Feb 23, 2026 at 4:20 AM David Disseldorp <ddiss@suse.de> wrote:
> There are still other options:
> - use a different initramfs archiving tool

I'm trying to solve Rob's use case. He tries to write a tool for building
kernel and rootfs called "mkroot". The tool is written in pure shell
without any C. It should not have any external dependencies.
So it cannot depend on a custom cpio tool. The only cpio tools
allowed are gen_init_cpio and whatever cpio is present on the system.

> - point GNU cpio at an existing /dev/console

This will not work if we are inside some container, such as docker.
Container engines usually replace /dev/console with something else.

> or call mknod as root

mkroot should work as normal user

> I remain unconvinced

I still believe in my approach.

According to current kernel logic, /dev/console
magically works if you use external initramfs and doesn't work
if you use internal initramfs. I simply propose to make internal
initramfs work, too.

> To me it still feels like a workaround for GNU
> cpio's poor archive-contents-must-exist-locally interface.

I will repeat: mkroot should work not only with GNU cpio,
but with whatever cpio is present on the system.

So we should either fix *all* cpio implementations, or
fix the kernel. Obviously the second option is easier.

-- 
Askar Safin

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

[Rob Landley]

On 2/19/26 17:59, David Disseldorp wrote:
>> This problem can be solved by using gen_init_cpio.

It used to work, then they broke it. (See below.)

>> But I think that proper solution is to ensure that /dev/console
>> is always available, no matter what. This is quality-of-implementation
>> feature. This will reduce number of possible failure modes. And
>> this will make easier for developers to get early boot right.
>> (Early boot issues are very hard to debug.)
> 
> I'd prefer not to go down this path:
> - I think it's reasonable to expect that users who override the default
>    internal initramfs know what they're doing WRT /dev/console creation.
> - initramfs can be made up of concatenated cpio archives, so tools which
>    insist on using GNU cpio and run into mknod EPERM issues could append
>    the nodes via gen_init_cpio, while continuing to use GNU cpio for
>    everything else.

Who said anything about gnu? Busybox has a cpio, toybox has a cpio... 
once upon a time it was a posix command, removed from the standard for 
the same reason tar was removed, and that was just as widely ignored.

It's an archive format. There are tools that create that archive format 
from a directory.

The kernel itself had a fairly generic one one built-in, which you 
_could_ use to create cpio archives with /dev/console as a regular 
user... until the kernel guys decided to break it. I carried a patch to 
fix that for a little while myself:

https://landley.net/bin/mkroot/0.8.10/linux-patches/0011-gen_init_cpio-regression.patch

But I just got tired of fighting lkml.

> Thanks, David

Rob

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

[David Disseldorp]

On Sun, 22 Feb 2026 19:27:50 -0600, Rob Landley wrote:

> On 2/19/26 17:59, David Disseldorp wrote:
> >> This problem can be solved by using gen_init_cpio.  
> 
> It used to work, then they broke it. (See below.)
> 
> >> But I think that proper solution is to ensure that /dev/console
> >> is always available, no matter what. This is quality-of-implementation
> >> feature. This will reduce number of possible failure modes. And
> >> this will make easier for developers to get early boot right.
> >> (Early boot issues are very hard to debug.)  
> > 
> > I'd prefer not to go down this path:
> > - I think it's reasonable to expect that users who override the default
> >    internal initramfs know what they're doing WRT /dev/console creation.
> > - initramfs can be made up of concatenated cpio archives, so tools which
> >    insist on using GNU cpio and run into mknod EPERM issues could append
> >    the nodes via gen_init_cpio, while continuing to use GNU cpio for
> >    everything else.  
> 
> Who said anything about gnu? Busybox has a cpio, toybox has a cpio... 
> once upon a time it was a posix command, removed from the standard for 
> the same reason tar was removed, and that was just as widely ignored.

I'm not familiar with Busybox or toybox cpio. I've referred to GNU cpio
as it carries the archive-contents-must-exist-locally interface. Any
tool which uses the same interface will likely need to workaround the
same mknod EPERM issues for initramfs.

> It's an archive format. There are tools that create that archive format 
> from a directory.
> 
> The kernel itself had a fairly generic one one built-in, which you 
> _could_ use to create cpio archives with /dev/console as a regular 
> user... until the kernel guys decided to break it. I carried a patch to 
> fix that for a little while myself:
> 
> https://landley.net/bin/mkroot/0.8.10/linux-patches/0011-gen_init_cpio-regression.patch

This seems like a helpful feature to me.

Thanks, David

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

[Rob Landley]

On 2/22/26 20:33, David Disseldorp wrote:
>> It's an archive format. There are tools that create that archive format
>> from a directory.
>>
>> The kernel itself had a fairly generic one one built-in, which you
>> _could_ use to create cpio archives with /dev/console as a regular
>> user... until the kernel guys decided to break it. I carried a patch to
>> fix that for a little while myself:
>>
>> https://landley.net/bin/mkroot/0.8.10/linux-patches/0011-gen_init_cpio-regression.patch
> 
> This seems like a helpful feature to me.

It was, but I want mkroot to at least be _able_ to build with vanilla 
kernels, so couldn't depend on a feature upstream had abandoned.

The real problem isn't cpio, it's that the kernel interface for 
statically linking a cpio into the kernel wants you to point it at a 
directory of files for _it_ to cpio up, and when you do that you need 
root access (or fakeroot) to mknod.

You used to be able to point it at one of those generated files (and 
thus edit the file yourself to add the extra nodes), but that went away 
the same time they broke the rest of the interface.

> Thanks, David

Rob

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

[Askar Safin]

Rob Landley <rob@landley.net>:
> The real problem isn't cpio, it's that the kernel interface

So there is some bug here?

Then, please, describe properly this bug.

I. e. using usual formula "steps to reproduce - what I got - what I expected to see".

Also, does the kernel broke *documented* feature? If indeed some
*documented* feature doesn't work, then this is indeed very real bug.

I kindly ask you, please, please, describe this bug. I really want
to help you.

-- 
Askar Safin

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

[Rob Landley]

On 2/23/26 11:34, Askar Safin wrote:
> Rob Landley <rob@landley.net>:
>> The real problem isn't cpio, it's that the kernel interface
> 
> So there is some bug here?
> 
> Then, please, describe properly this bug.
> 
> I. e. using usual formula "steps to reproduce - what I got - what I expected to see".

I think that the kernel special case creating files in initramfs is the 
wrong design approach, but it would address the problem and it's what 
the kernel already did in a different codepath.

> Also, does the kernel broke *documented* feature? If indeed some
> *documented* feature doesn't work, then this is indeed very real bug.

Documentation/filesystems/ramfs-rootfs-initramfs.txt section "populating 
initramfs" described using the text file format back in 2005 
(https://github.com/mpe/linux-fullhistory/commit/7f46a240b0a1 line 135) 
and then commit 
https://github.com/mpe/linux-fullhistory/commit/99aef427e206f a year 
later described running usr/gen_init_cpio to create those files from a 
directory to give you an easy starting point to edit.

But I wrote that documentation, so it probably doesn't count.

> I kindly ask you, please, please, describe this bug. I really want
> to help you.
Back when the gen_init_cpio stuff let you create the file and consume 
the file separately so you could edit it in between, there was an easy 
way to address this problem by creating a cpio containing /dev/console 
as a regular user using the kernel plumbing. Then the kernel broke that 
and created a regression, which they decided to fix with special case 
code doing mknod within the kernel before launching PID 1, but only for 
one of two codepaths.

I think adding the special case hack to the other codepath is the wrong 
_WAY_ to fix it... but I guess that ship has sailed. I agree doing that 
can avoid the "init has no stdin/stdout/stderr" problem and thus address 
the issue.

(I still think if you have a CONFIG_DEVTMPFS_MOUNT config symbol, it 
should actually work, but that's a somewhat separate issue and a 
half-dozen patches ignored by linux-kernel for a decade now apparently 
argue otherwise...)

Rob

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

[Askar Safin]

Rob, I THINK I KNOW HOW TO SOLVE YOUR PROBLEM! (See below.)

On Mon, Feb 23, 2026 at 4:27 AM Rob Landley <rob@landley.net> wrote:
>
> On 2/19/26 17:59, David Disseldorp wrote:
> >> This problem can be solved by using gen_init_cpio.

I said this, not David.

> It used to work, then they broke it. (See below.)

So you have a directory with rootfs, and you want to add /dev/console
to it? Do I understand your problem correctly?

This is how you can solve it.

Option 1 (recommended).

Let's assume you have your rootfs in a directory /tmp/rootfs . Then
create /tmp/cplist with:

dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1

And add this to your config:

CONFIG_INITRAMFS_SOURCE="/tmp/rootfs /tmp/cplist"

This will create builtin initramfs with contents of /tmp/rootfs AND
nodes from /tmp/cplist
(i. e. /dev/console).

This will work, I just checked it.
No need to build the kernel twice.
Does this solve your problem?

Option 2.
Alternatively (assuming you already built gen_init_cpio) you can
create cpio with /dev/console using gen_init_cpio and then
concatenate it with cpio archive with your rootfs.

Unfortunately, this may require building the kernel twice, as I
explained in my previous letter in this thread. But this option
is still doable.

Option 3.
Yet another way: run

usr/gen_initramfs.sh /tmp/rootfs /tmp/cplist > some-output.cpio

(again, here /tmp/rootfs is a directory with your rootfs and
/tmp/cplist is a list of nodes.)

Unfortunately, this requires gen_init_cpio to be present, so, again,
similarly to option 2, this may require building the kernel twice.
But, again, this is doable.

In fact, gen_initramfs.sh accepts same options as CONFIG_INITRAMFS_SOURCE,
this is explained in
https://elixir.bootlin.com/linux/v6.19/source/Documentation/driver-api/early-userspace/early_userspace_support.rst#L70
.

Conclusion.
As I said, option 1 is the best in my opinion. It does not require
building the kernel twice,
and, as well as I understand, fully solves your problem.

If I miss something, please, tell me this.

I really want to help you, Rob.
I sent this patch, because I want to help you.

-- 
Askar Safin

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

[Askar Safin]

Binaries linked with bionic libc require /dev/null to be present,
otherwise they will crash before entering "main", as explained
in https://landley.net/toybox/faq.html#cross3 .

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.

This problem can be solved by using gen_init_cpio.

But let's make sure instead that /dev/null is always available as
a quality-of-implementation feature. This will reduce number
of failure modes and will make it easier for developers to
get early boot right. (Early boot issues are very hard to debug.)

Signed-off-by: Askar Safin <safinaskar@gmail.com>
---
 init/do_mounts.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index f911280a348e..3e71049b3dcf 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -525,5 +525,8 @@ void __init create_basic_rootfs(void)
 	WARN_ON_ONCE(init_mkdir("/dev", 0755) != 0);
 	WARN_ON_ONCE(init_mknod("/dev/console", S_IFCHR | 0600,
 			new_encode_dev(MKDEV(5, 1))) != 0);
+	WARN_ON_ONCE(init_mknod("/dev/null", S_IFCHR,
+			new_encode_dev(MKDEV(1, 3))) != 0);
+	WARN_ON_ONCE(init_chmod("/dev/null", 0666) != 0);
 	WARN_ON_ONCE(init_mkdir("/root", 0700) != 0);
 }
-- 
2.47.3

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

[David Disseldorp]

On Thu, 19 Feb 2026 21:03:12 +0000, Askar Safin wrote:

> Binaries linked with bionic libc require /dev/null to be present,
> otherwise they will crash before entering "main", as explained
> in https://landley.net/toybox/faq.html#cross3 .

It looks as though Bionic has extra logic to handle missing /dev/null
during early boot, although it's dependent on !is_AT_SECURE:
  https://cs.android.com/android/platform/superproject/main/+/main:bionic/libc/bionic/libc_init_common.cpp;drc=a7637a8f06f103c53d61a400a6b66f48f2da32be;l=400

I think this would be better addressed via documentation (e.g. in Bionic
or ramfs-rootfs-initramfs.rst).

Thanks, David

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

[Askar Safin]

David Disseldorp <ddiss@suse.de>:
> It looks as though Bionic has extra logic to handle missing /dev/null
> during early boot, although it's dependent on !is_AT_SECURE:
>   https://cs.android.com/android/platform/superproject/main/+/main:bionic/libc/bionic/libc_init_common.cpp;drc=a7637a8f06f103c53d61a400a6b66f48f2da32be;l=400
> 
> I think this would be better addressed via documentation (e.g. in Bionic
> or ramfs-rootfs-initramfs.rst).

Okay, I see, current bionic behavior is good.

Okay, I agree that this /dev/null patch is not necessary.

-- 
Askar Safin

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

[Rob Landley]

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

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

[Askar Safin]

On Mon, Feb 23, 2026 at 4:15 AM Rob Landley <rob@landley.net> wrote:
> Are you saying it's reoccurred, or that you plan to run a 5 year old
> userspace with a current kernel?

I was not aware about this. Okay, I agree that /dev/null is not needed.

> (Although I can't say I've regression tested an init task statically
> linked against bionic launching itself in an empty chroot recently
> either.

I tested current Android NDK LTS. I found that if stdin/stdout/stderr
already opened, then bionic binary will not crash if /dev/null is absent.
It will not crash even if PID is not 1 (so chroot should work).
But I didn't test what happens if stdin/stdout/stderr are closed.
So, assuming you already somehow got /dev/console, then
/dev/null is not needed.

According to code, bionic binary should work even if stdin/stdout/stderr are
closed, assuming that PID is 1.

--
Askar Safin

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

[Rob Landley]

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

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

[Askar Safin]

On Mon, Feb 23, 2026 at 3:17 AM Rob Landley <rob@landley.net> wrote:
> 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.

drivers/base/Kconfig says on CONFIG_DEVTMPFS_MOUNT:
> This option does not affect initramfs based booting

So CONFIG_DEVTMPFS_MOUNT works as documented.

(But I am not against your CONFIG_DEVTMPFS_MOUNT approach
if it helps you fix your problem.)

--
Askar Safin

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

[Rob Landley]

On 2/23/26 14:58, Askar Safin wrote:
> On Mon, Feb 23, 2026 at 3:17 AM Rob Landley <rob@landley.net> wrote:
>> 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.
> 
> drivers/base/Kconfig says on CONFIG_DEVTMPFS_MOUNT:
>> This option does not affect initramfs based booting
> 
> So CONFIG_DEVTMPFS_MOUNT works as documented.

I.E. they added that instead of merging any of my patches. Doubling down 
on "initramfs isn't a REAL root filesystem"...

*shrug*

> (But I am not against your CONFIG_DEVTMPFS_MOUNT approach
> if it helps you fix your problem.)

Oh I've been patching it locally for years. I'm only replying because I 
was cc'd.

Rob

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

[Askar Safin]

Rob, I kindly ask you to test this solution to your problems:

https://lore.kernel.org/all/CAPnZJGDDonspVK1WxDac2omkLJVX=_1Tybn4ne+sf3KyaAuofA@mail.gmail.com/

-- 
Askar Safin

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

[Rob Landley]

On 3/6/26 21:22, Askar Safin wrote:
> Rob, I kindly ask you to test this solution to your problems:
> 
> https://lore.kernel.org/all/CAPnZJGDDonspVK1WxDac2omkLJVX=_1Tybn4ne+sf3KyaAuofA@mail.gmail.com/

Your earlier suggestion that at some point they fixed the kernel build 
so I can go "/path/to/dir /path/to/file.txt" (which didn't _used_ to 
work, I tested it way back when) would presumably solve my problem 
without kernel patches.

I just haven't been programming much since Gavin "spyware" Newsom passed 
his stupid "age verification in the OS" bill 
(https://mstdn.jp/@landley/116194386057190345) where every cloud 
instance needs to report an "age" to Palantir, implying I'll have to 
take mkroot down before Jan 1st to avoid $7k/download fines, and I'm 
looking at maybe getting a job in healthcare or something.

Rob

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

[Askar Safin]

On Tue, Mar 10, 2026 at 3:51 PM Rob Landley <rob@landley.net> wrote:
>
> On 3/6/26 21:22, Askar Safin wrote:
> > Rob, I kindly ask you to test this solution to your problems:
> >
> > https://lore.kernel.org/all/CAPnZJGDDonspVK1WxDac2omkLJVX=_1Tybn4ne+sf3KyaAuofA@mail.gmail.com/
>
> Your earlier suggestion that at some point they fixed the kernel build
> so I can go "/path/to/dir /path/to/file.txt" (which didn't _used_ to
> work, I tested it way back when) would presumably solve my problem
> without kernel patches.

Cool! Please, write me when you actually test this.

-- 
Askar Safin