[single *_grub_* partition for many distros]

[Goh Lip]

Joe(theWordy)Philbrook wrote:
> 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...
> 


Very detailed and good explanation, Joe. I would have failed to explain 
even a fraction of what I was doing. However, bear in mind a few points.

o Karmic will install grub2 as default, your <dedicated>grub in (hd0,2) 
<sda3> is presumably in grub legacy. You can still boot karmic by 
chainloading (which you are now doing); but I would recommend you 
convert this sda3 to grub2.

o You need not mount this grub partition (sda3) at all.

o If you set boot in sda 3 as
   configfile and chainload
to the various partitions, you need not worry about even manually 
editing this grub menu at all, whatever kernel upgrades or even new 
installations. It can be there forever without editing anything in it. 
(but I do edit it to just arrange the first OS to boot, and I do add my 
favourite OS (hardy and karmic) with kernel info (cut and paste) so to 
bypass the 2nd grub menu so it's faster, but it is not really necessary. 
When new kernels emerge, just edit say 2.6.31-10 to 2.6.31-11)
In short, you need not copy new kernels or initrds to sda3 under any 
circumstance.

o I set all 2nd grubs to hidden and 3 secs, so it faster.

o grub2 allows boot to iso files through looping, so if you have a 
livecd or other programs (gparted, anti-virus etc), you need not burn 
and run through cd boots. You may want to include entries at your sda3 
to do just this.

o For any new installation, it will by default set it in mbr, in 
kubuntu, you can circumvent this by setting this to the OS / partition. 
If you forget, you can always reset the sda3 grub back. {one funny thing 
though, in karmic where grub2 is default, the naming convention for 
setting this is still (hd0,4) for sda5, for example, while grub2 
convention should be (hd0,5), but that was in alpha1, does anybody know 
how it is in alpha6?}

o Grub2 come with new commands and methods and we need to relearn all 
this. My only concern is that these are done through the linux command 
lines and not at the grub> shell. So if all my linux OS 
fails...(unlikely, but...still my 'sda3' will boot to new and working 
installations)

BTW, I converted my hardy grub to grub2 as well. (I think it is hard to 
speak french and dutch in the same sentence, if you are not in liege, 
german maybe?)


Regards,
Goh Lip