Re: Vmware, RHEL4 confusion

[Aleksandar Milivojevic <alex milivojevic org>]

Quoting John Horne <john horne plymouth ac uk>:

> Well we tried just rebooting initially but the kernel panics. Yes,
> modprobe.conf was configured to use the LSI driver, and yes the ESX
> server was configured to use the LSI driver. After rebuilding initrd it
> works.

A (not so) short explanation why you got that kernel panic.

The purpuse of initrd image is to hold device driver modules (drivers 
not statically linked into kernel image, but rather dynamically loaded) 
needed to mount root file system.  It solves the chicken and egg 
problem (device drivers needed to access root file system are on the 
root file system -- see the problem?).

Historically, you had to have all device drivers needed to access root 
file system statically linked into the kernel.  This was not a problem 
if you were compiling the kernel yourself.  However, it was a problem 
for kernels packaged in distributions.  Before initrd, distribution 
builders had to build kernels that had practically all device driver 
needed to access storage statically linked, resulting in huge kernel 
images with tons of unused device drivers (for example, you always got 
kernel with all SCSI drivers inside, even if you didn't had any SCSI 
devices).

Initrd solved this.  The boot loader (Lilo or Grub) would load two 
images, one containing the kernel, and the other containing initrd.  
The boot loaders are able to access kernel and initrd images since they 
use BIOS calls (something the kernel can't do, this is limitation of PC 
architecture).  The kernel would then read initrd (it was in memory, so 
the kernel can access it without need for any device drivers).  This 
allowed distribution builders to make much smaller kernels which would 
then (during boot) load only subset of device drivers that are actually 
needed.  Rebuilding initrd image is way faster and simpler process then 
recompiling the kernel.  Whenever you install new kernel from RPM 
package, the postinstall script will be executed and (among other 
things) it will build initrd image for newly installed kernel.  Initrd 
image is always built for the specific machine, it is never distributed 
as part of RPM package.

Now, if you change the type of controller where your root file system 
is (for example BusLogic to LSI), you need to rebuild initrd image so 
that it contains the device driver for that controller.  If you run 
mkinitrd with '-v' option, it will print what it is doing and what 
device driver it included into initrd image.  You got the kernel panic 
the first time, since initrd image contained device driver for BusLogic 
controller, but not for LSI controller.  So the kernel was not able to 
access disk where your root file system was.

The direct consequence of this is that when you do "lsmod" command, 
first (well, actually, last, since the list is in reverse order of 
loading) couple of device drivers (usually SCSI, LVM, Software RAID, or 
whatever drivers were needed to mount root file system) are not 
binaries from /lib/modules directory.  Those binaries were actually 
part of initrd image (generally they are identical files, since initrd 
image is basically built by copying files from /lib/modules).

Of course, if you change some other controller (the one not used for 
root file system), you don't need to recreate initrd image.  Once root 
file system is mounted (early in the boot process), kernel will have 
access to all device drivers on it, and it can load them as needed.

--
See Ya' later, alligator!
http://www.8-P.ca/