Talk:Initial ramdisk

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

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. —Preceding unsigned comment added by Wk muriithi (talk • contribs)

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. — Preceding unsigned comment added by 68.164.84.38 (talk)

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. —Preceding unsigned comment added by Jaddle (talk • contribs)

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.

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

Wrong information about Debian

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)

1 is true, init is used by debian, mandrake, red Hat ...etc.

2 is false : mkinitrd of sarge uses cramfs

see man page of mkinitrd
grep cramfs /etc/mkinitrd.conf —The preceding unsigned comment was added by Romanc19s (talk • contribs) 22:07, 14 March 2007 (UTC).[reply]

2 is true for recent kernels, initrd can be built with cpio. I just checked this on debian/ubuntu 2.6.15 and debian/knoppix 2.6.19 for instance. I think we should point to the current documentation which is in the kernel tree (/usr/src/linux-2.6.X/Documentation/initrd.txt) All of this is explained. - pweltz 2007-june-03

Misrepresentation of the linux architecture and boot process

The article seems to be unsure of how a linux system actually boots, as I understand it (working from the source of the kernel!) The following happens. 1. The kernel itself is loaded into memory (optionally with a ramdisc image.) 2. The kernel concocts a very simple pre-boot file system, including a /dev 3. The kernel mounts the root file-system and performs a root_pivot (kernel version of chroot.) 4. The kernel then calls init, which controls the rest of the boot process.

The article at the moment indicates that the linux kernel _typically_ doesn't contain "all the code needed to load the system.". While some features ARE placed in modules, these tend not to be the ones you need for mounting the root file system. Using initrd it IS possible to place those features in modules. Unless someone can give me a good reason why not, I'll rewrite large chunks of this article in 24 hours time.

Scruffy brit 16:04, 12 October 2007 (UTC)[reply]

propose move to "initrd and initramfs"

… since this article describes both, and initramfs redirects here. —Fleminra 21:29, 20 October 2007 (UTC)[reply]

This article needs to be Dumbed Down to be useful

Can I suggest that this article be greatly simplified, have terms described, and have examples added. As it stands it may be accurate but only usable by somebody who already understands all the terms used - i.e. by somebody who doesn't need it. A case in point is the description of root and pivot. An example of the code we need to use to specify the (temporary ? or real ?) root would be meaningful. It left me mystified, and I still don't know what goes in initrd or how to create it. Please not I'm not criticising or nitpicking here, it's good that you guys have contributed this, I'm just trying to provide constructive feedback. Rcbutcher (talk) 05:52, 29 February 2008 (UTC)[reply]

Initramfs section far from complete.

Based on http://www.mjmwired.net/kernel/Documentation/filesystems/ramfs-rootfs-initramfs.txt, which was definately at least once true, although it might not still be true, the kernel always uses an initramfs. The CPIO archive is embedded in the kernel image. It may be empty. The kernel can optionally be passed an external cpio file, whose contents are merged with the internal one. If the built-in initramfs archive does not contain the necessary components, and no external initramfs is available to merge in, then legacy code for loading an initrd is used. If that fails, booting from a physical disc directly is attempted.

In theory then the kernel image can contain the complete OS, by using the built-in cpio archive. This is very different from an initrd, which always requires a separate file. 71.2.110.57 (talk) 17:30, 20 June 2008 (UTC)[reply]

Too much "inside-world" perspective

This article should compare the approach it describes with other operating systems' methods of solving the same problem. (Assuming that they have the same problem.) In FreeBSD this is generally the responsibility of /boot/loader; what does Solaris do? How about Microsoft Windows? QNX? Were there similar problems on other hardware architectures, or is this specific to PC-style systems? 18.26.0.5 (talk) 19:52, 30 October 2009 (UTC)[reply]

I'm not sure that would be helpful, because—from what I know—other operating systems have simpler boot processes with no straightforward analogue to an initramfs. Maybe a separate article on boot processes would be a good idea. —213.239.210.250 (talk) 13:58, 18 February 2010 (UTC)[reply]

The Foundational Issue

The basic issue here has been sort of indicated by some, but clearly sidestepped by the writers. In any type of storage medium, the medium must be prepared to accept data. That process is the formatting process which installs a file system. This article addresses that part of the RAM used as a temporary disk drive during boot.

It would seem logical that the file system used is the initramfs, or initial RAM file system. After that is done, the initrd, or initial RAM drive, has been created and is available for use. If this is not the case, then what sets aside that section of RAM and what is the file system used on that memory area?

When we move from traditional ways of viewing the computer components and their software, we only create confusion. I suggest that this article's beginning sections go thru a rethink. The current content appears to be misleading. - KitchM (talk) 08:12, 18 February 2010 (UTC)[reply]

There is no such thing. On recent kernels, the initial root file system is unpacked from a compressed archive into a tmpfs, which is a memory-only file system that has no defined on-disk format. A tmpfs does not even occupy any contiguous region of memory, but exists simply as a set of kernel data structures that can expand to fill available RAM. This is simpler and more flexible than using actual file systems on RAM-backed block devices.

The initramfs is not a file system itself, but simply that tmpfs being used as a scratch file system during the initial boot stage. —213.239.210.250 (talk) 08:50, 18 February 2010 (UTC)[reply]

Suggestion: reference to article "Linux startup process"

The article Linux startup process is extremely relevant to this article, and helps to clarify what it being said here. I'd suggest throwing a link to "Linux startup process" somewhere. I'd do it myself, but I'm not sure exactly where I should place it (a "see also" section at bottom? A "see also" at top? A summary of the Linux startup process, with "for further reading, see..."?) so that it won't be edited away in a matter of days.