Re: bootloader question about GRUB

[Chris Murphy]

On Dec 2, 2012, at 6:51 AM, Jomelle Wong <address@hidden> wrote:
> 
> So when you specify a block list during installation, is it that GRUB
> treats these as free locations and so will use it to whichever way it
> desires?

I don't understand the question.



> Both stage1.5 and stage2 can be stored in these locations?
> What if there isn't enough locations? I assume it'll complain. And if
> there is a surplus, I assume it wouldn't matter.

What's needed is very small maybe 60K so if the file system you're forcing 
block lists into doesn't have 60K free, you have a bigger problem than GRUB not 
installing.


> 
> If a block list is not specified at install-time, GRUB shall default
> to LBA 1-63 to install stage2, or if stage1.5 is desired then stage1.5
> goes there and the user simply inserts stage2 into the filesystem?
> Either way, LBA1-63 is a default area?

I no longer have enough brain cells to recall all of GRUB Legacy's behaviors. 
It's not supported anymore on this list, and hasn't seen an update in 5-6 
years. GRUB 2 is current. And GRUB2's installer produces the block list itself 
when you use the --force option. Stage 1, 1.5, 2 is GRUB Legacy terminology.

> 
> It seems that stage1 doesn't look at the partition table, nor does it
> load a partition boot sector, when installed in the MBR. I assume that
> the loading of partition boot sectors(and therefore OSes) occurs after
> the selection screen? I suppose this is what makes it a 'boot
> manager'.

No, what makes it a boot manager is the fact that it has a means of presenting 
choices what to boot to the user. What makes it a boot loader is that it can 
load other boot loaders or kernels and ram disk images.

Again the partition boot sector is a myth. I don't know why you keep bringing 
it up. It's not the usual case with GRUB. The usual boot sequence is BIOS looks 
to the MBR, loads and executes the code found in the MBR boot loader code 
region. There's some old Microsoft MBR code that instead of saying explicitly 
"jump to here" it actually defers to the active flag in the MBR and will jump 
to the first LBA for that partition. GRUB instead jumps to diskboot, which 
again is usually in the MBR gap, and then to core which is also in the MBR gap, 
and then it knows enough to find the grub folder (location of which is baked 
into core.img). Once it finds the grub folder it can load additional modules 
not found in core.img and also finds and loads the grub.cfg which may tell GRUB 
to load even more modules.


> 
> In which case, where's the part where it actually can load the kernel?
> After all, doesn't that need a bootloader? At this point, I'm confused
> as to what GRUB really does. Or am I confusing it with GRUB2? Do I
> still actually have to write a bootloader that loads the kernel
> itself? minus the PMode stuff.

GRUB is a boot manager and boot loader. The grub.cfg will contain menu entries 
which can be displayed or not (whether they are displayed is a function of the 
grub.cfg file), when selected the guts of the script are executed which 
includes commands to load a kernel and ram disk image at which point hand off 
then occurs.

> 
> How are the locations of each partition(and so, each OS/boot sector to
> choose from) specified?

GRUB uses its own reference for devices and partitions, the manual goes into 
some exhaustive detail on this. And give it up on the boot sector. If your 
operating system has its own boot loader, and hence actually makes use of a 
boot sector, then you don't really need GRUB, although you can still use it to 
chainload a different boot loader by referencing device+partition+sector 
offset. Again the manual goes through this.



> When you specify a path to a partition in the
> config which GRUB shall boot upon start up selection, at install time
> the installer gets the boot sectors of these partitions through
> reading the MBR partition table, or maybe some linux magic? Either
> way, these locations are hardcoded at install time? Or is it specified
> by the user? Or does GRUB re-reads the MBR partition table at run
> time?

There are two scripts that manage GRUB installation for normal users. 
grub-install in normal operation simply places two pieces of GRUB onto the 
disk: boot.img in the MBR, and diskboot+core in the MBR gap. Core contains the 
device and path information so GRUB can find its grub folder, which contain 
many megabytes of modules for various other purposes.

grub-mkconfig script produces the grub.cfg. It calls os-prober and various 
other scripts to determine what operating systems are already installed, and 
produces menu entries for each one found.

Both grub-instal and grub-mkconfig are used to produce a functioning GRUB and 
bootable system.


Chris Murphy