Re: bootloader question about GRUB

[Jomelle Wong]

On Sun, Dec 2, 2012 at 3:45 AM, Chris Murphy <address@hidden> wrote:
>
>
>> On Dec 1, 2012, at 9:58 AM, Jomelle Wong <address@hidden> wrote:
>
>
> How is it that GRUB doesn't conflict with an existing filesystem given
> that it
> loads things off fixed sectors(for the stage1 at least)? I've looked at
> the stage2
> directory and I don't think that will ever fit on just a single sector.
>
>
> The bulk of GRUB Legacy and GRUB 2 is placed into the MBR gap, from LBA 1
> to 62. But sometimes GRUB2's core.img is bigger which is why it's better to
> have a larger gap. Most partition tools now start partition 1 at LBA 2048,
> leave 2047 sectors for GRUB in the gap.
>
> For GPT disks, and BIOS which can support GPT, it's better to have a 1MB
> partition with the partition type of BIOS Boot, which GRUB 2's installer
> finds  automatically and installs diskboot.img and core.img. This is the
> safest approach.
>
> The block list approach you seem to be referring to isn't guaranteed to
> not conflict with an existing filesystem, or more correctly while GRUB
> probably won't step on anything the file system has reserved for itself, the
> file system can't know about about GRUB's usage, so the file system could
> step on GRUB and make the system unbootable. This is why blocklists are
> discouraged.
>
> More here in the section for GRUB Legacy users:
> http://www.gnu.org/software/grub/manual/grub.html
>
>
> Does GRUB try to guess what the existing filesystem is? I don't see any
> hints
> on the config file about the filesystem it is on.
>
>
> This is part of installing GRUB to the disk or partition, you won't find
> hints in the config file at all. All of this happens before the config file
> is produced or read by GRUB.
>
>
> On installation on a partition bootsector, does it read the MBR partition
> table
> and patch stuff(the long stage2_sector, for example)?
>
>
> Realize that partition boot sectors are a myth. For example XFS doesn't
> have one. ext[234]'s boot sector is only 512 bytes so it's essentially
> unusable. This is not big enough for GRUB to be installed onto a partition,
> which is why it's not recommended. But some people are stubborn and do
> things that aren't a good idea anyway, and in that case block lists are
> used.
>
>
>
> What if the filesystem doesn't have reserved spaces(reserved sectors for
> FAT
> would be set to 1, and ext would have no reserved blocks)? Where would the
> rest of GRUB go? Does it patch those fields? But I don't see any hints on
> the
> partition filesystem on the config. Or does GRUB literally store itself on
> fixed
> sectors(outside partitions)? In that case, I go back to my conflict
> question.
> That is, what if every partition has consumed the HDD to the brim. Does it
> adjust the partition table?
>
>
> Check out GRUB documentation on block lists. That should answer your
> question. It basically splits itself into pieces, with code to chain load
> those pieces sequentially until enough is loaded that it can then find
> grub.conf (or now grub.cfg for GRUB 2). It does not notify the file system
> of these pieces, it does not adjust the partition table. The pieces are
> subject to being overwritten at anytime by the host file system.
>
>
> Chris Murphy
>
> _______________________________________________
> Help-grub mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-grub
>

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? 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.

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?

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'.

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.

How are the locations of each partition(and so, each OS/boot sector to
choose from) specified? 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?