[techtalk] initrd/kernel building

[Linda Walsh]

> I have Red Hat 6.1 installed, and am about to rebuild the kernel. My
> /etc/lilo.conf has this line in it:
> 
> initrd=/boot/initrd-2.12.12-20.img
> 
> Now, from what I can tell, I'll need to use mkinitrd to make a new initrd
> file that matches up with my new (2.2.14, I think -- the latest stable)
> kernel. My specific questions is: at what point in the process do I need to
> do this? This isn't addressed in the kernel how-to, and initrd wasn't
> incorporated into Red Hat 5.2, from what I can remember, so this is the
> first time I've come across it.
---
	This is one of the most confusing parts of kernel building -- the
documentation (hey, read the man page?) is scattered and difficult to
parse.  I'm running SUSE 63 with a 2214 kernel and decided to forgo
the ramdisk entirely -- to do so, you just have to make sure all the drivers
your kernel needs to boot are linked in -- not modules.  So like I have
SCSI linked in -- be sure that ext2 filesystem and ELF modules are 
hard linked -- somehow I got two configurations that didn't work and traced
it back to those options getting turned off...*duh*.

	Obviously if you have ESDI devices, hard code that in instead --
the make sure the initrd isn't a 'global option' (as it was in SUSE)
my RedHat 6.0 install doesn't have it global (I have it running on
another system).  

	Anyway, I wrote up a recipe to remind myself of the steps
since I was constantly forgetting the steps  I came up with the 
following:

----------------------

<version> = kernel version, ex. - 2.2.10

1) make bzImage -- a compressed kernel
2) make modules
3) make modules_install  - as root, puts kernel support modules in
        /lib/modules/<version>
4) mkinitrd /boot/initrd-<version>.img <version>
        "/boot/initrd-<version>.img" seems to be a "standard" name and
        location;  The version info is used to find where to obtain
        the modules that will be 'pre-loaded' onto the ram disk
        >>> NOTE <<< for this to work you must have a loopback device
        configured into your kernel.  So before you go any further --
        if you want to repeat this in the future, you better make
        sure the loopback device is config'ed in (under Block Devices)


5) cp /usr/src/linux/System.map /boot/System.map.<version>
6) rm /boot/System.map; ln -s /boot/System.map.<version> /boot/System.map
7) mv /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-<version>
8) edit lilo.conf
        The first 'image=<name>' line is the start of the section that
        describe the default boot parameters;  The other sections are
        alternates that can be selected at boot time (press 'TAB' at
        the "lilo:" prompt at boot time to see available parameter\
        sets (as labeled by the 'label=' line)

        If you are installing a potentially unstable kernel, you might
        not want to initially make it the default.  Either way we should
        manually select our choice at boot time.

        So a sample new setup:
---
image=/boot/vmlinuz-<version>
        label=linux-<version label>
        root=/dev/sda5
        initrd=/boot/initrd-<version>.img
        read-only 

---

        Image is the compressed kernel image copied into place in '7' and
        made in step '1'.  Label is whatever, but hopefully a reminder
        of what this paramset is about.  root=root device to boot from --
        where the rest of the OS is.  initrd is the ram disk made and copied
        into place step 4 above.  read-only specifies to initially mount
        the root device as read-only until fsck has verified the device.

9) /sbin/lilo -- this installs the new 'option list' for the lilo boot
        loader to use on the next boot AND calcs the checksums of the
        images -- if any images change, they need new checksums!!
--------------------------


> Or, can I just not bother with initrd? Is it worth having?
---
	I just chucked it -- I also disabled 'initrd' support in the
kernel I built, but left ramdisks as a module.  

	Good luck...

-linda


************
techtalk at linuxchix.org   http://www.linuxchix.org