Let me try and summarize for the non-kernel hackers:
Traditionally, the way to boot linux was by setting attributes inside
the kernel image that would hardcode the location of the root partition.
This would either be picked by the kernel build system and copied from
the machine on which the kernel was compiled. This could also be changed
after the fact using the "rdev" command.
This meant that the kernel had to hold a bunch of builtin tools for
finding said root device. This included statically compiling into the
kernel (i.e. - not as a kernel module) all devices required for
accessing the root (such as the filesystem root resides on, the driver
for the IDE/SCSI/SATA where the disk resides). This could potentially be
a large number of drivers, and possibly totally unrelated to traditional
thinking (such as the driver for the network card, in case the root
resides on an NFS partition). If that were the whole story, however,
people would probably have stayed with initrd.
Accessing an NFS image requires some other prior configurations. These
configurations are not things normally done by a kernel. Two such things
that come to mind is configuring a network interface using DHCP, and
resolving names using DNS and/or NIS. Unlike the filesystems and drivers
mentioned above, these are things that are really best left for user
space programming. Due to the kernel's need to mount the root, however,
there was no choice but to to have a DHCP client inside the kernel. This
made the kernel code bigger, and thus harder to maintain.
In theory, initrd is capable of solving all of the above problems.
Initrd is an early disk mount, mounted as root before the "real" root is
mounted. The bootloader makes sure to load it into memory and to pass
pointers to it to the actual kernel. If you look at how mkinitrd is
built on Debian, it is trying to figure out what kernel modules are
needed for loading the root partition, and then places them on the
initrd image. This caused me no ends of trouble in the past, when I
tried to migrate a running machine from one root technology to another
(for example, when replacing the root with a software raid setup).
Mkinitrd needs to be run again, and sometimes it needs to be told to
explicitly load certain modules (such as is the case when 2.6.8 supports
a certain SATA device as IDE, which 2.6.15 sees it as SCSI).
Initramfs is meant to put the problem to rest, once and for all.
Technologically, the main difference is that the image is opened into a
ram disk and then erased, whereas with initrd the initrd image stays in
memory until unmounted. The flip side is that initrd is reuseable if it
came from a media that is still accessible to the machine. I've made
live CD setups where I managed to not put certain programs on the main
image, and mount the initrd directly (i.e. - after clearing the memory
it took at boot) and use it from there.
The main advantage of initramfs is for embedded cases, where it saves
the need of locating the initrd by being directly injected into the
actual kernel.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
