From: Bruce Dubbs <bruce.dubbs@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: my thoughts about grub 2
Date: Wed, 18 Aug 2010 19:02:15 -0500 [thread overview]
Message-ID: <4C6C7487.9010802@gmail.com> (raw)
In-Reply-To: <20100818144402.GD2632@caffeine.csclub.uwaterloo.ca>
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
next prev parent reply other threads:[~2010-08-19 0:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-16 19:21 my thoughts about grub 2 Petr Topiarz
2010-08-18 3:05 ` BVK Chaitanya
2010-08-18 7:12 ` Brendan Trotter
2010-08-18 14:44 ` Lennart Sorensen
2010-08-18 15:34 ` Colin Watson
2010-08-18 17:48 ` Brendan Trotter
2010-08-18 17:57 ` Lennart Sorensen
2010-08-18 19:17 ` Brendan Trotter
2010-08-18 19:28 ` Lennart Sorensen
2010-08-18 18:54 ` Seth Goldberg
2010-08-18 19:22 ` Lennart Sorensen
2010-08-18 19:24 ` Seth Goldberg
2010-08-19 0:02 ` Bruce Dubbs [this message]
2010-08-19 14:53 ` Lennart Sorensen
-- strict thread matches above, loose matches on Subject: below --
2010-08-19 8:30 thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C6C7487.9010802@gmail.com \
--to=bruce.dubbs@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.