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.