[single *_grub_* partition for many distros]

[Joe(theWordy)Philbrook]

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

> Le Sunday 20 September 2009 08:05:31 Joe(theWordy)Philbrook, vous avez écrit :
> > Confused yet? I would be... But bear with me and I will try to make it
> > add up.
> I'm not confused yet.
> 
> As I see it, the MBR is too small to contain a bootloader, instead it uses a 
> pointer (bootstrap) to the bootloader's position.

Absolutely...
 
> As someone installs a new distro/version, most of grub will be copied  either 
> in a 'boot' folder under '/' or in the '/boot' partition (if it is mounted).
> Then the pointer shoud normally be copied/updated in the MBR but you make it 
> instead in the superblock of your partition.

And I do this for two reasons. 

1) Occasionally an automatically updated (or newly installed) grub fails to
boot one or more of my Linux. (Though they usually do succeed in booting the
distro that installed/updated the grub.) Worse, I happen to absolutely hate
using UUID partition identification. (Any time traditional device names won't do
I'd sooner use /dev/disk/by-id.) Generally I take great pains to keep track of
the device names as used by each installed Linux, then one day some automatic
process converted all of them into UUID. There are no words in any language
on the planet sufficiently vile to describe how I felt about that. I
haven't allowed any distro to write to my primary grub since. Because I
always have more than one Linux installed, I simply boot one of the others
and use it to manually update my primary grub...

2) I like having the option of chainloading the newly installed/updated
bootloader, just in case I goof on my manual config. Hence I've always got
a chainloader menu selection for each partition that I'd even consider
installing a Linux on...

> > 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.
> If you mount this boot partition as you install the new Linux, files will be 
> placed there.

I take great care to NEVER do that. If I let the new Linux mount my boot
partition during the install, it would simply replace my grub with a new
version... I look at the install partition's /boot directory to see what
to copy. 

> *I guess the important point there is that you only do this copying after you 
> have tested this new grub*

Usually I edit and test my grub's new entry before I even look at theirs.
(Although with a new install I usually use the chainloader technique to let
the distro's grub configuration do the first boot in case there may be a
first run configuration tool that may even depend on some kernel option I
wouldn't have used. And then, while I've got it booted, I'll use df and/or
fdisk -l to verify that the installation is using the device names I expect)
Other than that I wouldn't even look at the distro's menu.lst unless my
own grub entry failed.

> > 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)
> That means you installed on sda7, doesn't it?

Actually that's my Sabayon partition...

> > to say instead:
> >
> > root (hd0,2)
> >
> > Which in my case was the new boot partition. (see below)
> Not quite clear, your are in the /boot/grub/ of your new Linux to tell the 
> system it has to boot from sda3?

Well you see, the: 

root (hd0,2)
line tells the grub on which partition to look for the kernel and initrd files
using the pathnames provided in the kernel & initrd lines in the grub file.
That is to say that if I used (hd0,6) in my Sabayon grub entry grub would
look on what Sabayon will call /dev/sda7 for the kernel file... But because
it says (hd0,2), it finds instead the copy on my /dev/sda3 partition.

However when the kernel is initialized, it's the kernel argument "root=" that
tells the kernel which partition to use as /... 

> > And while it was so mounted, I created a symlink:
> >
> > # cd /boot
> > # ln -s . boot
> I don't understand, your boot partition will contain a 'link name', 
> named 'boot', and that represents the eponymous '.' current directory.

It's actually a neat trick. If I mount sda3 on /boot I can look for my kernel
as /boot/vmlinuz-2.6.28-11-genericJaunty and find it. But when that
partition isn't mounted it's actual pathname on /dev/sda3 is just
/vmlinuz-2.6.28-11-genericJaunty That symlink allows me to use the pathname
of /boot/vmlinuz-2.6.28-11-genericJaunty in my menu.lst and grub will look
through the /boot symlink to find /vmlinuz-2.6.28-11-genericJaunty... 

My Kubuntu Jaunty installation has another example of using symlinks this
way in /usr/bin where the symlink to '.' named X11 will cause an
application or path setting that's looking for /usr/bin/X11/SOMETHING to
find instead /usr/bin/SOMETHING...

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