[lug] boot loader mystery

[Hugh Brown]

On Mon, 29 Jan 2007, karl horlen wrote:

> I've been reading up on bootloaders (scoured the net)
> and I believe I've got a pretty solid understanding of
> them.
>
> However, there is something that I still don't get and
> would be mighty glad if someone could clarify it for
> me.  Because not understanding my question means I
> really don't understand boot loaders ;-).  Here goes.
>
> I understand why you sometimes need to make an initrd.
> The reason being that sometimes the kernel needs a
> driver that is a module and not compiled into the
> kernel in order to access or use some device and
> consquently boot.  In my case, a scsi driver module.
>
> What I don't understand is the chicken and egg
> scenario my scsi (or any hd controller) module
> presents.  In order for the kernel to boot, it has to
> be able to access the disk and mount the partitions
> right?  So if the kernel requires a scsi driver to
> access the disk, why doesn't the bios itself require
> that same scsi driver to access the MBR/disk and then
> why doesn't the stage1 bootloader require that same
> scsi driver to access /boot partition to find the
> kernel and initrd files to boot in the first place?
>
> This has always puzzled me.
>
> It's like the bios is smart enough to give
> instructions to the scsi controller to find the things
> it needs but the kernel isn't smart enough to do the
> same thing to find a module on the disk so that it
> requires a ramdisk.  But if the kernel requires a
> ramdisk that lives on the disk to get the driver
> module to access the disk, how can it ever access the
> ramdisk?
>
> And it doesn't matter whether the controller/drives
> are IDE/SATA/SCSI based, the bios is always smart
> enough to find that MBR. Yet a kernel is always going
> to need a specific driver depending on the hardware
> installed.
>
> I've walked through the scenario many times and I
> still don't quite get it.
>
> My thought is that the bios must know how to read
> physical locations on a disk.  Which is why it can
> find what it needs.  That makes sense.  However, it
> still has to talk to what is one of a hundred
> different unique controllers installed in every
> individual box that lives out there.
>
> Which brings me back to the catch-22 I described
> earlier.  The bios can't know every new instruction
> set for every controller that comes out.  So how does
> it ask the controller to even get the MBR?  And if the
> bios can do it, why can't the kernel access the disk
> the same way to find its "boot" modules without
> requiring a separate ramdisk.  Couldn't the required
> "boot" modules just be placed in certain known sectors
> (begin plus offset) on the disk.  Then the kernel
> would be able to find it using the same physical
> location mechanism the bios does?
>
> Thanks to all who can provide some clarity about this.
>

This is not authoritative.  This is the way I understand it (which may be
completely wrong).

The bios understands where IDE disks are because it is coded into the
bios.  The mbr is always in the same place on a disk, so the bios doesn't
have to know anything about the file system on the disk or the operating
system on it.  It just starts reading the mbr and wants machine code that
the processor can understand.  In the case of SCSI disks, you'll generally
see that they have their own bios which loads before the mbr is loaded so
that you can boot off scsi disks.  I believe the bios needs the ability to
talk to a scsi adapter in order for this to work.  I suspect it is a stub
that just calls some agreed upon code to load awareness of devices.

So, either way, we get to the boot loader being read from the mbr of the
boot device.  The bios still doesn't know what the os is or anything about
the filesystem.  I think grub just stores where it thinks things are on
disk to load them (this could use some clarification).  The bootloader
loads the kernel.  Now the kernel is the one that needs to know about
talking to the device.  If the kernel is monolithic, you don't need the
initrd, but most of the time the kernel is highly modular.  The module for
being able to talk to the disk as well as to make sense of the filesystem
live on a disk and a filesystem.  So, you get the catch 22 and you need
the initrd in order to break out of the catch-22.

Why can't the bios pass info to the kernel about what devices are present?
I assume it's because it is OS dependent.  Linux has one way of talking to
a scsi device and windows another and ....  It needs to be able to get
that info in a way that makes sense in its environment.  I don't think
that bioses provide that.

I also suspect that the BIOS for a given motherboard has all the info
about the controllers that it has hardwired and that any add on controller
has to provide its own BIOS/ROM which then takes care of providing the
mobo BIOS with info on how to talk to the controller.

I suspect that with the LinuxBIOS (or whatever it's called), they could
set all of that up at a lower level.  But you'd need to do that in the
space you've got for the ROM.  I'm guessing that it was easier to set it
up generically and do just enough to get the next layer going.

That's the way I conceptualize it.

FWIW,

Hugh