Slashdot Mirror

← Back to Stories (view on slashdot.org)

Discover the Anatomy of initrd

Posted by ryuzaki0 on from the oh-you-clever-pr-people dept.

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."

15 of 41 comments (clear)

  1. Great tutorial by gigne · · Score: 5, Informative

    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/

    Are there any more that are actually easy to use?

    --
    Signature v3.0, now with 42% less memory usage.
    1. Re:Great tutorial by Crussy · · Score: 3, Informative

      Arch linux is beginning to use Mkinitcpio. It is for the most part easy to install and use.

  2. More trouble... by misleb · · Score: 3, Interesting

    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

    --
    "THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
    1. Re:More trouble... by doti · · Score: 2, Informative

      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.linuxfromscratch.org/

      --
      factor 966971: 966971
    2. Re:More trouble... by xiox · · Score: 2, Interesting

      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.

    3. Re:More trouble... by squiggleslash · · Score: 2, Informative

      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.

      --
      You are not alone. This is not normal. None of this is normal.
  3. Initramfs? by qbwiz · · Score: 2, Interesting

    I thought that initramfs was the hotness? Why would we want to use initrd over initramfs (or vice versa, for that matter)?

    --
    Ewige Blumenkraft.
    1. Re:Initramfs? by fimbulvetr · · Score: 4, Informative

      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.

    2. Re:Initramfs? by DarkDust · · Score: 2, Informative

      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).

  4. More More More!!! by Anonymous Coward · · Score: 5, Insightful
    More of these types of articles on Slashdot, please. This is "News I Can Use".



    Stick to our techie roots.

  5. F*ck that, give us more politics! by spun · · Score: 3, Funny

    We want more politics, thinly disguised corporate press releases, and pseudoscience articles, please!

    --
    - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
  6. Nontrivial Boot Environments by KagatoLNX · · Score: 3, Interesting

    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.

    --
    I think Mauve has the most RAM. --PHB (Dilbert Comic)
  7. initramfs vs. initrd by ColonelPanic · · Score: 2, Interesting

    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 that occupy statically allocated memory. Storage doesn't get
    reclaimed, but no storage is wasted by rounding up file sizes. An initrd is an image
    of a RAM disk, possibly compressed.

    Note that a cpio archive, possibly compressed, that's loaded in place of an initrd image
    gets automatically
    expanded and copied into the initramfs.

    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.

    If you're using an architecture with small pages (read: x86), use initramfs. Otherwise,
    you may need a clever hybrid solution, such as populating initramfs from a compressed cpio
    archive and then moving some of its content into a RAM disk.

    --
    "Skill shows through where genius wears thin." -Wittgenstein || Religion: uniting aviation and architecture.
  8. Options for fast booting by wall0159 · · Score: 5, Interesting


    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?

    1. Re:Options for fast booting by LiquidFire_HK · · Score: 2, Insightful

      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 if you propose saving what's in memory to an image to be loaded on boot, this already exists.