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