|Meet the Gang 1 2 3 4 5 6 7 8 9 10 11 12|
From Orla McClean
Answered By Thomas Adam, Ben Okopnik, Heather Stern, Jim Dennis, mike ellis
I need to install and be able to boot a couple of Linux distributions on one machine (along with W2K) Is there a recommended method for doing this?
[Ben] Probably not; most folks tend to run just one distro. I can certainly see wanting to experiment, though.
Linux is flexible enough that there is no single recommended way to get multiple Linux distributions installed on the same system. There are lots of ways you can do it and each can meet some needs, while each requires you to understand how UNIX and Linux work "under the hood" and each may entail various tricks to implement.
[Thomas] Well....you could always try un-installing W2K <grins>...
[Heather] One of my friends has a dual-boot laptop: Redhat because he needed to understand the environment at work; SuSE because he wanted to see a dif't rpm based system, and its init system is a mite different too.
On my personal laptop I have 2 bootable areas; one's a dev setup, the other is my normal life on there.
W2k is the hard part. I don't have any MSwin boxen right now, but the generic procedure over the years has been:
- install Windows. expect it to take over the whole drive. (obviously this is much easier if it came with MSwin already)
- get all its apps settled in as happy campers
- defrag and get the swap volume away from the end of the disk
- resize its partition to give you a bunch of empty space. DO NOT format this space under mswin.
- boot off your linux install media
- reconfigure the blank space only. Depending on your resizer you may have to delete a bogus D: (second vfat) to give you the space clear.
[Ben] Huh. All I've ever done is one of the two:
- Install basic Wind*ws.
- Use "FIPS" or whatever to split off whatever I want of the remainder.
- Install Linux.
- Boot with Tom's RootBoot or some other quickie; partition the HD.
- Install Wind*ws in one.
- Install Linux in others.
I've never had a problem... I think it may be that Wind*ws recreates its swap file as needed. If I ever suspected it of giving me problems, I would just delete it.
[Heather] Merely basic paranoia. I've been doing that sort of thing for a long while and MSwin 3.1 wasn't really happy about it. However it was quite easy to "defarg" - just tell it you feel like going with no swap file, and after giving you the "living dangerously, eh?" rant, it would let you.
What partitions should I share etc (swp, boot?)
[Ben] "swap" ...
[Heather] Trust me, swap doesn't give a rat's patooties. Unless you're using swsusp patches (in which case, join the Gang, we could use your expertise) there's no reason for it to, either.
See the "Windows sharing Swap with Linux" HOWTO, I forget which one it is, but it's definitely on linuxdoc.org and therefore in most of your major distros too.
Now *there's* something you can share, whatever passes for the Linux Documentation Project (LDP) mirror inside your distro kit.
[Ben] "boot"... eh, it may be possible, but you may be opening a can of worms; I would separate everything as much as possible (this assumes that disk space is not an issue - since you're talking about installing multiple distros, I'm taking that as a given.)
[Heather] Boot is a much happier thing if it's early on the disk - esp if you're planning to experiment with off-brand boot loaders. So having One Place For Kernels is a good thing. Making them keep their modules with them, means less headaches later.
To do this trick, you'll need room for the modules as well as the kernel itself. This kit has been getting larger as time goes on, too. So you should have more like a 20 MB /boot or 40 MB instead of 5-7 MB. (40 MB is probably room for 3 to 5 kernels and their stuff)
After you have distro #1 installed:
cp -a modules /boot/modules
mv modules MOVING
ln -s /boot/modules modules
After you have distro #2 installed:
cp -a * /boot/modules/
mv modules MOVING
ln -s /boot/modules modules
repeat for as many distros as you put on there...
After you've rebooted it should be safe to get rid of /lib/MOVING. In theory if the files aren't open... but no, it's much safer to have rebooted.
[Ben] <smile> That's what I meant by "a can of worms". My assumption here was "keep it as uncomplicated as possible".
[Heather] Ah, but for a moment's complexity during setup, we get simplicity later:
up2date wants to offer a new kernel
kernel.org says 2.5.n came out
make menuconfig && make dep make modules && make modules_install && make bzlilo
(well, that last might put the kernel "hard" in / as the file vmlinuz, but it's normally a symlink there) Basically things about kernels go to the right place then, happily ever after.
Keeping your lilo straight, that's your can of worms. But it's already open the moment you said "dual boot" much less triple.
I have managed to get redhat and mandrake working, but when adding Suse, I run into problems.
[Ben] <Sigh> Go to http://www.linuxgazette.com/tag/ask-the-gang.html and read through the guidelines, especially the part about 'Beware of saying "doesn't work"'. Then, rephrase the above question and try again.
[Thomas] Since you're using W2K, is it not perhaps feasible to add menu entries into errm <consults that aging brown notebook of "DOS" commands>...config.sys and autoexec.bat, rather than using Lilo???
Also my solution is probably very crude. (Literally mounted the partition with Mandrake on from RedHat and put the boot file in lilo.conf)
[Thomas] That is ok.....but I would have lilo installed on one partition that you select, and then have stanzas within that which points to the other drives.
[Ben] OK, I understood the part about mounting the "Mandrake" partition... could you explain what you mean by 'put the boot file in "lilo.conf"'? As far as I know, the only things you can put in "lilo.conf" are "lilo" keywords, things like stanzas that specify partitions to boot, etc. What's a "boot file"?
[Heather] Lilo.conf really has to be plaintext. Anything else is a disaster. Lilo is limited to 16 boot stanzas.
[Ben] Yep; that's what I knew about it.
I'd like to have a shared home directory partition, but beyond that, whatever the most elegant structure for partitioning etc is, is what I want.
[Heather] No. You cannot share /etc. I have tried and it's broken and wicked. Too many variations of apps have slightly different control structures in dif't software revisions.
The closest I can offer you there is that you can mount /home and assign each major app that you are going to keep in sync on all N distros -- e.g. apache or bind -- their own "home" for their control files, and again put in a symlink for the applicable place. But that symlink has to be named what the distro expects... if one wants /etc/httpd and another wants /etc/apache, you will break things if you try to "normalize" them.
For /home be careful about dotfiles. More on that later.
I have searched the HowTo's etc on this, but to no avail - most discuss using only one linux distribution. Maybe I need pointing in the right direction?
[Thomas] Why have multiple copies of Linux distros in the first place??? -- perhaps that is a silly question.
On my 6.4 GB harddrive (using SuSE 7.1 professional), I have partitioned it thus:
2.0 GB /
2.0 GB /usr
1.0 GB /home
1.0 GB /archive (backup partition)
Hope this Helps?!?
[Ben] Well, in theory, what you want to do shouldn't be that hard: you'd just end up with a lot of partitions. Or not - since you're experimenting, and are presumably going to blow all this stuff off at some point, you don't have to be quite as persnickety about carefully isolating everything.
[Heather] At some point you may have to use mknod and create more dev nodes; your distro may not be prepared for having /dev/hda14 for example.
[Ben] As an example, for a typical production system, I might have something like:
hda1 swap 128MB is a reasonable "I have no idea what I need" guess
hda2 /tmp 100MB, more if you abuse it like I do :)
[Heather] My favorite /tmp abuse is that this is where tarballs are unpacked when I surf into them with Midnight Commander (mc).
[Ben] <laugh> I see that we have the same exact definition of "/tmp abuse".
hda3 /boot ~10MB
[Heather] When you add the modules into this, 30 MB or 40 is more like it, but well worth the synchronized behavior you get. Also if you roll your own kernel at some point it will become "live" to all your distros at once.
hda4 /home (varies w/amt of available space)
[Heather] and amount you expect to use it. If you're just gonna surf this doesn't need to be huge, and might not need to be seperate from /
But if you expect to use it for anything - downloads, a few music files, letters to mom and cool pictures - you'll want it seperate.
hda5 /usr ( -- " -- )
hda6 /var ( -- " -- )
[Heather] log files, mail go here. If you don't do much mail and prefer not to watch logs then 200 MB is fine. If you're running a news server (?! on a triple boot? no way) you'd need a bunch more.
(A later caveat that occurs to me is, this is also where the package manager databases are stored, so don't cut it down too far, or you may have trouble adding packages.)
hda7 / ( -- " -- )
[Heather] distros vary on their minimums for this; a couple of them seem to insist on a /opt; I always symlink /opt to /usr/local at the earliest opportunity; because I'm experienced, I can do this during the install -- just make sure the target systems are mounted but you haven't made software selections yet, then visit the other virtual consoles.
In SuSE last I looked this would cause it to whine about free space but it would still do it and everything would work.
[Ben] For what you're doing, you might want to think about something like
hda1 swap 128MB hda2 /home Whatever space you care to allocate to it hda3 /D1 Distro1 hda4 /D2 Distro2 hda5 /D3 Distro3
and so on; mount /hda2 on "/home" for all of them. Slightly crude, but effective - and a lot of people have their 'regular' running setup done this way (I did, for several years.) When you're done experimenting - presumably you will be, at some point - you can blow off that partition structure, all except the first two, slice the remainder to taste, and garnish with a little bit of ext3 or ReiserFS. Yum.
[Heather] Errr, recall he mentioned MSwin.
hda1 C: 1 GB+ hda2 /boot 40 MB hda3 swap 128 MB <-- this can be more, if you have more memory. hda4 extend hda5 /tmp 400 MB hda6 /D1 Redhat hda7 /D2 Mandrake hda7 /D3 SuSE hda8 /D4 Debian . . . etc ad disc-emptia . . .
[Ben] Or less, if you have more memory. Just depends on how much "more" actually means, and how hard you flog it.
[Heather] yeah, well, I do a lot of jpeg stuff, and then switch off to other things; if it's gonna swap, it needs to swap to somewhere.
[Heather] And of course we have our stranger experiments.
[Ben] Yep, I'm having fun playing with a journalling file system. 'Snice.
For example, I run Debian on my laptop. The bootable installation is Debian Potato (stable). Under /home/.chroot (a subdirectory) I have an entire installation of Debian "unstable." When I want to play with new features I use the following commands:
cd /home/.chroot && chroot . /bin/bash
... and I'm able to work in inside of that directory almost as if I'd booting using that system. (My kernel, networking and some network services/daemons, and cron etc are all "outside" of this subsystem --- but that isn't a problem for what I want to do, and there are various tricks I could use to work around those limitations if I need to do so).
Heather (my wife, and the editor for LG TAG), has a "Debian" chroot on her S.u.S.E. desktop system. If I understand it correctly she uses that to test out software upgrades and installations before rsyncing it to her laptop. So the Debian subsystem on her desktop is also a mirror/backup of her laptop.
[Heather] Um, actually, I have several...
I have 3 debian chroots...
- a "pure backup" of my laptop... I keep thinking someday it'll be a way for me to hotsync more like an MSwin "my briefcase" ... since my canonical mailbox is on the desktop, and my projects have their own users on the desktop but sometimes only directories on the laptop. But for now, it certainly works.
- a "pure potato" build environment, which I use for running 'apt-get -b source' against unstable source trees, and for building external sources
- a "woody/testing" build environment, for pretty much the same, but up to date stuff. Also for testing that things can install in plain testing without causing headaches.
Every once in a while I clone the "pure" one to test upgrade behaviors before inflicting them on my laptop, which I consider to be a production machine. And then I just drop the apt archives across.
But I also have the LNX-BBC dev environment (chrooting into that kit takes some ramdisks and loopbacks) and make my own Tom's rootboots (likewise) so my /mnt area has subdirectories:
/mnt/a floppies /mnt/cd the real cd /mnt/bbc for loopback mounting cd's /mnt/b for loopback mounting floppies /mnt/r0 r1 r2 r3 ramdisks /mnt/point the "guest" mountpoint, most folk would use /mnt
For distro chroots, partition the beastie using your favorite method.
/home/distro1 (a chroot environment containing the whole of another distro)
But, this is harder to set up the first time, since some installers can't deal with the idea they can't own the partition. Gosh, you'd think they were following the tracks of those from Redmond
In my case the extra distro area started as a proper backup of my laptop, but has, ahem, evolved considerably since.
It's also possible (with a little fussing) to install a set of different Linux distributions such that they all share one /boot partition (which just holds kernels, System.map files, and a few map, backup and library bits). A complex lilo.conf file can then match each distribution's kernel to its root filesystem. So you might have something like /boot/vmlinuz-SuSE-2.4.14 matched to /dev/hda7 (it's root fs). Thus you select SuSE and lilo picks the kernel, passes it a root=/dev/hda7 (and possibly some other parameters) and you're in your SuSE system. All of your distributions can share the same /boot and /home, /usr/local or other ancillary filesystems --- but each can get its own root, usr, and var (which can be separated or combined in just about any way that suits your fancy).
[Heather] Oh, I'd be careful about /home ... beware of what the dotfiles in your user home directories might get themselves into. Some apps like The GIMP are written well for the expectation they'll be revised. Some others (like Netscape 4 vs Netscape 6) may not be so inclined to do the right thing. Avoiding having dotfiles at all for any apps you just don't use helps a lot.
The fussing is just in the installation. In some cases the easiest installation procedure might be to start with an extra (small) hard disk, install the distro into a suitably small partition or set of partitons on that; back that whole system up, and then restore it to a set of manually created and mounted partitions on your main hard drive.
Bill Schoolcraft, a talented and enthusiastic Linux support professional with whom I had the great pleasure of working while I was at Linuxcare, had his desktop system configured with about a dozen different Linux distributions using some scheme like I've just described. He also had FreeBSD, OpenBSD, and "Open"-Solaris x86 installations on that or some other system.
Under this scheme its also possible, and reasonably safe, to try mixing and matching the kernels from any one distribution with the root/usr filesystems of any other. All of that will mostly work, though you might find some programs complaining about missing support for one or another optional kernel features.
[Heather] For the readership - that'd be amongst linux distributions ... the BSDs probably are not safe to share that way.
It's also possible to mount up the "alien" filesystems in just about any silly combination you like. So you could boot into your RedHat 7.2 kernel with its rootfs (all on ext3, perhaps) and mount your SuSE/Reiserfs rootfs under /mnt/suse (or wherever). This is possible because the RedHat 7.2 kernel has reiserfs support linked into it, though it's practically undocumented. If you stick with ext2 for all of your filesystems then there will be no problem sharing those under any distribution you could find. If you try to mount a RedHat 7.2 ext3 filesystem under a S.u.S.E 6.x distribution it might fail or (because of ext3 backwards compatibility to ext2) it might work but have some odd effects if you hadn't cleanly unmounted/shutdown the fs when it was mounted under an ext3 capable kernel).
[Mike E] Just had a thought on this thread - the original problem was to to with SUSE co-existing with RH/Mandrake
Could it possibly be a problem with Reiser - I know that SUSE (7 and above loads reiser cant remember which version default - RH guy) but reiser does not play nicely with ext2/3 especially in boot/root partition - worth looking at
Of course you can also build your own kernels and ensure that they have support for all of the features you need from all of your distributions and for all of your filesystems. This isn't any more difficult than building a kernel for "just one" system and distribution. (There isn't that much difference in features among the distributions at the kernel level. Most of those apply to special packages, like Oracle, or special hardware like some chipsets and adapters that are common in Europe and obscure on this side of the pond, etc).
Yet another technique is to install a copy of VMWare (commercial software) and use it to create a number of "vdisks" (disk images) and then to install different distributions into each of those.
And, of course, it's often possible to keep a small stack of extra hard drives around, and some laptops have carriers and brackets that make swapping drives relatively convenient.
So, you're really only limited by your own creativity and willingness. Do the "Schoolcraft" thing: install a dozen distributions on that 60Gb hard disk today!
|Meet the Gang 1 2 3 4 5 6 7 8 9 10 11 12|