[single *_grub_* partition for many distros]

[Joe(theWordy)Philbrook]

It would appear that on Sep 17, Perry did say:

> Thanks Joe and Goh,
> 
> Many interesting points in your mails.
> The grub location is something I never thought about, and it was only by 
> chance that I didn't run into problems (because I never reaffected 
> the "wrong" partition).
> 
> *I noticed I have many instances of grub.*
> The most recent one, on Hardy, is only a couple of day old.
> As I understand:
>  the grub/menu.lst was updated when a new initrd.img was installed, then a 
> change at a much lower level, before Linux or M$ kicks in, made this file the 
> active one. Perhaps it is the BIOS that updated something on the MBR (??? not 
> sure about the details). Before this time, it was probably the grub/menu.lst 
> in the Jaunty partition that was active, since I (re) installed it after 
> Hardy. Indeed the grub-installer worked very intelligently.
> 
> Now imagine I had wanted to use only Jaunty and to reaffect the Hardy 
> partition as a /home or /perso partition (perhaps reformating it), I would 
> have been left with a unbootable system, even M$, and no way to ask for help, 
> until I use some rescue model (on the hard drive for M$, but will perhaps 
> just reinstall) or a Linux CD. Plus no clue why it happened.
> 
> I hope I will rememeber to pay attention to this "detail" in the future.

You probably will Perry. You already seem to see the potential problem
that has me maintaining a MANUALLY updated grub partition on /dev/sda3
..........................^^^^^^^^....................................

I routinely install multiple linux distros. I always tell them to
install grub on the superblock of the "root ( / )" partition rather
than to the mbr. (Of course I always have to look for something like
an "advanced" options button in the bootloader section of the linux
installer to even know there is a choice. Each of the distros will put
most of it's grub stuff in that distro's /boot/grub directory. But
there is a very small, but critical piece, call it a bootstrap, that it
will by default put in the MBR. The bootstrap's only real purpose is to
transfer execution to the grub files in that distro's /boot/grub
directory. By telling the installer to install grub to the superblock
instead, I prevent the new grub from being the default boot loader.
While still causing the installer to create a working grub loader. 

Confused yet? I would be... But bear with me and I will try to make it
add up.

It used to be that each time I installed another linux I started using
a new grub set-up. But I didn't care for the fancy splash screens that
most of them began using, so I learned how to set them up with a
simpler looking menu again and again. Then I figured out that I could make
a smallish partition and copy everything in the /boot & /boot/grub
directories of whichever one I was using at the time to it.
That is I copied "/boot" to "/" of the new partition, and "/boot/grub"
to "/grub"...  And of course I had to make sure that I had copied the
vmlinuz (kernel) files of each distro, as well as the initrd files to
the "/" of the new partition. 

Then I edited the "root lines" of the menu.lst (sometimes called
grub.conf) file on the new partition from something like:

root (hd0,6)

to say instead:

root (hd0,2)

Which in my case was the new boot partition. (see below)

Then from that distro, I used a root shell to mount the new partition
right on top of the existing /boot

# mount /dev/sda3 /boot

And while it was so mounted, I created a symlink:

# cd /boot  
# ln -s . boot

Next I used grub to set itself up in the mbr.

I know of two methods to do this.

There is a less well advised method that uses a linux command called

Where I'd want to make very sure the new boot partition was mounted
on /boot when I'd use the root shell to enter the command:

# grub-install /dev/sda

But I'm told it's better to use the grub shell to do this.

Of course to do that I needed to understand that with grub the first hard
drive isn't called "/dev/sda" but rather it's (hd0) [ zero because grub
starts with zero rather than one] This means my grub partition on
"/dev/sda3" is called (hd0,2)...

I don't really think this method requires that I mount the partition
because I explicitly tell grub which partition. But I've always
mounted it anyway...

So in any case, at the root shell prompt (with /dev/sda3 mounted on
/boot) I started a grub shell with:

# grub

Then I typed three grub commands
The first one tells grub which partition grub is rooted on...
The second one tells grub  to setup in the mbr
The third one tells grub I'm done


root (hd0,2)
setup(hd0)
quit

Now, as long as I don't set up any linux to use /dev/sda3 { or (hd0,2) }
and as long as don't let them use the mbr, this boot partition will
remain stable no mater which linux I install something else on top of
etc...

The draw back is I have to make changes manually... If I upgrade a
kernel, I need to copy it and it's new initrd file to the boot
partition and edit that grub.conf [menu.1st] file to use the new one
before it will work.

Except that if a linux automatically updated it's own grub, (the ones
that I had the installer install grub on the superblock instead of the
mbr) I can set my grub to boot that distro's grub. 

So that since my Kubuntu is on /dev/sda5 and is currently booted from
this grub entry:

title           Kubuntu kernel 2.6.28-11-genericKubuntu9.4jaunty
root            (hd0,2)
kernel          /boot/vmlinuz-2.6.28-11-genericJaunty root=/dev/sda5 ro vga=normal
initrd          /boot/initrd.img-2.6.28-11-genericJaunty

When I upgrade to karmic in such a way as to automatically configure the
grub on /dev/sda5 to use the new kernel etc, I'll be able to test it
before editing MY grub, with this existing grub entry:

title chain-booting Kubuntu via it's loader on sda5
rootnoverify  (hd0,4)
chainloader +1

It starts the grub on kubuntu's superblock...

Hope this helps...

-- 
|   ---   ___
|   <0>   <->	   Joe (theWordy) Philbrook
|	^		J(tWdy)P
|    ~\___/~	     <<jtwdyp at ttlc.net>>