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