Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Discover the Anatomy of initrd

Posted by timothy on Thu Aug 03, 2006 12:38 PM
from the oh-you-clever-pr-people dept.
Software Linux
IdaAshley writes "The Linux initial RAM disk (initrd) is a temporary root file system that is mounted during system boot to support the two-state boot process. It contains various executables and drivers that permit the real root file system to be mounted, after which the initrd RAM disk is unmounted and its memory freed. In this article explore the initial RAM disk for Linux 2.6, including its creation and use in the Linux kernel. In many embedded Linux systems, the initrd is the final root file system."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Discover the Anatomy of initrd 41 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Great tutorial (Score:5, Informative)

    by gigne (990887) on Thursday August 03 2006, @12:45PM (#15841124) Homepage Journal
    This looks to be a pretty good tutorial.

    As well as mkinitrd, there are some cool tools coming along that help build an initrd.
    Here is one I have used, and although it's very early in it's development cycle.
    http://yaird.alioth.debian.org/ [debian.org]

    Are there any more that are actually easy to use?

  • More trouble... (Score:4, Interesting)

    by misleb (129952) on Thursday August 03 2006, @12:50PM (#15841164)
    Is it just me, or does maintaining initrd seem like more trouble than it is worth? I guess it is good for generic distributions which want to support every hardware config under the sun and keep the kernel small, but if you know the (set of) hardware you are going to be running a given kernel on, you might as well just blow that initrd crap away. Whenever I recompile a kernel, initrd is the first thing to go. All you need in the kernel to make initrd irrelevent is disk and filesystem (and maybe software RAID modules) support. You can keep everything else as modules.

    -matthew
      • If you want to know better, install a LFS system.
        I did it once, and even used it on my machine at home for many months, before I went back to Slackware.

        It's really instructive, if you want to know how Linux is organized.
        I, for one, feel unconfortable having lots of software running in my system that I don't know what it is, what's their purpose, and if I can turn it off nor not. LFS made me know which is which. Also, it gives great understanding of the boot process.
        I highly recommend it: http://www.linuxfro [linuxfromscratch.org]

    • Nontrivial Boot Environments (Score:4, Interesting)

      by KagatoLNX (141673) <kagato@@@souja...net> on Thursday August 03 2006, @01:46PM (#15841658) Homepage
      There are definitely times where it is required.

      Take, for example, booting onto a root on a SAN--specifically a Coraid Ethernet SAN.

      During boot, you must bring up the ethernet interface, load the AoE module, probe for the SAN, wait for it to quiesce, then enable clustering, join the cluster, join the fence domain, allow the cluster to quiesce, load the DLM, enable CLVM, probe and activate everything, then mount your root GFS (or OCFS2 if you can get that working).

      This would not be possible without a good initrd.

      Also, not so obviously, distros aren't the only people who deploy a single kernel on lots of hardware. When you have 300 old Dells, 150 old gateways, 75 custom built boxen, and a handful of laptops, maintaining a single kernel and initrd beats maintaining ten of them. Not your use case, but definitely important.
        • Well, you need to have support compiled into the kernel to be able to mount the root filesystem before you can actually load the modules. If IDE Hard drive, ext3 and whatever is compiled into the kernel and it can mount / and load everything else from /lib/modules/... but I'm guessing that Debian therefore has SATA support compiled as loadable modules.

          The reason an initrd works is because it's the bootloader's responsibility to load the initrd, and one would hope that the bootloader has support for the hard
          • Not with initramfs, actually. Cramfs is also quite tiny.
            • To support them at the time the kernel is loaded they still need to be enabled in the .config (CONFIG_CRAMFS). Initramfs afaik is always used in the kernel since it contains the code for finding the root partition. Modification of this needs to be done at compile time and so can be a bit difficult for most times where an initrd would be simple.

              Just like anything else that is supported at boot, it is actually compiled into the kernel.. in theory it could contain loadable modules too but I think that would be
      • There are definitely times where it is required.

        Yes. But those "times" are unlikely to add up to even 0.1% of the times where initrd are employed.

        All distros I know off set up a initrd-thing even for bog-standard root on locally attached (ide|sata|scsi) devices.

        I don't see the point of it. Yes. It makes perfect sense in some scenarios. It does however *not* make any sense whatsoever in most standard, simple, cases. Why it's nevertheless done beats me.

      • ash is a self contained Bourne shell clone which is easily statically linked. bash is (a) relatively large (most compiled versions wiegh in in the megabytes) and generally not usually that self-contained. So yeah, he probably did mean ash, not bash.

        The initrds I've seen have used other shells such as nash (RedHat/Federoa) and dash (recent Debian kernels), bash really is overkill, especially when you consider you want the initrd to be as small as possible.

      • As this post's sibling has pointed out, ash, the minimalist shell component of BusyBox, is what the article's author intended to use.

        Furthermore, the proc filesystem, like most (all?) virtual filesystems, doesn't care what the device name is. Most people use "none", for clarity, but /proc should work just as well.

    • Is it just me, or does maintaining initrd seem like more trouble than it is worth? I guess it is good for generic distributions which want to support every hardware config under the sun and keep the kernel small, but if you know the (set of) hardware you are going to be running a given kernel on, you might as well just blow that initrd crap away. Whenever I recompile a kernel, initrd is the first thing to go. All you need in the kernel to make initrd irrelevant is disk and filesystem (and maybe software RAI

      • initrd's are also useful if you want to use fancy disk formats (RAID/LVM/EVMS/etc.) Some desktop users will want to use an initrd.

        The point of an initrds (now, at least) is to pull out the work of finding the root filesystem from the kernel and get it into userspace, which is much easier to maintain. Eventually, even "regular" root devices/filesystems will be mounted by an initrd, and the kernel will be that much smaller and more maintainable.

        (I'm using "initrd" as a synonym for "initramfs", even though the
    • We use initrd do to diskless booting. The initrd does dhcp and mounts an nfs partition as root and switches over to that. This is quite cool as the initrd can be quite intelligent, for instance using different root disks depending on which computer it runs on.

    • Whenever I recompile a kernel, initrd is the first thing to go. All you need in the kernel to make initrd irrelevent is disk and filesystem (and maybe software RAID modules) support.

      That's going to be harder and harder to do. For example, one of these days, in-kernel RAID detection is going away in favor of a userspace tool (in initrd). It's already that way with LVM.

      This makes good sense in general in light of the trent towards more and more hot-plugable devices. For instance, RAID. Without hot-plug,

  • Initramfs? (Score:3, Interesting)

    by qbwiz (87077) * <john@ba u m a n f a m ily.com> on Thursday August 03 2006, @12:55PM (#15841193) Homepage
    I thought that initramfs was the hotness? Why would we want to use initrd over initramfs (or vice versa, for that matter)?

    • Re:Initramfs? (Score:5, Informative)

      by fimbulvetr (598306) on Thursday August 03 2006, @01:32PM (#15841534)
      You're right. Initramfs is better in many ways to initrd, and doesn't have the crazy limitations.

      Initramfs, IIRC, has these advantages:

      It doesn't need block level drivers compiled into the kernel to read itself like initrd does.
      It uses the kernel cache area as its file storage area so you don't have to allocate space with a ramdisk.
      The mem it used to store files with temporarily can be returned to the kernel after the kernel has booted.
      No artificial size limit.

      All in all, it's a much better alternative.
      • It has another advantage: it's compiled into the kernel, so you only need to load one image (good for embedded systems).

        It has a huge disadvantage: it's compiled into the kernel, so you can't easily change it (bad for desktop systems).

        • An initramfs CAN be compiled into the kernel, but usually isn't. Normally, grub loads the gzipped cpio into ram and points to it just like a gzipped ramdisk. The kernel uncompresses it into the ramfs and releases the memory used for the archive.

          On Fedora and others, the mkinitrd utility actually creates an initramfs these days. Try zcat /boot/initrd-whatever | cpio -it.

    • Well, initramfs is very awesome. However, you can only have one initramfs per kernel, so initrd allows for a bit more modularity.

      I think it depends on your application (and bootloader), really.
    • We use both in our port of Linux to proprietary Cray architectures.

      Initramfs is synthesized from the stock page and dentry caches. The nice thing about
      initramfs is that RAM gets released to the dynamic pool when an inode is deleted. So
      it's a good choice for files that need to be present at boot time but not kept around,
      like kernel modules. The bad thing: each file occupies at least one page, and that's
      64KiB here. An initramfs with lots of little files can waste beaucoup bytes.

      RAM "disks" are devices tha

      • Confusingly, the kernel also has its own compressed cpio archive within its own text containing the initial content of the initramfs. At a minimum, it holds /, /dev, and /dev/console.

        Interesting! I didn't realize that the kernel provided that. Neat!

        I read somewhere else that if you're using cpio format archives, you can provide a list of them to the bootloader they'll all be extracted to the initramfs. (syslinux at least claims this - I don't know about others and I haven't tried it personally on

    • I may be wrong, but I think that newer kernels always use an initramfs even if you don't realize it. If you search the linux-kernel archives for "early userspace" they talk about moving kinit into userspace. At some point in the future most (all?) of the boot code will be moved into userspace. The plan seems to be that the kernel build a default initramfs for you that is functionally identical to the current behavior. If you want to you can customize it via various methods.

  • More More More!!! (Score:5, Insightful)

    by Anonymous Coward on Thursday August 03 2006, @12:56PM (#15841202)
    More of these types of articles on Slashdot, please. This is "News I Can Use".



    Stick to our techie roots.

  • Options for fast booting (Score:5, Interesting)

    by wall0159 (881759) on Thursday August 03 2006, @04:14PM (#15842806)

    I don't know much about this, but am curious.

    Why, once the system is booted cleanly, can't it save its state in initrd, and just load the state the next time without going through the boot process? Would that result in fast booting?

    • I don't know much about it, either, but I will attempt to answer your question.

      Most of the boot time is "wasted" in loading modules into memory, loading needed services (daemons, scripts to set up the environment, etc.). The time required to load up the initrd image is minimal, and few other things are "created" during boot (maybe /dev device nodes, but I think those are also saved in a tarball).

      What you are proposing would offer little speed increase: you still have to load everything into memory. And

  • Unfortunatly, the article starts well by explaining initramfs (using a compressed cpio rather than a block device image), but then leads the reader down the initrd path.

    Initramfs is intended to superceed initrd for several good reasons.

    For one, it's more efficient. Files in an initramfs are a special case of filesystem where the file is loaded into the generic file cache but has no backing storage (that is, it doesn't live on a block device). OTOH, an initrd is a simple image of a block device. It has a

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.