grub-devel
[Top][All Lists]
Advanced

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

Re: my thoughts about grub 2


From: Colin Watson
Subject: Re: my thoughts about grub 2
Date: Wed, 18 Aug 2010 16:34:07 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Aug 18, 2010 at 10:44:02AM -0400, Lennart Sorensen wrote:
> On Wed, Aug 18, 2010 at 04:42:20PM +0930, Brendan Trotter wrote:
> > 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.

There's a reason that I'm as involved as I can be in upstream
development - to keep this to a minimum.  It's true that there is some
divergence but it is reasonably under control.

(The presence of an update-grub wrapper in Debian and Ubuntu is probably
the most blatant user-visible difference, to be perfectly honest, in
that it's the one that the greatest number of users see.  I've
occasionally wondered whether we should just bite the bullet and include
that upstream despite the fact that it doesn't fit into our usual naming
scheme for historical reasons.)

The situation with GRUB Legacy was an order of magnitude worse, although
I'm not sure many people realised it.  update-grub was completely local
to Debian and its derivatives, OpenSUSE had a complete rewrite of the
setup process if I remember correctly, everyone backported different
sets of filesystem support, Fedora called its configuration file
something else and had all kinds of feature backports, etc.  One reason
we typically refuse to attempt GRUB Legacy support on #grub is that each
distribution's version is very close to being a different product.  And
yet, while nobody liked it much, the world didn't come to an end - so
even if the divergence situation with GRUB 2 is imperfect I think we're
doing rather better.

In some ways, the changes in GRUB 2's configuration language are what
you get if you take the requirements for a large feature set and
unification of what various disparate distributions have been doing, and
try to keep it reasonably unified and consistent.  Adding the
requirement that it shouldn't change its style would probably have been
the straw that broke the camel's back.  We could go back and do it all
again, but at this point I suspect the disruption would once again be
painful, and I'm not convinced that it would come out much better while
meeting all the requirements.

> 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.

One thing I would say is that grub-mkconfig is principally good for
distributions, and for users who want to essentially ignore the boot
loader: it avoids the pathological situation we had in GRUB Legacy where
installing a new packaged kernel with a different file name required a
script to go and edit a configuration file.  This was a fundamentally
horribly broken process (evidenced by a large number of bugs when it
went wrong): it's much better for files to be either user-editable or
system-editable but not both at once!

However, this does need extra layers of abstraction to make it work, and
I don't see any reason why users who don't want to expend the effort to
understand those layers of abstraction (which I can sympathise with to
some extent) can't write their own configuration file directly.  At that
point, you're looking at something like docs/grub.cfg, which is only
about as complex as a similar GRUB Legacy menu.lst file.  If you want to
add UUIDs, that will be a bit more complexity, but that's a feature that
GRUB Legacy didn't really have.

Perhaps we need to make it clearer somehow that this is a valid choice
for users.  I did try when I was writing the 'info grub' section on
configuration, but that probably isn't all that widely distributed yet.

> 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.)

I'm confident that GRUB 2 is on a good path, but do also want to smooth
the road for people who are finding it difficult; that's one reason I've
been spending a lot of time writing documentation recently.  After all,
you only care about the features you need.  But you're correct to say
that those features could never really have been done in GRUB Legacy,
and in many cases (things like translations, module loading, decent
loop-mounting support, etc.) they did require a more sophisticated
configuration language.

-- 
Colin Watson                                       address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]