Ubuntu :: Unsatisfactory Characteristics Of GRUB 2?

Now that I've finally learned how to use GRUB along comes GRUB 2. From my vantage point the developers seem to have overlooked some basics. Possibly, hopefully, I just need someone to straighten me out. Therefore I make some observations and would be grateful for someone to point out how I'm wrong.

To begin with it seems natural that a boot loader ought not depend on being able to boot the system in order to configure the settings used for booting. This is especially true for one calling itself grand. As best I can tell GRUB (legacy that is) does accomplish this but I'm having my doubts about GRUB 2. For example, I use GRUB as a boot manager whose job it is to boot other OS's on the same computer. I want the boot manager to be out of site and out of mind (i.e., simple to update on the rare occasion when that might be needed).

Therefore, I install it in a tiny FAT/DOS partition that I always create at the beginning of any new drive. This allows me to create multiple other partitions used to boot different OSs (e.g., in my case several versions of Linux and Windows). This means that every partition that has an OS installed on it also has the necessary software for loading that OS. In the case of Ubuntu this had become GRUB and now is GRUB 2. An important point here is that I do not expect nor want any Ubuntu system to load/boot any system other than itself. Ubuntu (GRUB 2 if you prefer) seems to go to great lengths to find other systems and configure itself to boot them. If this were done via what GRUB calls chain-loading this wouldn't be to bad.

In that, it would fit my purpose pretty well. However, GRUB has this characteristic, that I find quite undesirable, where it may load a kernel and/or mount a root filesystem from a different partition than the one from which GRUB was loaded. When cloning systems it becomes very easy to ruin multiple systems (i.e., not just the one where you made a configuration error but other stable systems as well). While some folks may like this feature I argue that there is a need for an easy foolproof way to disable it. Better yet this should be the default and those that want additional sophistication should have to enable it intentionally.

Something that I do a lot is to clone systems. The purpose is to try new or different things on a new system such that you don't screw up something that is working good while you experiment. It also provides a good method of recovering form errors that you are having difficulty troubleshooting but you aren't quite ready to trash the system that is acting up. Unfortunately you cannot count on GRUB to leave a stable system alone. The Ubuntu technique for using UUID to identify partitions causes a very particular problem when trying to clone a system.

When a partition image is created it includes the UUID. This means that when you restore the image file to a different partition the cloned system partition has the same UUID as the original partition. I've been able to circumvent this problem by changing the UUID on a live system partition before restoring an image of it to another partition. To be sure this technique risks causing a boot problem where one didn't previously exist which to my way of thinking is also poor technique. To do this I have to be able to update the GRUB configuration before being able to boot the restored partition. There are various ways to do this that basically involve mounting the newly restored partition and editing menu.lst (or whatever file might be appropriate). However, what you very definitely cannot do is to depend on booting the system in order to run the update-grub script.

It seems that GRUB 2 intends that the /boot/grub/grub.cfg file should not be edited. It provides a means to add custom menu entries by editing files in /etc/grub.d. However, this technique also depends on being able to run update-grub which cannot be done until after you have a way to boot the system. As best I can tell my only alternative is to edit grub.cfg.