Talk:Initial ramdisk

I think this article could be helped by the history behind Initrd. It has to do with resource *limitation* especially during the 16 bits to 32 bits CPU time. I have tried searching who proposed it as a solution and how that discussion evolved into initrd implementation on lkml without success, but I believe sprinkling this article with some of those initial discussions would make it more attention catching and educative, atleast for geeks.

---

I agree an historical and perhaps more comprehensive discussion would be useful. I am presently trying to learn why and when I would want to use initrd (I have built a few linux distros including cd boot only distros,and have never needed initrd). Some questions I would love to know the answer to are

1. Is initrd obsolete? It would seem that initrd is only needed if modules are not already in the kernel, but it would make much more sense to me to just compile needed modules in the kernel rather than build a whole second filesystem.

2. If initrd is not obsolete, for what root filesystem types is it needed. The article mentions that it is not needed for ide but is needed for scsi. What about nfs (network booting). And is it really true that scsi needs initrd (although I have not built a distro to work on a scsi machine, it doesn't seem like I would need initrd).

3. What ways can one make the initrd image? The tutorials I read seem to indicate you have to just build a chrooted basic system and tar the whole thing. Is this in fact necessary.

I'm no expert, but here's my take on it - some of this should get put into the article, but not until someone more knowledgeable has a look.

First of all, initrd is not obsolete. I think it basically was started because people didn't want to have to put all their drivers hard-coded in the kernel. This is especially important for default kernels as distributed with an install CD, for example. In this case, the kernel must support as much hardware as possible, so nearly all drivers will be included in the kernel, but to actually put those statically into the kernel would ake for an immense kernel file, and some of the drivers would probably conflict - 90% or more will never be used together anyway, so it would be pointless. Because of this (and a few other reasons...), the majority of drivers get built as modules. Of course, then you get problems if those drivers are needed for booting, i.e. root filesystem drivers, disk drivers, etc.. Even on an IDE system, if the IDE driver is built as a module, you will run into problems, since the kernel can't load these modules until the filesystem is mounted. The initrd makes drivers available before mounting the root filesystem though.

The other new development, as mentioned briefly in the article, is that some suspend tools require an initrd for some reason. I'm pretty sketchy on the reasons for that, but apparently it's true!

As for building an initrd, it should be mentioned that there are at least 2 kinds of 'initrd' right now - only the first, old system is actually called initrd. The replacement is called initramfs, and is supported with all 2.6 kernels. Though it's possible to build by hand, most people use a package called "initrd-tools", or for initramfs, "initramfs-tools". For initramfs, there's also a newer program called yaird to do the same thing, with a slightly different approach. Generally, any kernel package will build the initrd automatically when installed, if the initrd tools are available. (this is the case with debian-based systems anyway - I assume other distributions work similarly).

Anyway... I hope that makes a bit more sense. You can look at http://wiki.debian.org/InitrdReplacementOptions for a little more info, though it's still not very clear.~~

About creation of an initrd image - it's just "cpio | gzip" of a directory (or a FS image). That directory should contain an executable program called "init" (will get back to this later) and anything else that program depends on. It should usually NOT be a full-fledged OS - just enough stuff that can fit into RAM while still leaving space for the rest of the system.

Wrong information about Debian

I'm no expert but I read this article in parallel to taking a look at Debian's initrd.img files and I'd like to point out two errors:

1. The "main" program, at least on Debian Etch, is called "init". It's a shell script whic parsses the kernel command line arguments and decides what kind of modules and which kind of root FS it should mount.

2. The initrd.img that comes from Debian is a compressed cpio file, not cramfs.

Amos Shapira 04:15, 1 February 2007 (UTC)