Re: bootloader question about GRUB

[Chris Murphy]

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