On Sunday 05 July 2009 11:15:00 Robert P. J. Day wrote:
> Correct the description of the default initramfs, and add an
> explanation of where to see exactly how it's created.
>
> Signed-off-by: Robert P. J. Day <rpjday@xxxxxxxxxxxxxx>
>
> ---
>
> diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.txt
> b/Documentation/filesystems/ramfs-rootfs-initramfs.txt index
> a8273d5..d5f76d7 100644
> --- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt
> +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
> @@ -128,14 +128,31 @@ 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).
> -
> -The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig,
> -and living in usr/Kconfig) can be used to specify a source for the
> -initramfs archive, which will automatically be incorporated into the
> -resulting binary. This option can point to an existing gzipped cpio
> -archive, a directory containing files to be archived, or a text file
> -specification such as the following example:
> +archive contains nothing but the two objects:
> +
> + /root
> + /dev/console
> +
> +You can verify this by examining the default_initramfs() routine in the
> +file scripts/gen_initramfs_list.sh:
It's actually the output of "gen_initramfs_list.sh -d" (as
gen_initramfs_list.sh --help would tell you). But since that script has never
had the executable set in source control, for no readily apparent reason, most
people don't seem to know that.
> +default_initramfs() {
> + cat <<-EOF >> ${output}
> + # This is a very simple, default initramfs
> +
> + dir /dev 0755 0 0
> + nod /dev/console 0600 0 0 c 5 1
> + dir /root 0700 0 0
> + # file /kinit usr/kinit/kinit 0755 0 0
> + # slink /init kinit 0755 0 0
> + EOF
> +}
The /root entry is there for historical reasons, and serves no purpose. The
/dev/console entry is used to open the stdin, stdout, and stderr supplied to
PID 1.
It used to be that if you ran gen_initramfs_list.sh with no arguments, it spat
out what is now the -d output, as an example. And seemingly by accident, when
you didn't set CONFIG_INITRAMFS_SOURCE, the script wound up being run with no
arguments, and instead of an empty initramfs a three entry initramfs would be
created. And since it was there, the kernel grew a dependency on it, and
eventually they decided to make it at least _look_ less accidental.
If you feed it an initramfs without a /dev/console entry, you'll get this
little warning from init/main.c:
if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk(KERN_WARNING "Warning: unable to open an initial
console.\n");
And then generally silence.
Of course they then decided to complicate/bloat things even more by adding the
init/noinitramfs.c code path, where the default_rootfs() function creates
/dev, /dev/console, (and inexplicably, the unused /root) directly, hardwired
into the function. This is what happens when you switch initial ramdisk
support off. (Yes that's right, last I checked one symbol controlled both
initramfs and initrd. Don't ask me why.)
There's a reason I haven't reopened this can of worms...
> +Alternatively, the config option CONFIG_INITRAMFS_SOURCE (in General
> +Setup in menuconfig, and living in usr/Kconfig) can be used to specify
> +different contents for the initramfs archive. This option can point to an
> +existing gzipped cpio archive, a directory containing files to be
> archived, +or a text file specification such as the following example:
>
> dir /dev 755 0 0
> nod /dev/console 644 0 0 c 5 1
Another fun little thing is that the cpio entries are processed in order from
start to finish, so you listed the nod /dev/console before the dir it goes in,
the mknod will fail. Note that the return code of sys_mknod() is not checked,
so I believe it will fail _silently_, which is always fun...
I have in past stuck printk() calls into init/initramfs.c:do_name() just so I
could see what it was doing.
Oh, and on platforms where the early boot code has to copy the kernel to the
right location and the assembly is hardwired to copy at most a fixed amount of
data (sometimes because it's only set up very simple hardwired page tables
that assume the system has a minimum amount of memory), if your initramfs is
too big it can get truncated. You get a gzip error message to printk(), if I
recall...
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
