[PATCH 01/62] init: remove deprecated "load_ramdisk" command line parameter, which does nothing

[PATCH 01/62] init: remove deprecated "load_ramdisk" command line parameter, which does nothing

[Askar Safin]

This is preparation for initrd removal

Signed-off-by: Askar Safin <safinaskar@zohomail.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 2 --
 arch/arm/configs/neponset_defconfig             | 2 +-
 init/do_mounts.c                                | 7 -------
 3 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 747a55abf494..d3b05ce249ff 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3275,8 +3275,6 @@
 			If there are multiple matching configurations changing
 			the same attribute, the last one is used.
 
-	load_ramdisk=	[RAM] [Deprecated]
-
 	lockd.nlm_grace_period=P  [NFS] Assign grace period.
 			Format: <integer>
 
diff --git a/arch/arm/configs/neponset_defconfig b/arch/arm/configs/neponset_defconfig
index 2227f86100ad..16f7300239da 100644
--- a/arch/arm/configs/neponset_defconfig
+++ b/arch/arm/configs/neponset_defconfig
@@ -9,7 +9,7 @@ CONFIG_ASSABET_NEPONSET=y
 CONFIG_ZBOOT_ROM_TEXT=0x80000
 CONFIG_ZBOOT_ROM_BSS=0xc1000000
 CONFIG_ZBOOT_ROM=y
-CONFIG_CMDLINE="console=ttySA0,38400n8 cpufreq=221200 rw root=/dev/mtdblock2 mtdparts=sa1100:512K(boot),1M(kernel),2560K(initrd),4M(root) load_ramdisk=1 prompt_ramdisk=0 mem=32M noinitrd initrd=0xc0800000,3M"
+CONFIG_CMDLINE="console=ttySA0,38400n8 cpufreq=221200 rw root=/dev/mtdblock2 mtdparts=sa1100:512K(boot),1M(kernel),2560K(initrd),4M(root) prompt_ramdisk=0 mem=32M noinitrd initrd=0xc0800000,3M"
 CONFIG_FPE_NWFPE=y
 CONFIG_PM=y
 CONFIG_MODULES=y
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 6af29da8889e..0f2f44e6250c 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -34,13 +34,6 @@ static int root_wait;
 
 dev_t ROOT_DEV;
 
-static int __init load_ramdisk(char *str)
-{
-	pr_warn("ignoring the deprecated load_ramdisk= option\n");
-	return 1;
-}
-__setup("load_ramdisk=", load_ramdisk);
-
 static int __init readonly(char *str)
 {
 	if (*str)
-- 
2.47.2

[PATCH 02/62] init: remove deprecated "prompt_ramdisk" command line parameter, which does nothing

[Askar Safin]

This is preparation for initrd removal

Signed-off-by: Askar Safin <safinaskar@zohomail.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 2 --
 arch/arm/configs/neponset_defconfig             | 2 +-
 init/do_mounts_rd.c                             | 7 -------
 3 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index d3b05ce249ff..f940c1184912 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5229,8 +5229,6 @@
 			Param: <number> - step/bucket size as a power of 2 for
 				statistical time based profiling.
 
-	prompt_ramdisk=	[RAM] [Deprecated]
-
 	prot_virt=	[S390] enable hosting protected virtual machines
 			isolated from the hypervisor (if hardware supports
 			that). If enabled, the default kernel base address
diff --git a/arch/arm/configs/neponset_defconfig b/arch/arm/configs/neponset_defconfig
index 16f7300239da..4d720001c12e 100644
--- a/arch/arm/configs/neponset_defconfig
+++ b/arch/arm/configs/neponset_defconfig
@@ -9,7 +9,7 @@ CONFIG_ASSABET_NEPONSET=y
 CONFIG_ZBOOT_ROM_TEXT=0x80000
 CONFIG_ZBOOT_ROM_BSS=0xc1000000
 CONFIG_ZBOOT_ROM=y
-CONFIG_CMDLINE="console=ttySA0,38400n8 cpufreq=221200 rw root=/dev/mtdblock2 mtdparts=sa1100:512K(boot),1M(kernel),2560K(initrd),4M(root) prompt_ramdisk=0 mem=32M noinitrd initrd=0xc0800000,3M"
+CONFIG_CMDLINE="console=ttySA0,38400n8 cpufreq=221200 rw root=/dev/mtdblock2 mtdparts=sa1100:512K(boot),1M(kernel),2560K(initrd),4M(root) mem=32M noinitrd initrd=0xc0800000,3M"
 CONFIG_FPE_NWFPE=y
 CONFIG_PM=y
 CONFIG_MODULES=y
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index ac021ae6e6fa..f7d53bc21e41 100644
--- a/init/do_mounts_rd.c
+++ b/init/do_mounts_rd.c
@@ -17,13 +17,6 @@
 static struct file *in_file, *out_file;
 static loff_t in_pos, out_pos;
 
-static int __init prompt_ramdisk(char *str)
-{
-	pr_warn("ignoring the deprecated prompt_ramdisk= option\n");
-	return 1;
-}
-__setup("prompt_ramdisk=", prompt_ramdisk);
-
 int __initdata rd_image_start;		/* starting block # of image */
 
 static int __init ramdisk_start_setup(char *str)
-- 
2.47.2

[PATCH 03/62] init: sh, sparc, x86: remove unused constants RAMDISK_PROMPT_FLAG and RAMDISK_LOAD_FLAG

[Askar Safin]

They were used for initrd before c8376994c86.

c8376994c86c made them unused and forgot to remove them

Fixes: c8376994c86c ("initrd: remove support for multiple floppies")
Cc: <stable+noautosel@kernel.org> # because changes uapi headers
Signed-off-by: Askar Safin <safinaskar@zohomail.com>
---
 arch/sh/kernel/setup.c                | 2 --
 arch/sparc/kernel/setup_32.c          | 2 --
 arch/sparc/kernel/setup_64.c          | 2 --
 arch/x86/include/uapi/asm/bootparam.h | 2 --
 arch/x86/kernel/setup.c               | 2 --
 5 files changed, 10 deletions(-)

diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index 039a51291002..d66f098e9e9f 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -71,8 +71,6 @@ EXPORT_SYMBOL(sh_mv);
 extern int root_mountflags;
 
 #define RAMDISK_IMAGE_START_MASK	0x07FF
-#define RAMDISK_PROMPT_FLAG		0x8000
-#define RAMDISK_LOAD_FLAG		0x4000
 
 static char __initdata command_line[COMMAND_LINE_SIZE] = { 0, };
 
diff --git a/arch/sparc/kernel/setup_32.c b/arch/sparc/kernel/setup_32.c
index 704375c061e7..eb60be31127f 100644
--- a/arch/sparc/kernel/setup_32.c
+++ b/arch/sparc/kernel/setup_32.c
@@ -172,8 +172,6 @@ extern unsigned short root_flags;
 extern unsigned short root_dev;
 extern unsigned short ram_flags;
 #define RAMDISK_IMAGE_START_MASK	0x07FF
-#define RAMDISK_PROMPT_FLAG		0x8000
-#define RAMDISK_LOAD_FLAG		0x4000
 
 extern int root_mountflags;
 
diff --git a/arch/sparc/kernel/setup_64.c b/arch/sparc/kernel/setup_64.c
index 63615f5c99b4..f728f1b00aca 100644
--- a/arch/sparc/kernel/setup_64.c
+++ b/arch/sparc/kernel/setup_64.c
@@ -145,8 +145,6 @@ extern unsigned short root_flags;
 extern unsigned short root_dev;
 extern unsigned short ram_flags;
 #define RAMDISK_IMAGE_START_MASK	0x07FF
-#define RAMDISK_PROMPT_FLAG		0x8000
-#define RAMDISK_LOAD_FLAG		0x4000
 
 extern int root_mountflags;
 
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index dafbf581c515..f53dd3f319ba 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -6,8 +6,6 @@
 
 /* ram_size flags */
 #define RAMDISK_IMAGE_START_MASK	0x07FF
-#define RAMDISK_PROMPT_FLAG		0x8000
-#define RAMDISK_LOAD_FLAG		0x4000
 
 /* loadflags */
 #define LOADED_HIGH	(1<<0)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1b2edd07a3e1..6409e766fb17 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -223,8 +223,6 @@ extern int root_mountflags;
 unsigned long saved_video_mode;
 
 #define RAMDISK_IMAGE_START_MASK	0x07FF
-#define RAMDISK_PROMPT_FLAG		0x8000
-#define RAMDISK_LOAD_FLAG		0x4000
 
 static char __initdata command_line[COMMAND_LINE_SIZE];
 #ifdef CONFIG_CMDLINE_BOOL
-- 
2.47.2

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

[Rob Landley]

On 9/12/25 17:38, Askar Safin wrote:
> Intro
> ====
> This patchset removes classic initrd (initial RAM disk) support,
> which was deprecated in 2020.

Still useful for embedded systems that can memory map flash, but it's 
getting harder to find embedded developers who consider new kernels an 
improvement over older ones...

> Initramfs still stays, and RAM disk itself (brd) still stays, too.

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. This means the open("/dev/console") fails, so 
init starts with no error reporting and we have to get far enough to 
mount our own devtmpfs or similar and open our own stdout/stderr before 
we can see any error output from init, which is kinda brittle.

I posted various patches to make CONFIG_DEVTMPFS_MOUNT work for initmpfs 
repeatedly since 2017, which also addressed it, but the kernel 
community's been hermetically sealed against outside intrusion for a 
while now...

https://lkml.iu.edu/hypermail/linux/kernel/2005.1/09399.html

https://lkml.iu.edu/2302.2/05597.html

> init/do_mounts* and init/*initramfs* are listed in VFS entry in
> MAINTAINERS, so I think this patchset should go through VFS tree.
> This patchset touchs every subdirectory in arch/, so I tested it
> on 8 (!!!) archs in Qemu (see details below).

Oh hey, somebody using mkroot. Cool. :)

My current "passes basic automated smoketests" list for 6.16 is:

aarch64 armv4l armv5l armv7l i486 i686 m68k mips64 mipsel mips powerpc 
powerpc64le powerpc64 riscv32 riscv64 s390x sh4 x86_64

I'm assuming that's your 8: arm, x86, m68k, mips, ppc, riscv, s390x, 
superh. (The variants are mostly 32/64 bit and bit/little endian, couple 
architecture generations in there. The old ones go out of patent first, 
you can always tell patents are about to expire and get generic clones 
when corporate shills start insisting that support for something REALLY 
NEEDS TO GO AWAY RIGHT NOW...)

The or1k, microblaze, and sh4eb targets mostly work: sh4eb has broken 
eithernet (never tracked down whether it's kernel or qemu that's wrong I 
just know they disagree), or1k doesn't know how to exit ala 
https://lists.gnu.org/archive/html/qemu-devel/2024-11/msg04522.html and 
microblaze never wired up -hda to their hard drive emulation 
https://lists.nongnu.org/archive/html/qemu-devel/2025-01/msg01149.html
but I haven't had the spoons to argue with IBM Hat developers about 
procedure compliance auditing.

I need to track down a decent qemu emulation for armv7m, last time I 
tried with vanilla was https://landley.net/notes-2023.html#23-02-2023 
which was not promising, I downloaded a pic32 qemu fork last week, but 
haven't had the spoons to follow up on that either. Or to ship a new 
toybox/mkroot release: I've had 6.16 kernel patches since the week it 
came out, unbreaking powerpc and adding fdpic support to sh4-mmu, but 
hobbyist friendly this community ain't. Sigh, I should get back on the 
(beating a dead) horse...

I had hexagon userspace working for a while ("qemu-hexagon ls -l") but 
no kernel for it: Taylor Simpson said he was going to post a 
qemu-system-hexagon patchset with a comet board emulation, but that 
architecture has no gcc support (there was a gcc fork on code aurora but 
they abandoned it when the FSF went gplv3) so it needs an llvm-only 
toolchain build with a non-vanilla musl libc fork... Honestly the 
problem is compiler-rt sucks rocks: I should cycle back around to 
https://landley.net/notes-2021.html#28-07-2021 but just haven't.

(Although part of the "Just haven't" is that I posted a patch to lkml 
making generic $CROSS_COMPILE prefixes automatically work whether your 
toolchain was gcc or llvm, and the response was literally "we decided to 
manually specify LLVM= on the command line so you must always do that 
and we're refusing your two line fix to NOT need to do that". No really: 
https://lkml.iu.edu/2302.2/08170.html

> Warning: this patchset renames CONFIG_BLK_DEV_INITRD (!!!) to CONFIG_INITRAMFS
> and CONFIG_RD_* to CONFIG_INITRAMFS_DECOMPRESS_* (for example,
> CONFIG_RD_GZIP to CONFIG_INITRAMFS_DECOMPRESS_GZIP).
> If you still use initrd, see below for workaround.

Which will break existing configs for what benefit?

I'm not convinced the churn improves matters. Presumably the kernel 
command line paremeter is still rdinit= and grub still uses the "initrd" 
command to load an external cpio.gz.

But I bisect to find breakage like that every release so I assume the 
other embedded linux developers... are mostly shipping 10+ year old 
kernels that use half the memory of today's.

> Details
> ====
> I not only removed initrd, I also removed a lot of code, which
> became dead, including a lot of code in arch/.
> 
> Still I think the only two architectures I touched in non-trivial
> way are sh and 32-bit arm.
> 
> Also I renamed some files, functions and variables (which became misnomers) to proper names,
> moved some code around, removed a lot of mentions of initrd
> in code and comments. Also I cleaned up some docs.

Now that lkml.iu.edu is back up (yay!) all the links in 
ramfs-rootfs-initramfs.txt can theoretically be fixed just by switching 
the domain name.

> For example, I renamed the following global variables:
> 
> __initramfs_start
> __initramfs_size

That already said initramfs, and you renamed it.

> phys_initrd_start
> phys_initrd_size
> initrd_start
> initrd_end

Which is data delivered through grub's "initrd" command. Here's how I've 
been explaining it to people for years:

1) initrd is the external blob from the bootloader's initrd= option.

2) initramfs is the extractor plumbing, _init code that gets discarded.

3) rootfs is (for some reason) the name of the mounted filesystem in 
/proc/mounts (because letting it say "ramfs" or "tmpfs" like normal in 
/proc/mounts would be consistent and immediately understandable, so they 
couldn't have that).

(No I don't know why it's called rootfs. Having things like df not show 
overmounted filesystems isn't special case logic, why...? The argument 
to special case this because you can't unmount it is like saying PID 1 
shouldn't have a number because it can't exit. I would happily call the 
whole thing initramfs... but it's already not.)

> to:
> 
> __builtin_initramfs_start
> __builtin_initramfs_size
> phys_external_initramfs_start
> phys_external_initramfs_size
> virt_external_initramfs_start
> virt_external_initramfs_end

Do you believe people will understand what the slightly longer names are 
without looking them up?

I'm all for removing obsolete code, but a partial cleanup that still 
leaves various sharp edges around isn't necessarily a net improvement. 
Did you remove the NFS mount code from init/do_mounts.c? Part of the 
initramfs justification back in 2005 was "you can have a tiny initramfs 
set up our root filesystem so most of the init special casing can go"... 
and then they added CONFIG_DEVTMPFS_MOUNT but made it ONLY apply to the 
fallback root after the system has decided NOT to stay on rootfs, and 
ignored my patches to at least make it consistent.

The one config symbol that really seems to bite people in this area is 
BLK_DEV_INITRD because a common thing people running from initramfs want 
to do is yank the block layer entirely (CONFIG_BLOCK=n) and use 
initramfs instead, and needing to enable CONFIG_BLK_DEV_INITRD while

And the INSANE part is they generally want a static initrd to do it so 
they're not using the external loader, but Kconfig has INITRAMFS_SOURCE 
under CONFIG_BLK_DEV_INITRD and it's a mess. Renaming THAT symbol would 
be good.

But then, CONFIG_BLOCK is hidden under CONFIG_EXPERT which selects 
DEBUG_KERNEL (INCREASING KERNEL SIZE!!!) and thus everybody who does 
this patches the kconfig plumbing to be less stupid anyway. So the 
problem isn't JUST renaming the symbol...

(Oh CONFIG_EXPERT is SO STUPID. It's got a menu under it, but 
CONFIG_BLOCK isn't in that menu, it's at the top of menuconfig between 
loadable module support and executable file formats, just invisible 
unless you go down into a menu and switch on a setting and then back out 
to go find it. WHY WOULD YOU DO THAT?)

> New names precisely capture meaning of these variables.

To you. I'm not entirely sure what virt_external means. (Yes I could go 
read the code. No I don't want to. I EXPECT to need context and 
refreshing stuff, but having it change out from under me since the LAST 
time I did that is annoying when it's "same thing, new name, because".)

It makes more sense to YOU because you changed it to smell like you. 
Meanwhile 35 years of installed base expertise in other people's heads 
has been discarded and developed version skew for anyone maintaining an 
existing system. (That's not a "never do this", that's a "be aware 
humans consistently have the wrong weightings in our heads for this".)

Personally I usually have to look it up either way. And am spending more 
and more of my time poking at older kernels rather because newer stuff 
has either removed support for things I need or grown dependencies. (And 
because there's 20 years of installed base still in various stages of 
use, I'm personally likely to spend more time looking at the old names 
than the new ones.)

> This will break all configs out there (update your configs!).
> Still I think this is okay,

Because you don't have to clean up after it.

> because config names never were part of stable API.

I can forward everyone who asks me questions to you, or just agree when 
they tell me it's yet another reason not to upgrade.

> Other user-visible changes:
> 
> - Removed kernel command line parameters "load_ramdisk" and
> "prompt_ramdisk", which did nothing and were deprecated

Sure.

> - Removed kernel command line parameter "ramdisk_start",
> which was used for initrd only (not for initramfs)

Some bootloaders appended that to the kernel command line to specify 
where in memory they've loaded the initrd image, which could be a 
cpio.gz once upon a time. No idea what regressions happened since though.

(Last new bootloader I was involved with that had to make it work used 
some horrible hack editing a dtb at a fixed offset, like the old "rdev" 
trick but more brittle. Because "device tree better" than human readable 
textual mechanism. Fixing ramdisk_start to work right sounded like a 
more sane approach to me, but...)

> I tested my patchset on many architectures in Qemu using my Rust
> program, heavily based on mkroot [1].

You rewrote a 400 line bash script in rust.

Yeah, that's a rust developer. (And it smells like you now...)

> I used the following cross-compilers:
> 
> aarch64-linux-musleabi
> armv4l-linux-musleabihf
> armv5l-linux-musleabihf
> armv7l-linux-musleabihf
> i486-linux-musl
> i686-linux-musl
> mips-linux-musl
> mips64-linux-musl
> mipsel-linux-musl
> powerpc-linux-musl
> powerpc64-linux-musl
> powerpc64le-linux-musl
> riscv32-linux-musl
> riscv64-linux-musl
> s390x-linux-musl
> sh4-linux-musl
> sh4eb-linux-musl
> x86_64-linux-musl

or1k and microblaze work, they just don't pass the full smoketest for 
reasons that shouldn't affect initramfs testing.

I'm still waiting for Rich to ship the next musl release to do new 
toolchains...

https://www.openwall.com/lists/musl/2025/08/04/1

> Workaround
> ====
> If "retain_initrd" is passed to kernel, then initramfs/initrd,
> passed by bootloader, is retained and becomes available after boot
> as read-only magic file /sys/firmware/initrd [3].

Common use case for eg romfs is memory mapped flash or rom, so the 
address range in question isn't actually ram anyway. Mostly on mmu 
systems you just don't want the mapping to go away, so the kernel can 
still reach out and read it.

> This is even better than classic initrd, because:
> - You can use fs not supported by classic initrd, for example erofs

Network block device was the most recent one I saw used, but it had a 
tiny initramfs to set up and switch_root into it...

(Network block device != network filesystem. I have a todo item to 
integrate nbd-server into mkroot/testroot.sh but "-hda works" is one of 
the things it's testing...)

> - One copy is involved (from /sys/firmware/initrd to some file in /)
> as opposed to two when using classic initrd

Embedded developers have always been reaching out and using mappable 
flash directly. Vitaly Wool's ELC talk in 2015 (about running Linux in 
256k of sram, yes one quarter of one megabyte) described the process:

https://elinux.org/images/9/90/Linux_for_Microcontrollers-_From_Marginal_to_Mainstream.pdf

Rob

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

[Andy Lutomirski]

On Mon, Sep 15, 2025 at 10:09 AM Rob Landley <rob@landley.net> 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

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

[Rob Landley]

On 9/17/25 13:00, Andy Lutomirski wrote:
> On Mon, Sep 15, 2025 at 10:09 AM Rob Landley <rob@landley.net> 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,

They fixed the behavior in one codepath. They left it broken in the 
other codepath. The kernel's behavior is inconsistent.

Look:

$ mkdir sub; cc --static -xc - <<<'int main() {puts("hello\n");if 
(fork()) reboot(0x01234567); for(;;);}' -o sub/init
$ (cd sub; cpio -o -H newc <<<init | gzip) > sub.cpio.gz
$ make allnoconfig KCONFIG_ALLCONFIG=<(tr ' ' \\n <<<'PANIC_TIMEOUT=1 
RD_GZIP BINFMT_ELF BLK_DEV_INITRD EARLY_PRINTK 64BIT SERIAL_8250 
SERIAL_8250_CONSOLE UNWINDER_FRAME_POINTER' | sed 
's/^/CONFIG_/;/=/!s/$/=y/')
$ make -j $(nproc)
$ qemu-system-x86_64 -kernel arch/x86/boot/bzImage -nographic -no-reboot 
-append console=ttyS0 -initrd sub.cpio.gz

You get a "hello" output near the end there. (You can add "quiet" to the 
-append but given that qemu can't NOT output its bios spam there's not 
much point.)

Now add INITRAMFS_SOURCE="sub" to the config and remove -initrd 
sub.cpio.gz from the qemu invocation:

$ make clean allnoconfig KCONFIG_ALLCONFIG=<(tr ' ' \\n 
<<<'PANIC_TIMEOUT=1 RD_GZIP BINFMT_ELF BLK_DEV_INITRD EARLY_PRINTK 64BIT 
SERIAL_8250 SERIAL_8250_CONSOLE UNWINDER_FRAME_POINTER 
INITRAMFS_SOURCE="sub"' | sed 's/^/CONFIG_/;/=/!s/$/=y/')
$ make -j $(nproc)
$ qemu-system-x86_64 -kernel arch/x86/boot/bzImage -nographic -no-reboot 
-append 'console=ttyS0'

No "hello" output, but it DOES shut down cleanly instead of giving you a 
panic trace so you know it ran the init binary.

All that changed was statically linking the initramfs instead of feeding 
it in through the initrd mechanism: the kernel behaves differently in 
those two codepaths, as I explained in the message you replied to.

(The above instructions assume an x86-64 host toolchain, poke me if you 
want arm64 instead...)

> but why are you trying to put actual device nodes in an actual
> filesystem as part of a build process?

I'm not. Doing that would require root access on the build machine to 
mknod in "sub" directory above. I build new images WITHOUT root access 
on the host.

There used to be a way to feed a the kernel config a text file listing 
what to make in the cpio file instead of just pointing it at a 
directory, and my old Aboriginal Linux build used that mechanism 
(generating such a file by hand, borrowing the kernel infrastructure but 
driving it manually) 15 years ago:

https://landley.net/aboriginal/about.html

https://github.com/landley/aboriginal/blob/master/sources/functions.sh#L403

But kernel commit 469e87e89fd6 broke that mechanism because somebody 
dunning-krugered it away ("I don't understand why we need this therefore 
nobody needs it"). I had a patch to unbreak it for a while:

https://landley.net/bin/mkroot/0.8.10/linux-patches/0011-gen_init_cpio-regression.patch

But as with so many patches, lkml wasn't interested. (I mostly post them 
so when copyright trolls try to rattle sabers I can point to an lkml web 
archive entry that got ignored, and explain precisely HOW much bad PR 
they're in for when they proceed.)

And again: you ONLY need this for static initramfs. Dynamic initramfs 
has code create /dev/console (at boot time, not build time):

https://github.com/torvalds/linux/blob/v6.16/init/noinitramfs.c#L27

That code ONLY gets called for the external initrd loader, it does NOT 
get called when a static initramfs image built into the kernel has a 
runnable /init. This is an inconsistency in the kernel behavior, which 
is what I'm objecting to.

> 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.

You mean like commit 595a22acee26 from 2017?

> I wrote an absolutely trivial tool for this several years ago:
> 
> https://github.com/amluto/virtme/blob/master/virtme/cpiowriter.py

Let's see, I wrote the initramfs documentation in 2005:

https://lwn.net/Articles/157676/

Was already correcting kernel developers on how it actually worked 
(rather than theoretically worked) in 2006:

https://lkml.iu.edu/hypermail//linux/kernel/0603.2/2760.html

I added tmpfs support to it in 2013 (because nobody else had bothered 
for EIGHT YEARS):

https://lkml.iu.edu/hypermail/linux/kernel/1306.3/04204.html

I've maintained my own cpio implementation in toybox for over a decade:

https://github.com/landley/toybox/commit/a2d558151a63

The successor to aboriginal (above) is a 400 line bash script that 
builds a dozen archtectures that each boot to a shell prompt in qemu:

https://github.com/landley/toybox/blob/master/mkroot/mkroot.sh
https://landley.net/bin/mkroot/latest/

With automated regression test infrastructure to boot them all under 
qemu and confirm that it runs, the clocks are set right, the network 
works, and it can read from -hda:

https://github.com/landley/toybox/blob/master/mkroot/testroot.sh

So yes I _can_ create my own bespoke C program to modify the file in 
arbitrary ways, I have my reasons not to do that, and have thought about 
them for a while now.

> 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.

So you're unaware that the kernel accepts concatenated archives, and you 
can just cat together two cpio.gz files and they'll extract. (In gzip 
anyway, I haven't tested the other compression formats. That's why I 
needed to do https://github.com/landley/toybox/commit/dafb9211c777 and 
95a15d238120 by the way.)

The problem is there's no portable existing userspace tool to create a 
cpio archive from non-filesystem data. Partly because there WAS a 
mechanism built into the kernel... until that guy broke it in 2020. When 
I'm making a squashfs I've got the -p option (presumably modeled on what 
the kernel used to do before it broke), but the host cpio hasn't got a 
way to specify that and adding my own bespoke format to toybox... I'm 
still trying to get 
https://lists.gnu.org/archive/html/coreutils/2023-08/msg00009.html into 
coreutils. (Alas lkml isn't the only 30 year old community that's gotten 
stiff and hard of hearing.)

I could emit cpio contents with xxd -r from a HERE document hexdump or 
something to append to the generated file, but xxd isn't installed by 
default on debian and echo \x is WAY ugly, and "here's a giant hex dump 
you're not expected to understand" isn't really something I want to add 
to an otherwise understandable build. Writing, building, and running my 
own bespoke tool in C to do it isn't really an improvement over the hexdump.

The kernel ALMOST already does this. The code just needs to be 
refactored a bit, preferably so there aren't two codepaths each with 
half the testing.

> 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.

Sigh. When I started working on reproducible builds they weren't called 
that yet, but I don't think digging for more links would help here. I 
did do a rollup of what I'm trying to accomplish 5 years ago though 
http://lists.landley.net/pipermail/toybox-landley.net/2020-July/011898.html 
and long long ago, there was https://landley.net/aboriginal/history.html 
and...

Query: is your "plain user code" built with "cc"? Do you reliably have a 
"cc" link, or do you need to explicitly say "gcc" or "clang"? The kernel 
needs to do the latter for some reason, and my patch to GET to the 
kernel to at least _try_ "cc" before falling back to the others was 
explicitly rejected...

> --Andy

Rob

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

[Askar Safin]

Rob Landley <rob@landley.net>:
> Still useful for embedded systems that can memory map flash, but it's

They can use workaround suggested in cover letter.

> While you're at it, could you fix static/builtin initramfs so PID 1 has 
> a valid stdin/stdout/stderr?

This is in my low-priority TODO list. I want to help you. I will possibly do this
after a month or two or three...

> I posted various patches to make CONFIG_DEVTMPFS_MOUNT work for initmpfs

My solution will be different: I will create static /dev/console and /dev/null
after unpacking of builtin and external initramfs. (/dev/null because of
that bionic problem you somewhere wrote.)

> Oh hey, somebody using mkroot. Cool. :)

Yeah, thank you for mkroot.

> Now that lkml.iu.edu is back up (yay!) all the links in 
> ramfs-rootfs-initramfs.txt can theoretically be fixed just by switching 
> the domain name.

Yes, I plan to replace them with lore.kernel.org ones. This is in my low-priority
TODO list, too.

> > For example, I renamed the following global variables:
> > 
> > __initramfs_start
> > __initramfs_size
> 
> That already said initramfs, and you renamed it.

Yes, to distinguish builtin and external initramfs.

> > phys_initrd_start
> > phys_initrd_size
> > initrd_start
> > initrd_end
> 
> Which is data delivered through grub's "initrd" command. Here's how I've 

My plan is to change "official" names for these things.
"initramfs" will refer both to .cpio archive itself and to loading
mechanism. Name of GRUB's "initrd" command will become "wrong, kept for
compatibility".

But I plan to do all these renamings after I fully remove initrd support,
which will happen in September 2026, as I explained in another email.

> 3) rootfs is (for some reason) the name of the mounted filesystem in 
> /proc/mounts (because letting it say "ramfs" or "tmpfs" like normal in 
> /proc/mounts would be consistent and immediately understandable, so they 
> couldn't have that).

I totally agree. I want to change it to ramfs/tmpfs. But this change
may break something, so I think we need some strong motivation to
do this. So I will wait for removal of nommu support. Arnd Bergmann said
"NOMMU removal maybe 2027" ( https://lwn.net/Articles/1035727/ ,
https://static.sched.com/hosted_files/osseu2025/75/32-bit%20Linux%20in%202025%20%28OSS%20Europe%29.pdf ,
slide 20). (Also he said 32-bit support will be removed, too.)
After that I will remove ramfs (yeah, I love to remove things),
and, while we are here, I will rename "rootfs" to "tmpfs" in
/proc/mounts (hopefully I will get away with this).

> > __builtin_initramfs_start
> > __builtin_initramfs_size
> > phys_external_initramfs_start
> > phys_external_initramfs_size
> > virt_external_initramfs_start
> > virt_external_initramfs_end
> 
> Do you believe people will understand what the slightly longer names are 
> without looking them up?

No. But I still hope new names are better. As I said above, all these
will be named "initramfs" under my new plan. But again, all these
will happen after full initrd removal, which will happen in Sep 2026.

> I'm all for removing obsolete code, but a partial cleanup that still 
> leaves various sharp edges around isn't necessarily a net improvement. 
> Did you remove the NFS mount code from init/do_mounts.c? Part of the 

Okay, I put this to my low-priority TODO list.

> The one config symbol that really seems to bite people in this area is 
> BLK_DEV_INITRD because a common thing people running from initramfs want 
> to do is yank the block layer entirely (CONFIG_BLOCK=n) and use 
> initramfs instead, and needing to enable CONFIG_BLK_DEV_INITRD while
> 
> And the INSANE part is they generally want a static initrd to do it so 
> they're not using the external loader, but Kconfig has INITRAMFS_SOURCE 
> under CONFIG_BLK_DEV_INITRD and it's a mess. Renaming THAT symbol would 
> be good.

You mean renaming CONFIG_BLK_DEV_INITRD will be good?
I do exactly that.
And while we are here, I also rename CONFIG_RD_*,
because configs will be broken anyway.

Also, recently we got keyword "transitional" to help with such
renamings: https://www.phoronix.com/news/Linux-6.18-Transitional .
I will use it.

> To you. I'm not entirely sure what virt_external means. (Yes I could go 

It means "virtual address of external initramfs". But, yes, Borislav Petkov
said me in another email that kernel devs usually use "va" for virtual
address and "pa" for physical, so I will use these terms (in Sep 2026).

> Meanwhile 35 years of installed base expertise in other people's heads 
> has been discarded and developed version skew for anyone maintaining an 

I'm still not convinced. Ideally I want to remove word "initrd" from Linux
sources completely.

Decision to merge my patches or not is on maintainers anyway. They
will decide whether these renamings are good idea.

> > - Removed kernel command line parameter "ramdisk_start",
> > which was used for initrd only (not for initramfs)
> 
> Some bootloaders appended that to the kernel command line to specify 
> where in memory they've loaded the initrd image, which could be a 
> cpio.gz once upon a time. No idea what regressions happened since though.

I double-checked: ramdisk_start is used for initrd code path only
in modern kernels, not for initramfs code path.

"initrd=" is used in both code paths, and I keep it.

==

While we are here, let me answer other your emails, too.

Here is answer to https://lore.kernel.org/all/94023988-8498-4070-bdb7-6758dbe4b91d@landley.net/ .

> There used to be a way to feed a the kernel config a text file listing 
> what to make in the cpio file instead of just pointing it at a 
> directory, and my old Aboriginal Linux build used that mechanism 
...
> But kernel commit 469e87e89fd6 broke that mechanism because somebody 
> dunning-krugered it away ("I don't understand why we need this therefore 

I will consider fixing this, too. Put to my low-priority TODO list.

But it is possible that I will instead remove gen-init-cpio completely.
(I will do some experiments before deciding.)
If it was broken, and nobody except for you cared, then this means that
nobody except for you use it.

Of course, I will do that after sending patch for unconditional creating of
/dev/console and /dev/null, so you are safe.

> And again: you ONLY need this for static initramfs. Dynamic initramfs 
> has code create /dev/console (at boot time, not build time):
>
> https://github.com/torvalds/linux/blob/v6.16/init/noinitramfs.c#L27

Your explanation is wrong here. As you can see in Makefile, noinitramfs.c
is not built if there is BLK_DEV_INITRD.

If you don't have BLK_DEV_INITRD, then noinitramfs.c
is built, and it creates /dev/console.

If there is BLK_DEV_INITRD and there is no INITRAMFS_SOURCE, then
default built-in initramfs is used, which is specified here:
https://elixir.bootlin.com/linux/v6.17/source/usr/default_cpio_list
(and it happens to be equivalent to specified in noinitramfs.c).

If there are both BLK_DEV_INITRD and INITRAMFS_SOURCE, then
INITRAMFS_SOURCE is used instead of default built-in initramfs,
so there is no /dev/console.

I am totally sure that my explanation is correct.

> I could emit cpio contents with xxd -r from a HERE document hexdump or

There is no need for "xxd -r". cpio encoding of /dev/console is ASCII
(except for some null bytes). See:

$ echo /dev/console | cpio --create --format=newc --quiet | xxd
00000000: 3037 3037 3031 3030 3030 3030 3043 3030  0707010000000C00
00000010: 3030 3231 3830 3030 3030 3030 3030 3030  0021800000000000
00000020: 3030 3030 3030 3030 3030 3030 3031 3638  0000000000000168
00000030: 4438 4337 4241 3030 3030 3030 3030 3030  D8C7BA0000000000
00000040: 3030 3030 3030 3030 3030 3030 3036 3030  0000000000000600
00000050: 3030 3030 3035 3030 3030 3030 3031 3030  0000050000000100
00000060: 3030 3030 3044 3030 3030 3030 3030 2f64  00000D00000000/d
00000070: 6576 2f63 6f6e 736f 6c65 0000 3037 3037  ev/console..0707
00000080: 3031 3030 3030 3030 3030 3030 3030 3030  0100000000000000
00000090: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
000000a0: 3030 3030 3030 3030 3031 3030 3030 3030  0000000001000000
000000b0: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
000000c0: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
000000d0: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
000000e0: 3042 3030 3030 3030 3030 5452 4149 4c45  0B00000000TRAILE
000000f0: 5221 2121 0000 0000 0000 0000 0000 0000  R!!!............
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

So, I think the following will go (not tested):

==
printf '%s' '0707010000000C0000218000000000000000000000000168D8C7BA00000000000000000000000600000005000000010000000D00000000/dev/console' > out.cpio
printf '\0\0' >> out.cpio
==

Maybe even last '\0\0' is not needed.

Also, this your email ( https://lore.kernel.org/all/94023988-8498-4070-bdb7-6758dbe4b91d@landley.net/ )
for some reasons didn't end up on https://lore.kernel.org/lkml .

As you can see here https://lore.kernel.org/lkml/94023988-8498-4070-bdb7-6758dbe4b91d@landley.net/ ,
the full list of lore mailing lists, which got it, is linux-snps-arc, linux-riscv and linux-sh .

I wrote about this to public-inbox:
http://public-inbox.org/meta/CAPnZJGB7ugY5rytS+hO-QzvPQBNjCh1jzs4WVkuakafBM9c_=w@mail.gmail.com/T/#u .
But it is possible that the problem is on your side.

Maybe this is why people ignore your emails? Maybe they simply don't get them?

Consider applying for linux.dev email ( https://linux.dev ). They are free for linux devs.

==

Now let me answer to https://lore.kernel.org/lkml/8f595eec-e85e-4c1f-acb0-5069a01c1012@landley.net/T/#u .

> I find the community an elaborate bureaucracy unresponsive to hobbyists. 
> Documentation/process/submitting-patches.rst being a 934 line document 
> with a bibliography, plus a 24 step checklist not counting the a) b) c) 
> subsections are just symptoms. The real problem is following those is 
> not sufficient to navigate said bureaucracy.

I totally agree.

Still I somehow was able to manage this.

Again: I totally agree. I just want to share some practical advice, that helped me
to get my patches merged.

As you can see, I was able to get my patches merged:
https://lore.kernel.org/all/?q=f:%22Askar%20Safin%22 .

And this is despite nobody paid me for this. I do this in my own free time.

As well as I understand, you are doing embedded Linux development as your job,
so you are in better position.

My patches are merged despite my productivity is low. I am very slow person.

You don't need to remember all of submitting-patches.rst . Just do this:

- Run checkpatch.pl . It accepts git ranges, e. g. "checkpatch.pl origin/HEAD..HEAD"
- After posting patches respond to comments, apply their edits, send new version, then again and again

When sending patches and responding to comments don't write too long letters.
Nobody will carefully read long letters and respond to them.
I respond to such letters, because I'm autistic, and I feel responsibility to carefully
read and respond to each letter. But other people don't do this.

In particular, when sending patches and responding to comments don't write long
paragraphs about good things you did in the past and about how you are disappointed
in the entire world, such as these:

> Let's see, I wrote the initramfs documentation in 2005:
>
> https://lwn.net/Articles/157676/
>
> Was already correcting kernel developers on how it actually worked 
> (rather than theoretically worked) in 2006:
>
> https://lkml.iu.edu/hypermail//linux/kernel/0603.2/2760.html
>
> I added tmpfs support to it in 2013 (because nobody else had bothered 
> for EIGHT YEARS):
>
> https://lkml.iu.edu/hypermail/linux/kernel/1306.3/04204.html
>
> I've maintained my own cpio implementation in toybox for over a decade:
>
> https://github.com/landley/toybox/commit/a2d558151a63
>
> The successor to aboriginal (above) is a 400 line bash script that 
> builds a dozen archtectures that each boot to a shell prompt in qemu:
>
> https://github.com/landley/toybox/blob/master/mkroot/mkroot.sh
> https://landley.net/bin/mkroot/latest/
>
> With automated regression test infrastructure to boot them all under 
> qemu and confirm that it runs, the clocks are set right, the network 
> works, and it can read from -hda:
>
> https://github.com/landley/toybox/blob/master/mkroot/testroot.sh
>
> So yes I _can_ create my own bespoke C program to modify the file in 
> arbitrary ways, I have my reasons not to do that, and have thought about 
> them for a while now.

Again: I'm not trying to insult you. I'm just trying to give advice how
to get your patches merged.

When my patches are ready, I send them using something like this:

==
UPSTREAM=origin/HEAD
MERGE_BASE="$(git merge-base "$UPSTREAM" HEAD)"

mkdir /tmp/patches

# For --signoff
export GIT_COMMITTER_EMAIL=me@example.com

# Prepare patches
# --base for "base-commit:" footer
git format-patch --cover-letter --find-renames --base="$MERGE_BASE" --signoff -o /tmp/patches \
  --subject-prefix='PATCH v2' "$MERGE_BASE"

editor /tmp/patches/0000-cover-letter.patch

# Send
# "--batch-size=1 --relogin-delay=20" to insert delays between patches. Hopefully
# this will help me to cope with my mailserver limits
# "--confirm=" to give myself chance to cancel
git send-email --batch-size=1 --relogin-delay=20 --confirm=always --to=a@example.com --cc=b@example.com \
  /tmp/patches
==

This script will automatically generate nice diffstat in cover letter.

This script is not tested. Actually I use my own 182-line Rust program, which does
same thing.

This is checklist I plan to do when sending v2 version of this initrd patchset:
- Read all answers to prev. version, respond and apply edits
- checkpatch.pl
- Check that my patchset doesn't conflict with linux-next
- Check that every commit compiles for x86_64 with "W=1"
- Test everything using mkroot.sh rewritten in Rust

> Why keep the section when you removed the old mechanism?

This section still contains useful info, so I kept it.
But okay, I agree, I will rewrite it to not mention initrd.
I will do this after full removal of initrd, i. e. in Sep 2026.

If you want me to send some patch to this document _now_,
then just ask me, I will try to do this.

> Those two lines you just touched contradict each other

Will fix in Sep 2026, too.

> The init/noinitramfs.c file does init/mkdir("/dev") and 
> init_mknod("/dev/console") because calling the syscall_blah() functions 
> directly was considered icky so they created gratuitous wrappers to do

You cannot directly call syscall from kernel code if your syscall
works with strings. Reasons are here: https://lwn.net/Articles/832121/ .

mkdir syscall expects string, located in user memory. So you
cannot call it from kernel and pass kernel string to it.
Thus you need separate init_mkdir.

> Anyway, that's why the 130+ byte archive was there. It wasn't actually 
> empty, even when initramfs was disabled.

I just double-checked. If BLK_DEV_INITRD is disabled, then
there is no any builtin initramfs at all. If BLK_DEV_INITRD is
disabled, then initramfs_data.S is not built, as we can see here:

https://elixir.bootlin.com/linux/v6.17/source/usr/Makefile#L15

And initramfs_data.S contains symbol __initramfs_size, so, yes,
initramfs_data.S is actual builtin initramfs.

In fact, that "obj-$(CONFIG_BLK_DEV_INITRD) :=" trick
is not needed, because whole usr/ dir is compiled out,
if there is no BLK_DEV_INITRD:
https://elixir.bootlin.com/linux/v6.17/source/init/Kconfig#L1455

Again: I acknoledge that bug with missing /dev/console. In fact,
I was able to reproduce it. I plan to fix it in a month or two.

> > +If the kernel has CONFIG_BLK_DEV_INITRD enabled, an external cpio.gz archive can also
>
> You renamed that symbol, then even you use the old name here.

I rename it in later commit.

> > -This has the memory efficiency advantages of initramfs (no ramdisk block
> > -device) but the separate packaging of initrd (which is nice if you have
> > +This is nice if you have
> >   non-GPL code you'd like to run from initramfs, without conflating it with
> > -the GPL licensed Linux kernel binary).
> > +the GPL licensed Linux kernel binary.
>
> IANAL: Whether or not this qualifies as "mere aggregation" had yet to go 
> to court last I heard.

This is possible that court will use this file as an argument.
So let's keep this paragraph here. :)

There is an example, where FAQ on FSF site was actually
used as argument in court: https://www.sonarsource.com/blog/will-the-new-judicial-ruling-in-the-vizio-lawsuit-strengthen-the-gpl/ .

I mean this quote:

> Vizio “did not dispute” the first two questions, focusing instead on the “expectations” of the contracting parties.
> Relying on the Free Software Foundation’s (FSF) GPL FAQs, it argued that the FSF never intended for third parties to enforce the contract,
> and therefore the parties to the contract could not have intended it.


> >     echo init | cpio -o -H newc | gzip > test.cpio.gz
> > -  # Testing external initramfs using the initrd loading mechanism.
> > +  # Testing external initramfs.
>
> Does grub not still call it "initrd"?

Yes, grub still calls it "initrd".
As I said, in Sep 2026 I will rename bootloader loading mechanism to "initramfs",
and name of grub command "initrd" will simply become "wrong".

> A) they added -hda so you don't have to give it a dummy /dev/zero anymore.

Ok, I will fix.

> B) there's no longer a "qemu" defaulting to the current architecture,

Ok, I will fix.

-- 
Askar Safin

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

[Dave Young]

Hi,

On Sat, 13 Sept 2025 at 06:42, Askar Safin <safinaskar@zohomail.com> wrote:
>
> Intro
> ====
> This patchset removes classic initrd (initial RAM disk) support,
> which was deprecated in 2020.
> Initramfs still stays, and RAM disk itself (brd) still stays, too.

There is one initrd use case in my mind, it can be extended to co-work
with overlayfs as a kernel built-in solution for initrd(compressed fs
image)+overlayfs.   Currently we can use compressed fs images
(squashfs or erofs) within initramfs,  and kernel loop mount together
with overlayfs, this works fine but extra pre-mount phase is needed.

Thanks
Dave