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

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

> David Disseldorp <[email protected]>:
> > 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