[TriLUG] Re: initrd thread (what gives?)

Marty Ferguson marty.ferguson at pobox.com
Tue Nov 6 16:02:39 EST 2001


initrd is an inital ram disk.  It instantiates a file system
inside of ramdisk during boot which contains some of 
the modules found in /lib/modules/*ver_num*/...
which are essental for booting the system.

initrd is only requred for chicken-egg types of problems
during boot, whether you're booting for an install or
just performing a post-install everyday boot.

If you're running a stock RH modular kernel, if you boot from EIDE
and / is on an ext2 file system, then the kernel won't  use initrd 
(unless there are some other extenuating circumstances)

If you compile a kernel and 
 1 - your system has an ext3 mounted or a SCSI attached.
 2- you compile those features as modules, not directly into the kernel,
then an initrd can be created, kernel compilation detects the 
possible need through sensing the device (SCSI) or file system (ext3).

However, if (e.g.,) only your /usr file system has the ext3, 
and only your /tmp is the SCSI device, then you'll never 
actually need or use any of the modules early in the
boot process out of initrd.  You can skip the mkinitrd  
step when building this kernel, knowing that mounting / 
doesn't require these features.

The kernel module autoloader  will take care sensing the 
need for and loading the modules when called for, which
is a little later during the init (8) process, which first 
mounts / read only, then remounts / as read/write, and 
then finally fsck's and  mounts all of the other file systems, 
in the order specified in the last column of your /etc/fstab.

Rob, you didn't mention that you had trashed (or renamed) 
the ext3 module out of /lib/modules/2.4.7-10-#my_ver#/kernel/fs/ 
so that 's where it came from when you mounted your ext3.

Demonstrate this to yourself with an ext3 file system 
(I'll use msdos in this case, since I don't have an ext3)

# lsmod
Module                  Size  Used by
nls_cp437               4384   0  (autoclean)
nls_iso8859-1           2880   0  (autoclean)
3c59x                  26048   1  (autoclean)

]# mount /mnt/floppy/
mount: block device /dev/fd0 is write-protected, mounting read-only

]# lsmod
Module                  Size  Used by
vfat                    9488   1  (autoclean)
fat                    33856   0  (autoclean) [vfat]
nls_cp437               4384   1  (autoclean)
nls_iso8859-1           2880   1  (autoclean)
3c59x                  26048   1  (autoclean)

You'll see the same behavior when mounting your ext3 filesystem.

So once linux has access to the root filesystem, the kernel module 
autoloader has access to the modules through /lib/modules/#ver#, 
and all of your modules will be loaded later directly from there, not 
from the initrd file system.


I need a job.

Marty Ferguson
mailto:marty.ferguson at pobox.com        919-544-9575
Red Hat Certified Engineer   (RHCE #806199530900860)

 i was poking around with roy vestal's problem, seeing if i could
reproduce it, and ended up confused about whether i understand
the need for an initrd ram disk during boot.

  as many of you know, the whole point of building an initrd
file with "mkinitrd" is to make available to the kernel essential
modules that it needs to boot (SCSI, IDE, and the like).  in fact,
the initrd file that ships with red hat contains the ext3.o
module, to support mounting of ext3 filesystems in case you
decide to format using ext3 at install time.

  fair enough.  so i started with a fresh red hat 2.4.7-10 RPM,
built it using their template i686 config file (which selects
ext3 support as a *module*), created the modules, did the basic
install, ran "mkinitrd" to build an initrd image in /boot,
and added the appropriate stanza to /boot/grub/grub.conf.
not surprisingly, it booted just fine.

  just for laughs, i removed the "initrd" line from grub.conf to
see what would happen if the kernel had no pointer to an initrd
file from which to load an ext3 module.  still booted just fine.

  so i explicitly deleted that initrd file from /boot, just in
case the kernel was being clever and looking for it there anyway.
still booted just fine.

  ok, so what's going on?  can ext3 filesystems be mounted
even without an available ext3 module or built-in support for
ext3 in the kernel?  what gives?


More information about the TriLUG mailing list