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 [[email protected]] _______________________________________________ Grub-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/grub-devel
