Grub 2: was: Re: Partition resize

[Rashkae]

J wrote:
> On Tue, Feb 2, 2010 at 22:53, Rashkae <ubuntu at tigershaunt.com> wrote:
>>> And you are about 90 degrees wrong ;-)
>>>
>>> stage 1 of the GRUB boot loader lives in the MBR and points to the
>>> address of stage 1.5 which in turn gets us to stage 2, both of which
>>> live in /boot, which is either in the root filesystem, or in a
>>> separate boot partition if you're smart ;-)
>>>
>>> Same goes for LILO if you're old enough to remember that one.  Half in
>>> the MBR and half wherever /boot resides.
>>>
>>> Regardless of the OS, at least some portion of the boot loader has to
>>> reside in the MBR and point to the rest of the boot loader in order to
>>> actually get your system up and running.
>>>
>> Indeed, but you managed to completely miss the point that none of these
>> grub or lilo bits and pieces reside in the Windows Partition.
> 
> Nah... I didn't miss it, it just wasn't germane to my comments.  You
> took care of pointing out that it doesn't sit in the Windows
> anything... I was just being pedantic about the fact that not ALL of
> GRUB or LILO sits in /boot.
> 
>> PS. and it seems grub2 is an altogether more sophisticated beast as
>> well, which embeds the rough equivalent of stage 1.5 in some space after
>> the mbr on dos partition table HD's, or a special grub partition (not
>> the /boot partition, but a partition just for Grub) in GUID hard drives.
>>  wee, fun.
> 
> Hrmmm, that sounds interesting.  I wonder why that is.  This is from
> http://www.gnu.org/software/grub/grub-2.en.html
> 

As I understand it, (I might have some facts wrong)

They are trying to no longer rely on BIOS drive ordering (because they 
change all the fricken time) and blocklists (because they can break if 
someone does something as simple as defrag a filesystem, and all of a 
sudden grub stage 1.5 files are no longer on the same blocks.)

So, in theory, grub should now embed enough executable code that it can 
read the filesystem that rest of it is located on, and it can search all 
hard drives the bios is aware of until it finds those files, at which 
point, grub.cfg (the replacement for menu.lst file) identifies any other 
  partitions (including windows boot partitions) by UUID, which grub can 
properly asses no matter where you hid it.  Basically, as long as the 
MBR doesn't get overwritten, it's now much harder to break and much 
easier to recover on systems with multiple hard drives and multiple IO 
controllers.  I really love it!