Grub Manual

[Les Mikesell]

William Case wrote:

> I would like to object to your objection to my description of what
> occurs with GRUB.

>>> Grub's job is to find partitions and file systems; not to use them.
>> Grub doesn't 'find' partitions, you tell it where the one it will use is 
>>   from the bios perspective with the root (hdx,x) directive before 
>> installing.
>>
> 
> Whether GRUB finds, goes to, or loads stage 1.5 or stage 2 are moot
> and/or pedantic points.

No it isn't.  The point is that it won't find anything unless you told 
it which drive and partition to use, and you have to do this from the 
perspective of bios and in the grub terminology neither of which match 
the Linux terminology.  Move your boot drive to a different bios 
location and see what happens.

> The OP maintained and continues to maintain "There is nothing simple
> about what Grub does. It is the tiny software that let us boot our Linux
> or Windows operating systems".  I was responding by saying, in plain
> language, that it is in fact quite simple.
> 
> Grub in its own way is just a specialized very small Operating System
> that has one job -- to load other full Operating Systems.
> 
> Your responses unnecessarily re-complicate an issue that can
> conceptually be easily understood.  Once the idea of a separate small
> independent system is absorbed by a reader, then the peculiarities of
> the GRUB operating system (I know it is never called that) can be
> discussed.

Nobody cares much about how/what grub does internally as long as it 
works.  What matters from the user/operator's perspective is how you 
have to configure it so it will in fact work.  And what you have to do 
is learn a completely different way of describing disk locations than 
anything you've used elsewhere.  If you only boot from your first 
partition on your first drive and blindly follow the examples of (hd0,0)
you may never see the problem. Try copying your /boot to some other 
partition on some other drive and see what you have to do to make it 
alternate between the versions.  It's not impossible (as long as it's in 
a place bios can see), but it's not obvious either.

> Similarly, the fact that the viewable source configuration file may
> reside within a Linux partition (eg /boot) does not limit GRUB's
> independence from all OS's that exist on a given hard disk.  As a matter
> of necessary convenience it is made visible within a full operating
> system so that it can be amended or changed before the next boot, but
> nonetheless remains unconnected to that (Linux or other) Operating
> System.  It is easy to confuse the Grub operating system with the full
> system (Linux or others)

Yes, that's exactly the point. To work with the files that grub will use 
you must use the running OS conventions, but to tell grub about them you 
must use grub notation to describe bios conventions.

>> And the missing piece is that you - or the distro-packaged scripts - 
>> update those locations through the OS concepts of where that partition 
>> is mounted.  This part is OS/distro specific and doesn't have a lot to 
>> do with grub.
> 
> That's the point.  Why confuse the issue?

Confuse?  The manual should be from the operator's perspective, not the 
program that only sees one side.  The operator/user doing the 
configuration needs to know both the OS convention to place the files 
and the grub/bios convention to initialize grub correctly.  These things 
are hidden in the fedora installer but not exposed or documented very 
well.  You are probably right that it doesn't belong in an os-agnostic 
grub manual but rather in a fedora-grub-admin manual.

> I have taken the time to respond here, because by your responses you
> have touched on a point that has become important to me.  I have spent
> three years digging deeper and deeper into the functioning of computers
> and Operating Systems, particularly the RedHat/Fedora version of Linux.
> Always after hours and hours of digging through technical and often
> pedantic descriptions, I find that a two or three sentence overview in
> plain understandable language would have sufficed to let someone new to
> a concept have a eureka moment.  Then all the rest easily slides into
> place.  

Yes, the missing pieces are how you find which drive bios will call 0x80 
and 0x81 under most circumstances (which can be extremely difficult, and 
in the case of raid1 you really want to also know how they will be 
addressed if the primary boot device fails which will depend on a lot of 
things), the fact that grub calls these hd0 and hd1, and any notion of 
where these devices are mounted into the linux filesystem.  There is a 
program that tries to generate a device map for grub installs and I've 
seen it work sometimes, sometimes not.  Is there any documentation for 
the mechanism that program uses and how to second-guess the results when 
it is wrong?


-- 
   Les Mikesell
    lesmikesell at gmail.com