Re: my thoughts about grub 2

[Brendan Trotter]

Hi,

On Thu, Aug 19, 2010 at 12:14 AM, Lennart Sorensen
<address@hidden> wrote:
> On Wed, Aug 18, 2010 at 04:42:20PM +0930, Brendan Trotter wrote:
>> On Wed, Aug 18, 2010 at 12:35 PM, BVK Chaitanya <address@hidden> wrote:
>> > If you could list out specific instances of what you felt is
>> > difficult, then it would be a lot helpful.  A general comment like,
>> > "its not good or difficult" does not give any chance for improvements.
>>
>> If the English language was radically changed, almost everyone that
>> became accustomed to the current/old version of English would become
>> confused and frustrated when they're confronted with the new English.
>> This is relatively easy to understand - radical change means
>> confusion, relearning/retraining and lost productivity.
>>
>> The syntax used for GRUB's configuration (and the structure and
>> location of GRUB's configuration files) isn't really any different -
>> it's like a special language people use to tell GRUB what they want.
>> Not only was it radically changed, it became a lot more complex too.
>>
>> Here's some selected excerpts from the "Configuration" section of the
>> (draft?) GRUB2 documentation (from
>> http://grub.enbug.org/Manual#head-8bd9ce00a71835c5e4a44b1ae459a8de023e55cd
>> ):
>>
>> - "Before you edit some file/entry in /boot/grub that mysteriously 
>> disappears"
>> - "Configuration for GRUB 2 is much different than the original GRUB."
>> - "A multistep configuration creation process (i.e. a configuration
>> for creating the configuration) might seem convoluted."
>> - "Certain items embed configuration information in a non-obvious way"
>> - "Users must depend on the configurations fed to the utilities that
>> generate these images to infer what they will try to do on reboot."
>>
>> Of course this is an intentionally biased and misleading selection of
>> excerpts intended to illustrate a point of view; but can you imagine
>> what normal users are thinking when they try to understand GRUB2
>> configuration for the first time?
>>
>> To make thing even worse, (if Ubuntu is a reasonable indication)
>> different OS distributions will add their own non-standard extras to
>> GRUB2 configuration (and probably add their own non-standard patches
>> to GRUB2's code too). This will mean that if someone learn to
>> configure GRUB2 on one OS distribution (with one set of extra
>> features) then they'll be confused if/when they shift to a different
>> OS distribution (with a different set of extra features); and if
>> anyone is silly enough to attempt to install 2 different OS
>> distributions on the same computer (e.g. dual boot) they'll need to be
>> extremely careful that the distributions don't fight over the GRUB
>> configuration (and screw each other up).
>
> That was certainly the case with grub1 as well.  Debian had a patch to
> add 'save default' to grub1, which upstream did not have.  This
> certainly puzzled some people who wondered why it didn't work on other
> distributions.
>
>> In my honest opinion, the design of GRUB2 should have began with the
>> question "What do normal users expect?". As far as I can tell, most
>> users expect a boot manager to be self contained (e.g. doesn't depend
>> on any OS for installation or configuration) and includes built-in
>> configuration tools that are easy to use (e.g. menu driven).
>
> No, that's not a good design method.  Starting with 'what should it be
> able to do' is much better (and appears to be what happened).
>
> grub2 is multi architecture, modular, extendible, and much more robust
> than grub1.  The fact it no longer depends on any block maps to work is
> a great thing.  The fact it uses modules to build the required features
> in and loads any others needed on demand means it can support a lot more
> filesystems than grub1 since grub1 would have gotten too big adding all
> those features.
>
> Sure grub1's config was simple and the syntax had a lot less in it, but it
> was also limiting the ability to add new features.  Now for debian users,
> they already had an update-grub command that generated the grub config
> file for them, so going to grub2 really doesn't change anything from the
> users point of view, unless they happen to want to custize something.
> Now those customizations happen in /etc not /boot/grub/menu.lst.  That's
> actually a good thing, since all config SHOULD be in /etc, not /boot.
> So grub1 was actually the one that was doing the wrong thing before.

Um, what?

Imagine you've got 3 OSs: Hiaku, FreeDOS and ReactOS. Given that none
of these OSs normally have an "/etc" directory, which "/etc" should be
used to store GRUB's configuration?

Perhaps you're saying that GRUB should be useless for anything that
isn't a Unix clone. In that case, imagine you've got 3 Unix clones. Of
course all of them want to automatically update their boot loader's
configuration when their kernel is updated, and they can't all share
the same "/etc". Does the user nominate one Unix clone as "working"
and let the other 2 OSs fail?

Using a separate partition for "/boot" that contains GRUB's
configuration for all OSs worked (at least in theory) because all OSs
that are installed could mount that partition without conflicts (as
long as you use a file system that all OSs understand).

> Remember it took years for lilo users to finally accept that grub1 was a
> much better choice (lilo being entirely blockmap based, even for kernel
> images, which made it very fragile and inflexible).  It will take time
> for people to get used to grub2 (it certainly has for me), but the fact
> it is more robust and flexible, and works on things other than x86 PCs
> (I am very happy using it instead of yaboot on an IBM powerpc server now)
> means grub2 will soon be the de facto linux boot loader.  It might even
> hit version 2.x (unlike grub1 which never got there).  Now the complete
> conversion of everything in the code has certainly meant some things
> broke over time and got fixed again, but in general it has worked great.
> Isn't native mdraid, lvm, dmraid, piles of filesystems and multi
> architecture support worth it?  How about multiple partition table types
> (disks or raids over 2GB don't work with msdos partition tables after all,
> and grub2 supports EFI style GPT partition tables.)
>
>> To confirm my suspicions I spent an hour or 2 doing a survey. I
>> started with a Google search for "boot manager", and selected each
>> entry in the search results for the first page and a half (before
>> deciding I'd spent enough time) and tried to find out about the
>> installation and configuration of each different boot manager.
>>
>> For the following list of boot managers they all have 2 things in
>> common - they don't require any OS for installation, and all
>> configuration is done inside the boot manager itself (typically with a
>> simple menu driven interface):
>
> So how does installing a new kernel update the boot loader then if it
> is only configured by itself?

I was talking about boot managers, not boot loaders.

Conceptually you have a boot manager (to select which OS to boot) that
doesn't really need to care about any of the details for any
particular OS; plus a boot loader for each OS which is designed
specifically for that OS (and doesn't really need to care about other
file systems, etc). The difference between them often gets blurred
because feature creep is tempting (for example, a lot of the boot
managers I looked at earlier had features for creating/removing
partitions, even though this is normally done using separate utilities
designed for the purpose, like fdisk, parted, etc; and a lot of boot
loaders are probably able to chainload).

GRUB is different in that it's intended to be a boot manager and a
boot loader for many OSs (and isn't primarily intended for a single
role); and I'd guess that is the reason it has to be too complex to be
"user friendly" for any specific role.


Cheers,

Brendan