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

David Disseldorp
2026-02-23T02:34:09Z

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