my thoughts about grub 2

my thoughts about grub 2

[Petr Topiarz]

Dear Developers!

Firstly, thanx for all your time and effort! Grub works perfectly and is 
an ideal tool for me as I believe for millions of other admins too.

Lately I have come accross configuring grub 2 (namely 1.98) and adding 
more systems. I have to say, I was discouraged, displeased and 
diseverything after I have found what a change in configuring you have 
done. I think changing the way of configuring some application so much 
is kind of completely non-systemic. I seriously doubt you had no other 
option but change it so much. It is now harder to configure, 
time-wasting and misleading to many who have learned the old configuration.

While I am no-one in the open-source world of software, I still believe 
you have to know the oppinion of people who use your product.

Please change the configuration back!
Thank you
Petr Topiarz
sys-admin and BSDMag contributor

Re: my thoughts about grub 2

[BVK Chaitanya]

Hi Petr,


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.


regards,
bvk.chaitanya

Re: my thoughts about grub 2

[Brendan Trotter]

Hi,

On Wed, Aug 18, 2010 at 12:35 PM, BVK Chaitanya <bvk.groups@gmail.com> 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).

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

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):
- SyMon (http://symon.da.ru/)
- GAG (http://gag.sourceforge.net/index.html),
- Plop (http://www.plop.at/en/home.html)
- Master Booter (http://www.masterbooter.com)
- Smart Boot Manager (http://btmgr.sourceforge.net/about.htm)
- System Selector/BootManager
(http://www.bootmanager.com/uebersicht.html.en.html)
- BootIt (http://www.terabyteunlimited.com/bootit-next-generation.htm)
- Multiple Boot Manager (http://elm-chan.org/fsw/mbm/mbm_e.html)
- MATTsoft Boot Manager (http://martin.hinner.info/mbtmgr/)

I only found 3 exceptions. The first is Acronis OS Selector
(http://www.acronis.com/homecomputing/products/diskdirector/os-selector.html)
which is part of a much larger toolkit (backup/recovery, partition
management, etc). It requires a version of Windows for Installation
and configuration. OSL2000 (http://www.osloader.com/) and boot-us
(http://www.boot-us.com/) also require an OS (windows) for
installation and configuration.

The other thing I noticed is that when you it comes to
"user-friendliness" all of the boot managers (even the ones that
require an OS for installation/configuration) make GRUB2 look like an
extremely overcomplicated mess.


Cheers,

Brendan

Re: my thoughts about grub 2

[Lennart Sorensen]

On Wed, Aug 18, 2010 at 04:42:20PM +0930, Brendan Trotter wrote:
> Hi,
> 
> On Wed, Aug 18, 2010 at 12:35 PM, BVK Chaitanya <bvk.groups@gmail.com> 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.

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?

> - SyMon (http://symon.da.ru/)
> - GAG (http://gag.sourceforge.net/index.html),
> - Plop (http://www.plop.at/en/home.html)
> - Master Booter (http://www.masterbooter.com)
> - Smart Boot Manager (http://btmgr.sourceforge.net/about.htm)
> - System Selector/BootManager
> (http://www.bootmanager.com/uebersicht.html.en.html)
> - BootIt (http://www.terabyteunlimited.com/bootit-next-generation.htm)
> - Multiple Boot Manager (http://elm-chan.org/fsw/mbm/mbm_e.html)
> - MATTsoft Boot Manager (http://martin.hinner.info/mbtmgr/)

Most boot loaders are simple partition selectors, which is really all
windows/dos users ever wanted.  Linux users expect more.

> I only found 3 exceptions. The first is Acronis OS Selector
> (http://www.acronis.com/homecomputing/products/diskdirector/os-selector.html)
> which is part of a much larger toolkit (backup/recovery, partition
> management, etc). It requires a version of Windows for Installation
> and configuration. OSL2000 (http://www.osloader.com/) and boot-us
> (http://www.boot-us.com/) also require an OS (windows) for
> installation and configuration.
> 
> The other thing I noticed is that when you it comes to
> "user-friendliness" all of the boot managers (even the ones that
> require an OS for installation/configuration) make GRUB2 look like an
> extremely overcomplicated mess.

Well people seem to claim the same about linux versus windows.  Apparently
windows is much easier to configure and install (I personally don't
think so, but then again I have used both a lot).

-- 
Len Sorensen

Re: my thoughts about grub 2

[Colin Watson]

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                                       [cjwatson@ubuntu.com]

Re: my thoughts about grub 2

[Brendan Trotter]

Hi,

On Thu, Aug 19, 2010 at 12:14 AM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> 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 <bvk.groups@gmail.com> 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

Re: my thoughts about grub 2

[Lennart Sorensen]

On Thu, Aug 19, 2010 at 03:18:53AM +0930, Brendan Trotter wrote:
> Um, what?

Well at least update-grub reads from /etc to generate the final config
(which is still /boot/grub/grub.cfg, so it does go in /boot, but since
it is generated (at least on my debian system), I don't consider it
config anymore).

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

Well whichever one is responsible for generating the grub.cfg could
store the files wherever is normal on that OS.

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

I honestly don't personally care at all about any OS that isn't a unix
clone anymore.  Fortunately, I am only a grub user and not one of the
developers.  They seem to care.

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

grub2 certainly has no issue with that.  The default is to use grub.cfg
in the /boot/grub directory.

> I was talking about boot managers, not boot loaders.

Why should there be a difference?

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

Almost every x86 boot loader for linux has also been a boot manager
(through chainloading if nothing else).  Even the ntldr can do that.  It
seems to me that a boot manager is a stripped down boot loader that
doens't do very much.  Seems like a completely useless piece of software
to me.  I don't get it.

-- 
Len Sorensen

Re: my thoughts about grub 2

[Brendan Trotter]

Hi,

On Thu, Aug 19, 2010 at 3:27 AM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Thu, Aug 19, 2010 at 03:18:53AM +0930, Brendan Trotter wrote:
>> Um, what?
>
> Well at least update-grub reads from /etc to generate the final config
> (which is still /boot/grub/grub.cfg, so it does go in /boot, but since
> it is generated (at least on my debian system), I don't consider it
> config anymore).
>
>> 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?
>
> Well whichever one is responsible for generating the grub.cfg could
> store the files wherever is normal on that OS.
>
>> 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?
>
> I honestly don't personally care at all about any OS that isn't a unix
> clone anymore.  Fortunately, I am only a grub user and not one of the
> developers.  They seem to care.

You missed my point - it doesn't work for Unix clones either. You
could even have 2 copies of the exact same OS (something like Ubuntu)
installed on the same computer (in different partitions), and it fails
because both copies of the OS can't share the same "/etc". Any changes
to "/etc" done by one copy won't be seen by the other copy.

>> 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).
>
> grub2 certainly has no issue with that.  The default is to use grub.cfg
> in the /boot/grub directory.
>
>> I was talking about boot managers, not boot loaders.
>
> Why should there be a difference?

A few sayings come to mind:
- "Write programs that do one thing and do it well" (
http://en.wikipedia.org/wiki/Unix_philosophy )
- "jack of all trades" (
http://en.wikipedia.org/wiki/Jack_of_all_trades,_master_of_none )

A boot manager can be very simple to install and very simple to
configure. You should probably take a look at a few (I created a list
including URLs earlier). A few of them even claimed to have "single
click configuration" because they automatically detect installed OSs.

A pure boot loader (something without "boot manager" features, that is
designed specifically for one OS only) typically needs a single
command to install and doesn't need any configuration.

>> 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.
>
> Almost every x86 boot loader for linux has also been a boot manager
> (through chainloading if nothing else).  Even the ntldr can do that.  It
> seems to me that a boot manager is a stripped down boot loader that
> doens't do very much.  Seems like a completely useless piece of software
> to me.  I don't get it.

SYSLINUX is a collection of pure boot loaders. ELILO is a pure boot
loader too. In the old days so was loadlin. If I remember correctly,
early versions of Linux also had a boot loader built directly into the
kernel (but I think that was only for booting from floppies). GRUB,
LILO, SILO and PALO are a mixture. I can't think of any other Linux
loaders.


Cheers,

Brendan

Re: my thoughts about grub 2

[Lennart Sorensen]

On Thu, Aug 19, 2010 at 04:47:06AM +0930, Brendan Trotter wrote:
> You missed my point - it doesn't work for Unix clones either. You
> could even have 2 copies of the exact same OS (something like Ubuntu)
> installed on the same computer (in different partitions), and it fails
> because both copies of the OS can't share the same "/etc". Any changes
> to "/etc" done by one copy won't be seen by the other copy.
> 
> A few sayings come to mind:
> - "Write programs that do one thing and do it well" (
> http://en.wikipedia.org/wiki/Unix_philosophy )
> - "jack of all trades" (
> http://en.wikipedia.org/wiki/Jack_of_all_trades,_master_of_none )
> 
> A boot manager can be very simple to install and very simple to
> configure. You should probably take a look at a few (I created a list
> including URLs earlier). A few of them even claimed to have "single
> click configuration" because they automatically detect installed OSs.

Then install a boot manager, and install grub2 for each unix clone you
want to boot seperately, and let the boot manager pick which grub2 install
to boot, and then let each unix clone manage their own grub2 config for
their kernels to boot.  grub is very much a boot loader.  It has some
support for booting other partitions, but the primary thing is to be a
boot loader.

> A pure boot loader (something without "boot manager" features, that is
> designed specifically for one OS only) typically needs a single
> command to install and doesn't need any configuration.

It needs config for which kernels or other things to boot.  Even ntldr
has a boot config file on windows.  The only ones that don't need config
are those that have no options (like the DOS boot loader).

> SYSLINUX is a collection of pure boot loaders. ELILO is a pure boot
> loader too. In the old days so was loadlin. If I remember correctly,
> early versions of Linux also had a boot loader built directly into the
> kernel (but I think that was only for booting from floppies). GRUB,
> LILO, SILO and PALO are a mixture. I can't think of any other Linux
> loaders.

isolinux certainly has a config file and supports lists of kernels and
options, so no syslinux is far from pure.  loadlin is, given it's config
was whatever arguments you passed it.  Not sure about elilo, although I
suspect it has a config somewhere to tell it which kernels to load again.
The kernel's floppy boot (which is long gone) could be considered a pure
boot loader.  Almost all are at least configurable.  Many are also able
to chainload other partitions or drives.  Few are pure boot loading on
any OS.

-- 
Len Sorensen

Re: my thoughts about grub 2

[Seth Goldberg]

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

  I agree with you -- using GRUB2 in a multi-OS configuration is inherently 
problematic due to the split-brain phenomenon, but if you're managing 3 OSes, 
we expect you to be smart enough to work around the problem yourself.  Keep in 
mind that a multi-UNIX environment is not the target use case for GRUB2 -- 
it's one distro that manages the GRUB2 configuration.  It would be a nightmare 
to try to support three UNIXes, each with potentially different versions of 
GRUB2, each trying to own the menu.

  I know GRUB2 isn't the easiest thing to work with, but it's far more flexible 
than Legacy GRUB was.

  Also, no one's forcing you to use the autogenerated configuration file.  You 
can disable that and manually manage your menus, but in doing that you need to 
understand that you're cutting out one of the more useful features.

  --S

Re: my thoughts about grub 2

[Lennart Sorensen]

On Wed, Aug 18, 2010 at 11:54:07AM -0700, Seth Goldberg wrote:
>  I agree with you -- using GRUB2 in a multi-OS configuration is 
> inherently problematic due to the split-brain phenomenon, but if you're 
> managing 3 OSes, we expect you to be smart enough to work around the 
> problem yourself.  Keep in mind that a multi-UNIX environment is not the 
> target use case for GRUB2 -- it's one distro that manages the GRUB2 
> configuration.  It would be a nightmare to try to support three UNIXes, 
> each with potentially different versions of GRUB2, each trying to own the 
> menu.
>
>  I know GRUB2 isn't the easiest thing to work with, but it's far more 
> flexible than Legacy GRUB was.
>
>  Also, no one's forcing you to use the autogenerated configuration file.  
> You can disable that and manually manage your menus, but in doing that 
> you need to understand that you're cutting out one of the more useful 
> features.

There is certainly nothing wrong with each linux installation having it's
own grub2 install on it's bootable partition, and letting something else
be the boot manager that picks which to boot.  Each one can manage the
grub2 config for its kernel, and leave the decision of which partition
to boot to someone else.

-- 
Len Sorensen

Re: my thoughts about grub 2

[Seth Goldberg]

Quoting lsorense@csclub.uwaterloo.ca, who wrote the following on Wed, 18...:

> On Wed, Aug 18, 2010 at 11:54:07AM -0700, Seth Goldberg wrote:
>>  I agree with you -- using GRUB2 in a multi-OS configuration is
>> inherently problematic due to the split-brain phenomenon, but if you're
>> managing 3 OSes, we expect you to be smart enough to work around the
>> problem yourself.  Keep in mind that a multi-UNIX environment is not the
>> target use case for GRUB2 -- it's one distro that manages the GRUB2
>> configuration.  It would be a nightmare to try to support three UNIXes,
>> each with potentially different versions of GRUB2, each trying to own the
>> menu.
>>
>>  I know GRUB2 isn't the easiest thing to work with, but it's far more
>> flexible than Legacy GRUB was.
>>
>>  Also, no one's forcing you to use the autogenerated configuration file.
>> You can disable that and manually manage your menus, but in doing that
>> you need to understand that you're cutting out one of the more useful
>> features.
>
> There is certainly nothing wrong with each linux installation having it's
> own grub2 install on it's bootable partition, and letting something else
> be the boot manager that picks which to boot.  Each one can manage the
> grub2 config for its kernel, and leave the decision of which partition
> to boot to someone else.

   Anything is possible, yes.  However, I'm talking about the design center 
here.  The design center was a single OS managing the configuration file.

  --S

Re: my thoughts about grub 2

[Bruce Dubbs]

Lennart Sorensen wrote:

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

I agree with your general comments, but at the same time think grub2 is 
suffering form a severe case of feature-itis.  Just because something 
can be done, doesn't mean is should be done.  For example, I've never 
seen a real need for a boot loader to work with software raid.  Users 
can very easily create a separate non-raid partition in a reasonably 
common format and boot from that.  Is there a real need for the boot 
partition to be encrypted?  In the effort to be complete, the whole 
thing has become very complicated.

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

And if you have some non-debian kernels, that are not recognized either 
grub.cfg or an intermediate shell script needs to be edited manually. 
I'd rather edit grub.cfg myself and have the distros keep away from 
grub.cfg.

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

Using /etc only applies to Unix-like operating systems.  If you *are* in 
a Unix-like OS, just put a symbolic link into /etc.

> 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 afraid I don't agree.  Too many options leads to complications.  A 
boot partition does not need all those specialized partition types.

Even a graphical interface is overkill when the vast majority of users 
will only be in the boot screen 10 seconds or less waiting for a timeout 
for the default boot.  For really novice users, just set the timeout to 
zero and skip the boot screen completely.

> So how does installing a new kernel update the boot loader then if it
> is only configured by itself?

That's why they invented emacs and vi (or ed).  For me to add a new 
kernel means that I need to add basically two lines to grub.cfg.  For 
many users though that's way too much.  However, once a user has a 
working configuration, the only thing that should happen is for the 
distro to add a file to a directory with a menuentry entry.  I don't 
need or want a customized boot screen for Debian, or Ubuntu, or Red Hat, 
or SuSE.

   -- Bruce

Re: my thoughts about grub 2

[Lennart Sorensen]

On Wed, Aug 18, 2010 at 07:02:15PM -0500, Bruce Dubbs wrote:
> I agree with your general comments, but at the same time think grub2 is  
> suffering form a severe case of feature-itis.  Just because something  
> can be done, doesn't mean is should be done.  For example, I've never  
> seen a real need for a boot loader to work with software raid.  Users  
> can very easily create a separate non-raid partition in a reasonably  
> common format and boot from that.  Is there a real need for the boot  
> partition to be encrypted?  In the effort to be complete, the whole  
> thing has become very complicated.

Not supporting software raid in the bootloader is huge pain.  I want
my system to continue to be bootable if a disk fails.  Anything else
is stupid.  grub2 fortunately supports that (grub1 had to be manually
copied around with non raid boot partitions on every drive.  Huge pain
in the ass.).

As for encrypted, well I have no idea why you would need that.  Does grub2
support encrypted drives?

> And if you have some non-debian kernels, that are not recognized either  
> grub.cfg or an intermediate shell script needs to be edited manually.  
> I'd rather edit grub.cfg myself and have the distros keep away from  
> grub.cfg.

Why would I ever have any kernels not built using make-kpkg on my system?
I hate doing extra work, so I use the correct tools that make cleanup
trivial and make the boot loader automatically work.

> Using /etc only applies to Unix-like operating systems.  If you *are* in  
> a Unix-like OS, just put a symbolic link into /etc.

That's pretty ugly.  Just tell grub where you want the config file to be.
/etc if that makes sense, somewhere else if you prefer that.  It does
have options for that.

>> 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 afraid I don't agree.  Too many options leads to complications.  A  
> boot partition does not need all those specialized partition types.

Well in fact on systems that use dmraid, the bootloader MUST support it
to boot unless you want to dedicate a seperate disk entirely for booting
(I sure don't).  For mdraid you could make a system without raid on the
boot partition (as grub1 required), but it makes for a less robust and
much more complicated to manage system.  So mdraid is essential in the
boot laoder too.  lvm could be considered questionable.

> Even a graphical interface is overkill when the vast majority of users  
> will only be in the boot screen 10 seconds or less waiting for a timeout  
> for the default boot.  For really novice users, just set the timeout to  
> zero and skip the boot screen completely.

I don't actually use the graphical one.  grub1 had it too.  I don't
understand graphical boot screens for the kernel either.  I don't reboot
that often.

> That's why they invented emacs and vi (or ed).  For me to add a new  
> kernel means that I need to add basically two lines to grub.cfg.  For  
> many users though that's way too much.  However, once a user has a  
> working configuration, the only thing that should happen is for the  
> distro to add a file to a directory with a menuentry entry.  I don't  
> need or want a customized boot screen for Debian, or Ubuntu, or Red Hat,  
> or SuSE.

Why should I add them, when a tool can manage it for me automatically
(and make less mistakes that I might).  It if can be automated, it
should be.  I am lazy and proud of it.  Lazy is also known as efficient.

-- 
Len Sorensen

Re: my thoughts about grub 2

[thomas]

>
>Le jeu 19/08/10 02:02 , Bruce Dubbs  a écrit::
>
>Lennart Sorensen wrote:
>
>> 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.
>
>I agree with your general comments, but at the same time think grub2 is 
>suffering form a severe case of feature-itis.  Just because something 
>can be done, doesn't mean is should be done.  For example, I've never 
>seen a real need for a boot loader to work with software raid.  Users 
>can very easily create a separate non-raid partition in a reasonably 
>common format and boot from that.  Is there a real need for the boot 
>partition to be encrypted?  In the effort to be complete, the whole 
>thing has become very complicated.

    And if anything may be needed by someone, it means it should be done.
    Of course, user can create a separate boot partition with their Linux kernel
and an initramfs that supports software RAID. However that means the kernel
is _not_ on the RAID. With the RAID support within Grub2, you can embed it
the first sector in every disk in your array; Should any disk broke down, you will
still be able to boot and your kernel will still be there.
    As for the encrypted partitions support, some companies ask for the whole
system to be encrypted, not only the data, but also the kernel since it is often
containing some custom stuffs.
    You call it complicated, but as far as I'm concerned, I found Grub2 far more
easier to use than its predecessor. ;)

>> 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.
>
>And if you have some non-debian kernels, that are not recognized either 
>grub.cfg or an intermediate shell script needs to be edited manually. 
>I'd rather edit grub.cfg myself and have the distros keep away from 
>grub.cfg.

    I agree that the new system is not very practical when you have to reboot
under Ubuntu/whatever to update your configuration files. I'd prefer to be able
to edit the configuration file under Grub itself, and have them within reach in
my boot partition, instead of in the filesystem of one of my operating systems

>> 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.
>
>Using /etc only applies to Unix-like operating systems.  If you *are* in 
>a Unix-like OS, just put a symbolic link into /etc.

    Same as above; If we want Grub to be portable, then its configuration
shouldn't depend on one operating system.

>Even a graphical interface is overkill when the vast majority of users 
>will only be in the boot screen 10 seconds or less waiting for a timeout 
>for the default boot.  For really novice users, just set the timeout to 
>zero and skip the boot screen completely.

    When people ask me to show them Linux because they want to try it, one
of the first questions that comes in mind is "Will I still be able to
<do something> with Windows?". Of course, you can still reboot under it
and all your files are here. But when I show them how, the not-so-fancy
Grub screen nearly screams "go away!".
    Fancy stuff isn't overkill; People who will use it want it fancy. :)

>> So how does installing a new kernel update the boot loader then if it
>> is only configured by itself?
>
>That's why they invented emacs and vi (or ed).  For me to add a new 
>kernel means that I need to add basically two lines to grub.cfg.  For 
>many users though that's way too much.  However, once a user has a 
>working configuration, the only thing that should happen is for the 
>distro to add a file to a directory with a menuentry entry.  I don't 
>need or want a customized boot screen for Debian, or Ubuntu, or Red Hat, 
>or SuSE.

    I would expect something else for the configuration files.
    My idea is to break down the configuration file into several pieces and put
all of them in the boot partition.
* Multiple template files for the global configuration
  * A template file that comes with Grub2
  * Another template file that is created during the installation process
  * User-made template files
  * A template file for each group of entries in the menu
* After generation of the configuration, this will lead to
  * A global configuration file
  * Multiple configuration file that generates the entries in the menu
    With this, every operating, provided it can read the boot partition, should
be able to run the Grub tools (and its own tools) to add its template files,
and then generate new configuration files for Grub2. And it would be even
possible to regenerate them within Grub2 itself.

    But that's only an idea. ;)

    Thomas.