GRUB module query

[Tod Merley]

Hi Again Dave (I hope everybody can forgive top posting and interwoven
replies but...),

Interwoven Replies:

On 8/19/06, Dave S <ubuntu at pusspaws.net> wrote:
> On Thursday 17 August 2006 22:15, Tod Merley wrote:
> > On 8/17/06, Dave S <ubuntu at pusspaws.net> wrote:
> > > > Hi Dave!
>
> Ahh my problem solved - I am no expert but I will tell you what I have found.
> If I am wrong let me know - its the way i learn :)
>
>
> My PCI raid controller has its own BIOS - when I boot it gives me a config
> screen for various RAID options - I turn them off and use kernel software
> RAID.
>

Interesting.  The whole interaction between BIOS, apparently in your
case a secondary "on card" bios, and then GRUB, and then Kernel.
Bill has probably been criticised about his tendency to "take over the
world" thing but it DID make this whole area more regimented for his
world.  In our case, I hope GRUBv2, new more Linux.NX aware BIOSs, and
super kernels will move some of this off of our desks.

> > > >
> > > > I do not understand.  If you need the raid driver to access the disk
> > > > then how can you even fully load GRUB?!?!
>
> Because GRUB is loaded by the BIOS. On power up it is the BIOS that is first
> started, the BIOS loads in the first few sectors of a HDD and executes them -
> hello GRUB ! Only the first HDD light of my RAID array flickers - its not in
> RAID mode yet.
>
> So on boot the BIOS (and I guess my RAID card BIOS) conspire to load the first
> few sectors of my RAID hdd - so far so good :)
>
> (NOTE BIOSs are getting too smart - I used to have 2 x ide controllers on the
> motherboard hda/b hdc/d. I plug in the raid card and the card assumes hda/b
> hdc/d and my motherboard ide controllers are shifted to hde/f hdg/h !)
>
> So grub then asks the BIOS to load the kernel & initrd.img. initrd.img is the
> temporary RAM root file system (very stripped down) - you can find it
> in /boot and look whats inside by ...
>
> root at dave-comp:/boot# mkdir /tmp/tmpinitrd
> root at dave-comp:/boot# cd /tmp/tmpinitrd/
> root at dave-comp:/tmp/tmpinitrd# cat /boot/initrd.img-2.6.15-26-386 | gzip -d |
> cpio -i --make-directories
> 31437 blocks
> root at dave-comp:/tmp/tepinitrd# ls
> bin  conf  etc  init  lib  modules  sbin  scripts  usr
>
> Its a mini filesystem :)
>

Oh I was happy to see this,  :)  :)  !!  I knew about the ramdisk and
had intended to "unzip and reconstruct" one.  I believe it will make a
very good "eyes on" part of my presentation.  I have already run
through the procedure (for my Dapper) and done some "snooping" - all
recorded in WP.  I may also make this the area to use when looking at
the filesystem hierarchy (requested by a LUG member).

> Note the kernel has not accessed the HDDs yet, this exists entirely in RAM.
> The kernel then starts and access this filesystem. Inside the filesystem it
> executes /linuxrc to detect hardware and load appropriate modules - all from
> this RAM filesystem.
>
> Once the modules are loaded it then accesses the HDDs and changes its root
> filesystem to the main HDD filesystem. (both HDD leds start blinking on my
> HDDs - RAID is working :)
>
> My problem was that /linuxrc could not detect and load the needed module. My
> solution was ...

Who, from where, calls "linuxrc"?

>
> apt-get install initrd-tools
> vi /etc/mkinitrd/modules
> and add the line 'it821x'
> apt-get install --reinstall linux-image-2.6.15-26-386
>
> re-boot, the new initrd.img is loaded & everything works :)
>

Ahhhh! Soo happy to see the chicken and egg happy at the same time.

Thank you Dave!  The presentation will be better, and those I run into
doing this mail list research who do have a "my egg has no chicken"
problem will be very happy to know this!

Thanks again!

Tod