On Dec 1, 2012, at 9:58 AM, Jomelle Wong <[email protected]> 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
[email protected]
https://lists.gnu.org/mailman/listinfo/help-grub
