* Customized Bags and Boxes
From: forrest.mypackagingpro @ 2026-06-08 16:28 UTC (permalink / raw)
To: initramfs
Hi,
We are a packaging company specializing in customized boxes and labels in all sizes, materials, and styles. We offer tuck boxes, rigid boxes, mailer boxes, retail boxes, shopping bags, and a wide range of other packaging.
Please share your packaging details (box size, quantity, and style), and we’ll be happy to assist you. We also provide design assistance.
Let me know if you have any questions or job that you would like to try us on.
Best regards,
Forrest Sage
Marketing Executive
My Packaging Pro.
^ permalink raw reply
* [PATCH v2] vfs: init/main.c: change comment and pr_err: opening /dev/console may fail
From: Askar Safin @ 2026-04-07 6:59 UTC (permalink / raw)
To: linux-kernel, linux-fsdevel, Christian Brauner, Alexander Viro,
Jan Kara
Cc: patches, kernel-janitors, Randy Dunlap, initramfs,
David Disseldorp
This patch is for VFS.
Today comment on console_on_rootfs says that opening /dev/console never
fails. This is false. The opening may fail if /dev/console is not
present in internal initramfs. So let's update the comment and pr_err.
I tried to fix the problem itself in [1], but the patchset was rejected,
so I will fix the comment and pr_err instead. :)
v1: https://lore.kernel.org/all/20260406090815.1495095-1-safinaskar@gmail.com/
v1 -> v2 changes: changed text and also moved it to pr_err (inspired by Al Viro)
Link: https://lore.kernel.org/all/20260219210312.3468980-1-safinaskar@gmail.com/ # [1]
Signed-off-by: Askar Safin <safinaskar@gmail.com>
---
init/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/init/main.c b/init/main.c
index 1cb395dd9..daf115d08 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1645,13 +1645,15 @@ 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 */
void __init console_on_rootfs(void)
{
struct file *file = filp_open("/dev/console", O_RDWR, 0);
if (IS_ERR(file)) {
- pr_err("Warning: unable to open an initial console.\n");
+ pr_err("Warning: unable to open an initial console. "
+ "You likely supplied your own internal initramfs, "
+ "make sure /dev/console is there.\n");
return;
}
init_dup(file);
base-commit: bfe62a454542cfad3379f6ef5680b125f41e20f4 (mainline)
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] vfs: init/main.c: change comment: opening /dev/console may fail
From: Askar Safin @ 2026-04-07 6:43 UTC (permalink / raw)
To: viro
Cc: brauner, ddiss, initramfs, jack, kernel-janitors, linux-fsdevel,
linux-kernel, patches, rdunlap, safinaskar
In-Reply-To: <20260406095452.GY3836593@ZenIV>
Al Viro <viro@zeniv.linux.org.uk>:
> ITYM "so if you supply your own internal initramfs, make sure /dev/console is there"
I want to write browser extension for expanding your acronyms like "ITYM".
Okay, I will fix in the next version.
--
Askar Safin
^ permalink raw reply
* Re: [PATCH] vfs: init/main.c: change comment: opening /dev/console may fail
From: Al Viro @ 2026-04-06 9:54 UTC (permalink / raw)
To: Askar Safin
Cc: linux-kernel, linux-fsdevel, Christian Brauner, Jan Kara, patches,
kernel-janitors, Randy Dunlap, initramfs, David Disseldorp
In-Reply-To: <20260406090815.1495095-1-safinaskar@gmail.com>
On Mon, Apr 06, 2026 at 09:08:15AM +0000, Askar Safin wrote:
> -/* Open /dev/console, for stdin/stdout/stderr, this should never fail */
> +/*
> + * Open /dev/console, for stdin/stdout/stderr, this may fail if you supplied
> + * your own internal initramfs without /dev/console
ITYM "so if you supply your own internal initramfs, make sure /dev/console is there"
^ permalink raw reply
* [PATCH] vfs: init/main.c: change comment: opening /dev/console may fail
From: Askar Safin @ 2026-04-06 9:08 UTC (permalink / raw)
To: linux-kernel, linux-fsdevel, Christian Brauner, Alexander Viro,
Jan Kara
Cc: patches, kernel-janitors, Randy Dunlap, initramfs,
David Disseldorp
This patch is for VFS.
Today comment on console_on_rootfs says that opening /dev/console never
fails. This is false. The opening may fail if /dev/console is not
present in internal initramfs. So let's update the comment.
I tried to fix the problem itself in [1], but the patchset was rejected,
so I will fix the comment instead. :)
Link: https://lore.kernel.org/all/20260219210312.3468980-1-safinaskar@gmail.com/ # [1]
Signed-off-by: Askar Safin <safinaskar@gmail.com>
---
init/main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/init/main.c b/init/main.c
index 1cb395dd9..40cfda9aa 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1645,7 +1645,10 @@ 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 may fail if you supplied
+ * your own internal initramfs without /dev/console
+ */
void __init console_on_rootfs(void)
{
struct file *file = filp_open("/dev/console", O_RDWR, 0);
base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2 (mainline)
--
2.47.3
^ permalink raw reply related
* initramfs-tools 0.151 release
From: Ben Hutchings @ 2026-04-01 14:24 UTC (permalink / raw)
To: initramfs, debian-kernel, kernel-team
[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]
This release adds some minor features:
- 3cpio is used instead of cpio, if available
- post-update hooks can be installed in
/usr/share/initramfs/post-update.d
Other changes:
- Fixed new shellcheck warnings
- Fixed various problems with the autopkgtests
The shortlog is below.
Ben.
Ben Hutchings (8):
Merge branch 'shellcheck' into 'debian/latest'
Merge branch 'wrap-and-sort' into 'debian/latest'
Merge branch 'fix-test-arm64' into 'debian/latest'
Merge branch '3cpio' into 'debian/latest'
Merge branch 'runparts_usr' into 'debian/latest'
Merge branch 's390x-timeout' into 'debian/latest'
Merge branch 'deterministic-boot' into 'debian/latest'
Releasing version 0.151.
Benjamin Drung (8):
Run wrap-and-sort
silence incorrect shellcheck SC2329
Fix shellcheck SC2268
mkinitramfs: move unknown compression warning earlier
mkinitramfs: introduce build_initrd_with_cpio
Use 3cpio for unmkinitramfs/lsinitramfs if available
Support 3cpio and prefer 3cpio over cpio
autopkgtest: increase timeout to 240s on s390x
Hector Cao (1):
tests fail on arm64 because they call qemu-system-arm64 with cpu=max the qemu fails to boot the VM with recent EDK2.
John Chittum (2):
d/tests refactor for explicit paths
d/t/qemu-net-iscsi: determinate boot by LABEL
Luca Boccassi (1):
update-initramfs: support loading post-update hooks from /usr/share/ too
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] init: ensure that /dev/console and /dev/null are (nearly) always available in initramfs
From: Askar Safin @ 2026-03-23 3:47 UTC (permalink / raw)
To: Rob Landley
Cc: brauner, ddiss, initramfs, jack, linux-fsdevel, linux-kbuild,
linux-kernel, nathan, nsc, patches, rdunlap, viro
In-Reply-To: <54f06055-c5ca-4b8f-9aed-065755e7c1b2@landley.net>
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
^ permalink raw reply
* Re: [PATCH 0/2] init: ensure that /dev/console and /dev/null are (nearly) always available in initramfs
From: Rob Landley @ 2026-03-10 12:51 UTC (permalink / raw)
To: Askar Safin
Cc: brauner, ddiss, initramfs, jack, linux-fsdevel, linux-kbuild,
linux-kernel, nathan, nsc, patches, rdunlap, viro
In-Reply-To: <20260307032258.2857157-1-safinaskar@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 0/2] init: ensure that /dev/console and /dev/null are (nearly) always available in initramfs
From: Askar Safin @ 2026-03-07 3:22 UTC (permalink / raw)
To: rob
Cc: brauner, ddiss, initramfs, jack, linux-fsdevel, linux-kbuild,
linux-kernel, nathan, nsc, patches, rdunlap, viro
In-Reply-To: <bd45c86c-e1ea-4995-bb00-df83cc873105@landley.net>
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
^ permalink raw reply
* Re: [PATCH 0/2] init: ensure that /dev/console and /dev/null are (nearly) always available in initramfs
From: Rob Landley @ 2026-02-24 19:02 UTC (permalink / raw)
To: Askar Safin
Cc: linux-fsdevel, Christian Brauner, Alexander Viro, Jan Kara,
Randy Dunlap, linux-kernel, linux-kbuild, initramfs,
David Disseldorp, Nathan Chancellor, Nicolas Schier, patches
In-Reply-To: <CAPnZJGAw9o8BetWs_wO2B6YD7mYuOopP0CwD=KCfOJXw2QU4Gg@mail.gmail.com>
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
^ permalink raw reply
* Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
From: Askar Safin @ 2026-02-23 23:04 UTC (permalink / raw)
To: Rob Landley
Cc: David Disseldorp, linux-fsdevel, Christian Brauner,
Alexander Viro, Jan Kara, Randy Dunlap, linux-kernel,
linux-kbuild, initramfs, Nathan Chancellor, Nicolas Schier,
patches
In-Reply-To: <6d34c95a-a2ea-46a4-b491-45e7cb86049b@landley.net>
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
^ permalink raw reply
* Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
From: Askar Safin @ 2026-02-23 21:41 UTC (permalink / raw)
To: David Disseldorp
Cc: brauner, initramfs, jack, linux-fsdevel, linux-kbuild,
linux-kernel, nathan, nsc, patches, rdunlap, rob, viro
In-Reply-To: <20260223121946.45b3c5b1.ddiss@suse.de>
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
^ permalink raw reply
* Re: [PATCH 2/2] init: ensure that /dev/null is (nearly) always available in initramfs
From: Askar Safin @ 2026-02-23 21:18 UTC (permalink / raw)
To: Rob Landley
Cc: linux-fsdevel, Christian Brauner, Alexander Viro, Jan Kara,
Randy Dunlap, linux-kernel, linux-kbuild, initramfs,
David Disseldorp, Nathan Chancellor, Nicolas Schier, patches
In-Reply-To: <e67898f6-4e33-428b-8498-b8b28f817bd9@landley.net>
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
^ permalink raw reply
* Re: [PATCH 0/2] init: ensure that /dev/console and /dev/null are (nearly) always available in initramfs
From: Askar Safin @ 2026-02-23 20:58 UTC (permalink / raw)
To: Rob Landley
Cc: linux-fsdevel, Christian Brauner, Alexander Viro, Jan Kara,
Randy Dunlap, linux-kernel, linux-kbuild, initramfs,
David Disseldorp, Nathan Chancellor, Nicolas Schier, patches
In-Reply-To: <a7cb199d-928d-4158-8f16-db7ae5309082@landley.net>
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
^ permalink raw reply
* Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
From: Rob Landley @ 2026-02-23 19:45 UTC (permalink / raw)
To: Askar Safin
Cc: brauner, ddiss, initramfs, jack, linux-fsdevel, linux-kbuild,
linux-kernel, nathan, nsc, patches, rdunlap, viro
In-Reply-To: <20260223173443.327797-1-safinaskar@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
From: Askar Safin @ 2026-02-23 17:34 UTC (permalink / raw)
To: rob
Cc: brauner, ddiss, initramfs, jack, linux-fsdevel, linux-kbuild,
linux-kernel, nathan, nsc, patches, rdunlap, safinaskar, viro
In-Reply-To: <7e309fc3-7d55-4e95-8dea-f164a7a96b6c@landley.net>
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
^ permalink raw reply
* Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
From: Rob Landley @ 2026-02-23 16:11 UTC (permalink / raw)
To: David Disseldorp
Cc: Askar Safin, linux-fsdevel, Christian Brauner, Alexander Viro,
Jan Kara, Randy Dunlap, linux-kernel, linux-kbuild, initramfs,
Nathan Chancellor, Nicolas Schier, patches
In-Reply-To: <20260223133357.0c3b8f8e.ddiss@suse.de>
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
^ permalink raw reply
* Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
From: Rob Landley @ 2026-02-23 1:27 UTC (permalink / raw)
To: David Disseldorp, Askar Safin
Cc: linux-fsdevel, Christian Brauner, Alexander Viro, Jan Kara,
Randy Dunlap, linux-kernel, linux-kbuild, initramfs,
Nathan Chancellor, Nicolas Schier, patches
In-Reply-To: <20260220105913.4b62e124.ddiss@suse.de>
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
^ permalink raw reply
* Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
From: David Disseldorp @ 2026-02-23 2:33 UTC (permalink / raw)
To: Rob Landley
Cc: Askar Safin, linux-fsdevel, Christian Brauner, Alexander Viro,
Jan Kara, Randy Dunlap, linux-kernel, linux-kbuild, initramfs,
Nathan Chancellor, Nicolas Schier, patches
In-Reply-To: <6d34c95a-a2ea-46a4-b491-45e7cb86049b@landley.net>
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
^ permalink raw reply
* Re: [PATCH 2/2] init: ensure that /dev/null is (nearly) always available in initramfs
From: Rob Landley @ 2026-02-23 1:15 UTC (permalink / raw)
To: Askar Safin, linux-fsdevel, Christian Brauner, Alexander Viro,
Jan Kara
Cc: Randy Dunlap, linux-kernel, linux-kbuild, initramfs,
David Disseldorp, Nathan Chancellor, Nicolas Schier, patches
In-Reply-To: <20260219210312.3468980-3-safinaskar@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
From: David Disseldorp @ 2026-02-23 1:19 UTC (permalink / raw)
To: Askar Safin
Cc: brauner, initramfs, jack, linux-fsdevel, linux-kbuild,
linux-kernel, nathan, nsc, patches, rdunlap, rob, viro
In-Reply-To: <20260220191150.244006-1-safinaskar@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 0/2] init: ensure that /dev/console and /dev/null are (nearly) always available in initramfs
From: Rob Landley @ 2026-02-23 0:17 UTC (permalink / raw)
To: Askar Safin, linux-fsdevel, Christian Brauner, Alexander Viro,
Jan Kara
Cc: Randy Dunlap, linux-kernel, linux-kbuild, initramfs,
David Disseldorp, Nathan Chancellor, Nicolas Schier, patches
In-Reply-To: <20260219210312.3468980-1-safinaskar@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 2/2] init: ensure that /dev/null is (nearly) always available in initramfs
From: Askar Safin @ 2026-02-21 0:16 UTC (permalink / raw)
To: ddiss
Cc: brauner, initramfs, jack, linux-fsdevel, linux-kbuild,
linux-kernel, nathan, nsc, patches, rdunlap, rob, viro
In-Reply-To: <20260220112606.551099f5.ddiss@suse.de>
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
^ permalink raw reply
* Re: [PATCH 1/2] init: ensure that /dev/console is (nearly) always available in initramfs
From: Askar Safin @ 2026-02-20 19:11 UTC (permalink / raw)
To: ddiss
Cc: brauner, initramfs, jack, linux-fsdevel, linux-kbuild,
linux-kernel, nathan, nsc, patches, rdunlap, rob, viro
In-Reply-To: <20260220105913.4b62e124.ddiss@suse.de>
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
^ permalink raw reply
* Re: [PATCH 2/2] init: ensure that /dev/null is (nearly) always available in initramfs
From: David Disseldorp @ 2026-02-20 0:26 UTC (permalink / raw)
To: Askar Safin
Cc: linux-fsdevel, Christian Brauner, Alexander Viro, Jan Kara,
Randy Dunlap, linux-kernel, linux-kbuild, initramfs, Rob Landley,
Nathan Chancellor, Nicolas Schier, patches
In-Reply-To: <20260219210312.3468980-3-safinaskar@gmail.com>
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
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox