On Tue Oct 26 1999 at 08:36, Tom Oehser wrote:
> > What does it take to make a tomsrtbt use an initrd?.. let's say I wanted
> > the minix.o (or whatever it's called) loaded.
>
> It is easy to make a tomsrtbt use an initrd for _anything BUT_ minix.o.
>
> The filesystem of the root filesystem for tomsrtbt IS minix, so it would
> NEVER work, unless you change buildit.s to use ext2fs instead of minix and
> then what is the point anyway? Given having minix and initrd in the
> kernel, initrd is easy, just change the lilo.conf to point to it and
> create a linuxrc.
Hmm. I always thought that it worked something like this...
When lilo runs and an initrd or ramdisk ot whatever is needed at
bootup, then this information gets added to the "parameter map" in the
boot sector so that the kernel knows (or, is told) where (physically)
to find what it needs.
I was always under the impression that the actual filesystem was
irrelevant at boot time, just as long there was some way to physically
describe all this in a generic way regardless how the filesystem has
been formatted.
So when the kernel boots, it needs to find and then load the initrd
disk... at this stage it doesn't care about the actual filesystem on
the disk. It's after this point, that the hardware/software devices
need to be initialised, and *that* is when it starts to matter.
Ok, let me put this another way... the point I'm trying to make is
that it is possible for the kernel to boot off any sort of filesystem
up until the initrd stage... it's the magic in the bios and boot
sector that makes it all _start_ to happen.
If the drivers for using the filesystem are then made available at
this point, then from here on everything is sweat.
Disclaimer: I have no idea how the information in the boot sector
makes it all worl, let alone anything about its internal structure,
so somebody please correct me if I've got the wrong impression here.
In any case, the eligance of all this is almost poetic... whoever the
artist was who put all this together to make it work for linux like it
does did a very good job of it. :)
Anyway, this is all an interesting diversion from the main point of
all this...
> Look the EASIEST way, in my opinion, is to _build yourself a kernel_, with
> support enabled for what you need, and only what you need, and delete and
Exactly right.
> I guess I'm confused, is there something more difficult than I think there
> is about just building a different kernel and slapping it onto tomsrtbt?
:-)
No, not at all - building another kernel is the real solution.
In fact how I solved the problem I had using the megaraid with
tomsrtbt was to do exactly this... compile up a customised kernel and
put it into a customised rtbt disk. It took me a couple of times to
get it tweaked right, but it finally worked.
Puzzling thing is that I also used a redhat rescue disk with the
modules extracted out of the installer and put onto another floppy
disk, which I simply mounted. It worked fine to allow me to see the
raid-5 scsi devices when I insmod'ed the megaraid module from there.
But no way would it work for the default tomsrtbt disk. I never did
manage to find out why. (Apologies for that Tom, but I ran out of
time to follow this up properly before I left the uni).
Cheers
Tony
