[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Grub Manual

Hi Les and Mikkel:

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

On Fri, 2007-10-19 at 13:07 -0500, Les Mikesell wrote:
> William Case wrote:
> >> They can't mesh other than by convention.  When updating the config, 
> >> kernel, initrd, etc., files you are working with the OS (doesn't have to 
> >> be linux) view of the filesystem and it's relative locations.  When grub 
> >> boots, it only has the bios view of things and only sees one partition 
> >> through the bios conventions.
> >>
> > 
> > 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.

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

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)

Therefore, manuals that discuss and explain GRUB refer to (or at least
mean) only the Grub operating system.  Confusion abounds when
directions, names and commands for the Grub system get confused with
directions, names and commands of the full operating system (whether
Linux or other).

> > Grub is so powerful exactly because it can find so many different kinds
> > of partitions/filesystems and load them and their kernels with their
> > various forms of init into memory.
> That's true, and it makes it possible to change the configuration, 
> although not the partition to be used, without reinstalling grub itself 
> as you would with lilo.  However, it still doesn't know/care what the OS 
> it is booting will call those partitions or if they are subsequently 
> mounted at all.

If one thinks of Grub as an independent and separate Operating System,
there is no reason to assume it does care what some other system calls
partitions or if they are subsequently mounted at all.

In fact, it can't.  The name and location of partitions and files are
stored within the as yet unloaded Linux or other kernel.

> > To do that Grub needs its own generic file system (rudimentary though it
> > is) and it's own small kernel that allows it to operate on *any*
> > machine.  The manuals (although I agree they could have some basic (less
> > technical) explanations included) deal only with the GRUB file system
> > and kernel making no assumptions about the partitions/files/kernel(s)
> > that will eventually be loaded.
> 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?

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

Regards Bill

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]