On 9/12/25 19:37, Askar Safin wrote:
Update it to reflect initrd removal.
Also I specified that error reports should
go to linux-...@vger.kernel.org , because
Rob Landley said that he keeps getting
reports about this document and is unable
to fix them
Do you think emailing a list I could forward stuff to will improve matters?
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.
What is ramfs?
--------------
@@ -101,9 +103,9 @@ archive is extracted into it, the kernel will fall through to the older code
to locate and mount a root partition, then exec some variant of /sbin/init
out of that.
-All this differs from the old initrd in several ways:
+All this differs from the old initrd (removed in 2025) in several ways:
Why keep the section when you removed the old mechanism? You took away
their choices, you don't need to sell them on it.
(Unless you're trying to sell them on using a current linux kernel
rather than 2.6 or bsd or qnx or something. But if they _do_ remove 32
bit support, or stick a rust dependency in the base build, I suspect
that ship has sailed...)
- - The old initrd was always a separate file, while the initramfs archive is
+ - The old initrd was always a separate file, while the initramfs archive can
be
linked into the linux kernel image. (The directory ``linux-*/usr`` is
devoted to generating this archive during the build.)
@@ -137,7 +139,7 @@ Populating initramfs:
The 2.6 kernel build process always creates a gzipped cpio format initramfs
archive and links it into the resulting kernel binary. By default, this
-archive is empty (consuming 134 bytes on x86).
+archive is nearly empty (consuming 134 bytes on x86).
Those two lines you just touched contradict each other.
For historical reference, commit c33df4eaaf41 in 2007 added a second
codepath to special case NOT having an initramfs, for some reason.
That's how static linked cpio in the kernel image and external initrd=
loaded cpio from the bootloader wound up having different behavior.
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
it for you instead, because that's cleaner somehow. (Presumably the same
logic as C++ having get and set methods that perform a simple assignment
and return a value. Because YOU can't be trusted to touch MY code.)
Note that ONLY init/noinitramfs.c creates /dev/console. You'd THINK the
logical thing to do would be to detect failure of the filp_open() in
console_on_rootfs() and do the mkdir/mknod there and retry (since that's
__init code too), but no...
My VERY vague recollection from back in the dark ages is if you didn't
specify any INITRAMFS_SOURCE in kconfig then gen_init_cpio got called
with no arguments and spit out a "usage" section that got interpreted as
scripts/gen_initramfs_list.sh output, back when the plumbing ignored
lines it didn't understand but there was an "example: a simple
initramfs" section in the usage with "dir /dev" and "nod /dev/console"
lines that created a cpio archive with /dev/console in it which would
get statically linked in as a "default", and code reached out and used
this because it was there without understanding WHY it was there. So it
initially worked by coincidence, and rather than make it explicit they
went "two codepaths, half the testing!" and thus...
Anyway, that's why the 130+ byte archive was there. It wasn't actually
empty, even when initramfs was disabled.
One of the "cleanups that didn't actually fix it" was
https://github.com/mpe/linux-fullhistory/commit/2bd3a997befc if you want
to dig into the history yourself. I wrote my docs in 2005 and that was
2010 so "somewhere in there"...
-If the kernel has initrd support enabled, an external cpio.gz archive can also
-be passed into a 2.6 kernel in place of an initrd. In this case, the kernel
-will autodetect the type (initramfs, not initrd) and extract the external cpio
+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.
+be passed into a 2.6 kernel. In this case, the kernel will extract the
external cpio
archive into rootfs before trying to run /init.
-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.
Which is basically why
https://hackmd.io/@starnight/Load_Firmware_Files_Later_in_Linux_Kernel
was so screwed up in the first place: the logical thing to do would be
put the firmware in a static initramfs and have the module
initialization happen after initramfs was populated... BUT LICENSING! We
must have a much more complicated implementation because license. I
believe I suggested passing said initramfs in via the initrd mechanism
so it remains a separate file until boot time, and was ignored. *shrug*
The usual...
It can also be used to supplement the kernel's built-in initramfs image. The
files in the external archive will overwrite any conflicting files in
@@ -278,7 +278,7 @@ User Mode Linux, like so::
EOF
gcc -static hello.c -o init
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"?
qemu -kernel /boot/vmlinuz -initrd test.cpio.gz /dev/zero
A) they added -hda so you don't have to give it a dummy /dev/zero anymore.
B) there's no longer a "qemu" defaulting to the current architecture,
you have to explicitly specify qemu-system-blah unless you create the
symlink yourself by hand. This was considered an "improvement" by IBM
bureaucrats. (Not a regression, a "feature". Oh well...)
C) to be honest I'd just point people at mkroot for examples these days,
but I'm biased. (It smells like me.)
Rob
