Thread (4 messages) flat view 4 messages, 3 authors, 2025-10-06

Re: [PATCH 00/62] initrd: remove classic initrd support

From: Andy Lutomirski <luto@amacapital.net>
Date: 2025-09-17 18:00:45
Also in: linux-acpi, linux-alpha, linux-api, linux-arch, linux-block, linux-devicetree, linux-doc, linux-efi, linux-ext4, linux-fsdevel, linux-m68k, linux-mips, linux-patches, linux-riscv, linux-s390, linux-sh, linux-um, lkml, loongarch, sparclinux

On Mon, Sep 15, 2025 at 10:09 AM Rob Landley [off-list ref] wrote:
While you're at it, could you fix static/builtin initramfs so PID 1 has
a valid stdin/stdout/stderr?

A static initramfs won't create /dev/console if the embedded initramfs
image doesn't contain it, which a non-root build can't mknod, so the
kernel plumbing won't see it dev in the directory we point it at unless
we build with root access.
I have no current insight as to whether there's a kernel issue here,
but why are you trying to put actual device nodes in an actual
filesystem as part of a build process?  It's extremely straightforward
to emit devices nodes in cpio format, and IMO it's far *more*
straightforward to do that than to make a whole directory, try to get
all the modes right, and cpio it up.

I wrote an absolutely trivial tool for this several years ago:

https://github.com/amluto/virtme/blob/master/virtme/cpiowriter.py

it would be barely more complicated to strip the trailer off an cpio
file from some other source, add some device nodes, and stick the
trailer back on.  But it's also really, really, really easy to emit an
entire, functioning cpio-formatted initramfs from plain user code with
no filesystem manipulation at all.  This also makes that portion of
the build reproducible, which is worth quite a bit IMO.

--Andy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help