For years I've used this method of managing multiple distro's on one HD (with or w/o Windows). The early distributions should've come up with this long ago; maybe we can eventually convince them to add it onto the back-end...
While I've been with one main Linux distro now for several years, for a while it's come in 32- and 64-bit flavors, of course. On several occasions over the past year or so, I've had the impetus to go one way or the other; I've got both variants installed (and reinstalled...). Further, I'm (traditionally, at least) a "distro junkie". Live CD's have eased the situation somewhat, but I'm still of the opinion that if I've got a HD big enough to hold working copies of 1000's of distros, then I ought to be able to do so - and RUN THEM! And sometimes it looks like I'm trying to...
I long ago settled on GRUB (v. 0.97 works fine here), for the obvious reasons. I'm also somewhat of a "filesystem junkie", as well - hence the need for a separate, stable, static-as-possible /boot partition. And what's the harm in running /boot read-only, eh?
I like a tidy HD; I use LVM extensively. I may have 6 or 7 bootable distros installed at any one time, but my partition table is always the same:
Part#/name/size/type/comments
1: /boot 100-150 MB/ext2...theoretically, could be GB's, but...
2: /boot2 40-100 MB/ext2 - An extra/empty(/hidden?) partition for when distroQ doesn't play nice and you find that out when you're in a hurry.
3: LVM 40-250 GB/any
4: extended ? GB/na
>4: logical (extended), non-LVM data partitions, as needed/desired.
I have historically maintained 3 extended, non-LVM, partitions, for various reasons (and note there's not one HD partition with an ambiguous number/index/letter when using this scheme).
=== CREATE ===
Beginning with a brand-new disk, while creating a partition layout similar to that above, create /boot (as an ext*2* partition), appending a couple of sane options to mkfs.ext2:
# mkfs.ext2 -m0 -N512 /dev/sda1
My fstab line for boot (in all distros, FWIW):
# /dev/sda1 /boot ext2 ro,defaults 0 2
Within the LVM volume, I maintain a single, global swap space, then create "/" and "/home" partitions for each distro, either planned or as needed. 8 GB for / and 4 GB for /home are huge numbers for my needs, and a mere piddling on a HD today (and with LVM, all can be changed later, anyway). Having two DOZEN distros installed is both doable and manageable ("sane" is left as an exercise for the reader).
I give all distros a short tag (arch32, arch64, kub3, xub6, mand, etc.) which I'm not going to change later.
I install the first distro. Let (a reasonably current version) install GRUB to the MBR. Reboot and make sure you don't have bigger worries. If not, as root (and an obvious alias candidate...herein named "rwboot"):
# mount -o remount,rw /boot
# cd /boot
Create a subdirectory using the distro's tag, and copy the kernel files from /boot to the subdirectory (...herein named "upboot"?):
# mkdir arch32
# cd arch32
# cp ../*26* .
This copies all the files any distro I currently use, creates: vmlinuz26, kernel26.img, kernel26-fallback.img, System.map26.
If you use a distro which creates others (and not named "*26*"), do something...
I leave the last ones created in /boot - I figure it can't hurt...you could always "mv" instead of "cp".
Since I (for example...) use my $HOSTNAME as my tag name, and since I'll only ever be modifying THAT directory from THIS install, all this is very easily and automatically parameterized for you, for scripting, if you choose, of course.
Now go into GRUB's menu.lst file (in my case):
# title Arch Linux 2.6.28-3 i686 Mode: Normal
# root (hd0,0)
# kernel /vmlinuz26 root=/dev/vg/ua vga=794 ro
# initrd /kernel26.img
And add the subdir tag on the "kernel" and "initrd" lines:
# title Arch Linux 2.6.28-3 i686 Mode: Normal
# root (hd0,0)
# kernel /arch32/vmlinuz26 root=/dev/vg/ua vga=794 ro
# initrd /arch32/kernel26.img
========>^^^^^^^<=========
Ditto with the fallback and memboot options should you so desire. Note you only have to rename the files ONCE in menu.lst (when you install the distro). Kernel updates to some distros involves generating new, identically-named files. If your situation's different...it is. Every time a distro needs to update its kernel, you "rwboot", run the kernel update, run "upboot", then reboot (which returns you to a ro-mounted /boot - you're so rarely exposed, and in so controlled a fashion, that even ext2 makes sense). Also, insert this as the *first* line of the "upboot" alias or whatever, and you'll never overwrite the last bootable kernel in the house:
# mv arch32 arch32old
Obviously you can make these files available to GRUB via menu.lst, also.
=== UPDATE ===
Note you MUST "rwboot" before doing a kernel update (since /boot's normally ro), hence one will never slide by you (or vice-versa). Further, 2 aliases/scripts are, along with your distro's update command(s)), ALL you need. Properly laid out, even the same scripts/aliases can be used in all distros - and this is the ONLY time /boot will ever be mounted rw.
Obviously, back up /boot before installing a new distro. Either have the new distro skip installing a bootloader (most allow that), or let it have it's way with "/boot", following which you can tidy up (create subdir, cp/mv files, and add relevant and modified lines to menu.lst).
I've found this layout and these steps wear well; I've been using them w/o having to fully repartition my entire HD in over 3 years (and that was to reclaim Windows' space), covering literally dozens of Linux installs. I decided to write this after realizing how handy this has become, while converting my "bleeding-edge" distro's root fs to ext4 (yes, "ext4", not "ext4dev" - and notice I said the root fs, NOT /home!
). Of course, YMMV. Comments welcomed.
multi boot
. It provided a hearty laughter over lunch 
.
