Partitioning travels (and Happy Birthday to me!)

Question

Next to my avatar, I note that I signed up here 5 years ago today. Not as long as I've been sober,    but still a milestone. I'm quite sure my first Arch install was 0.4...'Voodoo'? The first Linux distro I touched that showed promise of one day "being ready for prime time" - I'm glad I waited for it!
So, this is a 'slightly' off-topic post (but still quite 'on-topic'), and if the powers that be choose to move it; so be it. No skin off my back. This is (IICC) my 89th post in 5 years. Over the years I've made a couple of gaffes, and found more than a couple of bugs (my 'weird' partitioning schemes, outlined below, may test parts of software that most people don't, I don't know).
But overall, I'm pretty quiet. I sometimes wait longer than I should for bugs I find annoying to be fixed, but they almost always are, without my involvement, and often as quickly as I could get a "round tuit" filling out a bug report! My own experience has been that unless I think I've found something substantial, early (which I've sortof done twice in the past two days), I don't report it. And if I do, I report it here. It usually shows up in days, if not hours, anyway. Just my experience.
Anyway, I started checking out a (small number of) distros a few months back, plus I've been piddling with Arch x86_64 installs, so I've been dual-booting (between 32- and 64-bit Arch) even when I only have Arch on the machine! But I've had as many as 5 (Arch 32- and 64-bit, DistroU 32- and 64-bit, and DistroD WTF remembers how many bits it was now).
For a good while (several years, in some form), I've had a partitioning scheme which I've never seen replicated in any tutorials on the subject, but which I find quite flexible and useful.
I have several "non-mainstream" methods for handling multi-booting. Feel free to pick and choose anyhing you find useful, free as in beer and free (of) as in warranty, of course. 
swap belongs on the fastest part of the drive; usually if not always the very beginning (outside) of the drive - IF you only have one installation. In this case, making a 1 GB swap, a  /  of your choice, size-wise, followed by (if you choose) a /home partition that takes the rest of the drive, saving a chunk at the end (40-80 MB) for /boot.
To do this, when partitioning a new drive, 1st create a 1-2 GB primary ('xdy1'; x='s' or 'h', y='a-z'), for swap. Next, create a 2nd *primary* right behind, physically, xdy1 ('sda1'), xdy2, for  /  . Whatever you need, size-wize, 4-60 GB, I guess...
NOW, depending on with *fdisk/gparted/whatever you're using, ether create your extended partition (if using an fdisk variant that will let you leave some space at the end); leave 40-80 MB free. Otherwise, create the extended partition first, and leave the last 40-80 MB unused. You should then be able (very likely after a reboot) to re-run *fdisk and create the final primary partition out of that chunk at the end. Your extended partition would've taken xdy3, so the chunk at the end is xdy4 - a *primary* partition.
You can use this puppy for /boot; /boot BELONGS on the slowest part of the drive. It's very rarely accessed after sysinit. This setup offers 2 advantages: while no BIOS capable of running a 686-optimized Linux system limits you to the first 1024 'cylinders' (sic), some DO require the /boot partition to be on a primary partition. This IS a primary partition. Furthermore, if permanently placed at the end of the drive as a logical partition, every time you added or re-arranged your partitions, it's partition number would most likely change (the partition ID of your BOOT drive - yeah, yeah, I know, UUID's...). With it stuck like glue to 'sda4', it ain't going anywhere, regardless of how (or how many!    ) times you reorganize the extended partition (which is where.I tend to do most of my 'playing').
You can then use the entire extended partition for /home, if you wish, or carve it up however you like. More on this below.
When multi-booting, I've found ("developed"???) a sightly more sophisticated set of arrangements that seem to work well together (WHY RedHat didn't think of this in 1996 - it would be a de facto standard today! - I have NO idea...)
Normally, distros want to install a vmlinuz26, and and a kernel26.img  (and maybe a fallback image, and a config26.gz, and a System.map file), into /boot/. A lot of my older (and some of my newer) machines required bootable partitions to be on a *primary* partition. Install 5 distros like *that*.
Actually, it's QUITE easy:
Note: I have a larger-than-normal (for ME) /boot partition (96 MB - and 64 would likely be adequate for 3 distros), but the reason is obvious, and IMX most people have /boot WAY too big, anyway. Right now I have 2 distros loaded (Arch 32- and 64-bit), current and former kernels are both retained for each distro - ie, 4 complete sets of kernels. My 96 MB partition is 32% full.
For our multi-boot environment,  xdy1 ('sda1') is actually a large (60 GB or so) LVM volume. 'sda2' becomes the extended volume, and 'sda3' is the 40-80 GB /boot volume at the end of the drive. We have the entire extended partition to use *outside* LVM. I generally use a VERY large 'chunk' size in LVM (like 256 MB!), and try to set it up, roughly, as such (on a 250 GB = 236 GB drive):
sda1 P LVM 64 GB
sda2 E extended ?
sda5 L logical ?
sda4 P /ext2+++ 64 MB
+++ there is ZERO reason to make a /boot partition ext3 and incur the substantial overhead of a 32 MB journal on a 60-100 MB filesytem! The system runs BEAUTIFULLY with boot mounted ro - that's my normal MO, in fact. I can always remount it rw on the rare occasions I need to update something.
Rather than using dev-mapper's long naming conventions, I create a Volume Group called vg, and Logical volumes called, say, ar and ah and such:
ah 4 GB # arch32 /home
ar 8 GB # arch32 / (root)
sw 1 GB # swap (shared)
sd 3 GB # data partition shared between all O/S's on the machine (if desired...).
br 8 GB # arch64 / (root)
bh 4 GB # arch64 /home
You can add more lv's to install additional O/S'es.
You are NOT forced, in either fstab, GRUB, OR LILO, into using the 40-character-long "dev/dev-mapper/vg01/dm-01" syntax; from above, "dev/vg/at" works great, and reasonably resembles your other partition ID's. 
Note that no matter HOW many O/S'es we install, we only use ONE /boot partition! I might have to go to a 128 MB or 256 MB partition. 
While I normally have fstab mount /boot ro, it's easy, of course, to remount it rw on the fly. Since all distros SHARE the same /boot (normally only mounted ro by all concerned), if one distro borks it's grub entries or installs a REALLY crappy kernel, it's quite easy to get to the file in question from another O/S!
I first installed Arch i686 on this machine (AMD64 XP3500+). I then created a directory at /boot/arch32. I copied (*copied*, NOT moved) all the loose files from the /boot directory (vm*, kern*, Sys* in arch's case) into the /boot/arch32 directory. I then update /boot/grub/menu.lst, replicating all it's primary entries as new options to select, with '/boot/vmlinuz26' becoming '/boot/arch32/linuz26', etc. These come BEFORE the original selections. I leave the loose files in /boot alone; they aren't hurting anything, and, who knows...
Reboot choosing the 'normal' option (not 'safe'). If the system boots correctly, I leave the 'fall-back' option from the original Arch install as the LAST entry in grub (it's literally the 'last shot', anyway...). Theoretically, it should pick up these 'loose' files, were it to come to that.
Now, whenever Arch updates the kernel, it (wisely) doesn't do a bunch of checking in /boot/grub/menu.lst or check what files are in /boot; it simply recompiles a full set of files and slaps them into /boot. All I have to do when there is the occasional kernel update is:
cd /boot
rm -rf arch32old
mv arch32 arch32old
mkdir arch32
cp vm* kern* Sys* arch32/
All is ready to go. The next boot will RUN the kernel from the /boot/arch32 directory.
That's pretty quick-n-easy considering Kernel updates don't NORMALLY (cough cough) come out that often.
One could even create GRUB entries for the arch32old (and arch64 old) kernels! (easily, basically cut-n-paste w/minor replacements/substitutions). You could have a GRUB menu that takes the entire screen!
We can now install Arch x86_64, and any other distros that recognize LVM2 and play nice with other distros.
One last thing I do: in the extended partition (preferably near the end of the drive) I set up 8 GB partitions as ext2, -b4096, -m0, -N16384 (-N65536?). I use these for the /var/cache/pacman in Arch, but other distros have similar (it not as ready for prime time!) arrangements and needs; the routine seems to wear well; I've had at least some of my now-system disk (250 GB) working like this for a good 3 years (including some REALLY substantial, solo, all-night Linux install parties!    ). My current x86_64 install, which is what I'm using now, is a fresh install, but it's not really any faster than a month's-old Arch32 install on the same computer.
Sorry for the tome. It's my birthday and I'll write if I want to...
Yes, I know this post is timestamped the day after, but I assure you I started this before midnight! 
I have no intention of "graduating from" Arch i686. I fully intend to keep both on my system (at a MINIMUM) - if one install gets borked, you can get to it fairly easily from another install on the same machine (of something DIFFERENT - I make sure to update a new kernel to one system for a week before updating the other.
A single /boot partition for a dozen distros, with a relatively easy (straight-forward, at least) and painless method for handling kernel updates from multiple distros on one machine....shared swapspace...shared storage...
On the rare chance that someone (a) is still reading, and (b) feels this is a rational start of a Wiki page, I'm willing to maintain...
Blue Skies...Keith/grndrush
Last edited by grndrush (2009-01-05 05:30:51)

Answer 1

Thanks to you both.
As to the 1024 cylinder limit, again, I think there are very few remaining out there in operation (*I'll* never have one, LOL) with the 1024-cylinder problem, but I HAVE had a few problems with relatively recent (in 'my' terms, which means ancient) hardware where Linux doesn't want to boot using a *logical* partition for /boot - hence the homegrown workaround to get /boot at the end of the disk. You're 100% right - today, it's not worth the time or hassle of doing so. I simply thought like this since BEFORE the days of 20 MB HD's!  .
Thanks again. Five years using Linux doesn't seem *nearly* as long as five years running Windows (although it DOES seem like a good 5 years since I've used Windows voluntarily). And, of course, these ARE faster machines...