Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
Askar Safin <[email protected]> Tue, 24 Feb 2026 00:41:07 +0300
| 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 | <CAPnZJGC0kHEmAqHeTXwbcmuA0GqEOhDmCfjLRPRKff5DsEgW6w@mail.gmail.com> |
On Mon, Feb 23, 2026 at 4:20=E2=80=AFAM David Disseldorp <[email protected]> wr= ote: > 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. --=20 Askar Safin