Re: 2.4.5-1 kernel in woody trouble

["Michael B. Taylor" <mtaylor@vorticity.engr.utk.edu>]

On Fri, Jul 06, 2001 at 09:04:23AM -0600, mark@foresthaven.com wrote:
> On Fri, Jul 06, 2001 at 08:45:06AM -0500, Jorge Santos wrote:
> > 
> > Hi,
> > 
> > I've installed kernel-image 2.4.5-1 on woody but I get the following
> > errors when booting:
> > 
> > request_module[block-major-3]: Root fs not mounted
> > VFS: Cannot open root device "303"or 03:03
> > Please append a correct "root=" boot option
> > Kernel Panic: VFS: Unable to mount root fs on 03:03
> > 
> 
> It looks like you may have compiled support for your hard disk as a
> module instead of compiling it into the kernel. I did this once...
> 
> 
Actually, you can get away with things like building ext2 support as a 
module when your root filesystem is ext2 now.  This is exactly what is done
in kernel-image package 2.4.5-1.  

Here is the output of lsmod, under 2.4.5-1 on my system (root fs is ext2 on
a scsi drive)

mtaylor@mapleloop:~$ /sbin/lsmod
Module                  Size  Used by
parport_pc             19344   1 (autoclean)
lp                      5104   0 (autoclean)
parport                24672   1 (autoclean) [parport_pc lp]
ppp_deflate            39232   1 (autoclean)
bsd_comp                4160   0 (autoclean)
ppp_async               6352   1 (autoclean)
ppp_generic            17296   3 (autoclean) [ppp_deflate bsd_comp ppp_async]
rtc                     5344   0 (autoclean)
soundcore               4112   0 (autoclean)
unix                   15168  57 (autoclean)
sd_mod                 10736   3 (autoclean)
aic7xxx               101152   3 (autoclean)
scsi_mod               88256   2 (autoclean) [sd_mod aic7xxx]
ext2                   35952   2 (autoclean)

As you can see, everything that can be a module is a module.

Here is how it works:  A temporary file system, containing kernel modules, a
rudementry shell (ash) and maybe some other stuff is loaded into a ramdisk
during the boot process.  The kernel boots under lilo and uses the ramdisk
fs as its root fs temporarily.  It runs a temporary init from the ramdisk fs.
The modules required to access the real root fs are loaded.  Once the
kernel is configured with the modules it needs, the temporary init chroots
to the real root fs and the real init is run.

You need to make some changes to lilo.conf to make all this happen.  Here is
my lilo.conf.  The most important difference between it and what you may be 
used to is the initrd line.  initrd contains the data that is loaded into 
the ramdisk fs.  The docs are unfortunately a little sketchy/confusing
on the correct used of initrd with lilo.

boot=/dev/fd0
root=/dev/sda2
compact
install=/boot/boot.b
map=/boot/map
vga=normal
image=/vmlinuz
  initrd=/boot/initrd
  label=Linux
  

Mike