How to build a dual-booting Linux system on a single hard drive (developerWorks)

Posted Jun 18, 2002 14:43 UTC (Tue) by nicku (subscriber, #777) [Link]

The same principles apply in programming.

My preferred method is:

1. Setup each Linux system with Lilo installed in its root partition

2. Have one grub (or Lilo) set up to boot that particular partition, but not require the first (primary?) installation to know about the kernels, partition arrangements, etc in the other Linux installations.

3. Advantage is that when upgrade a kernel in Linux x, no need for Linux installation a to know about it, i.e., no need to reboot into a, edit _its_ lilo.conf and run lilo just because you applied an update to Linux x.

Posted Jun 18, 2002 20:40 UTC (Tue) by AnswerGuy (guest, #1256) [Link]

For several years I've used chroot subsystems for similar purposes. Basically I install entire distributions, or replicate installations, into subdirectories. For example the workstation I'm on right now has Red Hat 7.1 as the boot OS (not my choice), and it has a replication of that installation under /u1/redhat-chroot. It also has two different Debian/Woody installations under /u1/debian and /u1/debian-play. Thus I can run under any of these environments using the simple commands: cd /u1/$TARGET && chroot . /bin/bash

I can run many such processes concurrently. [Indeed, I'm compiling our project under one of them as I type, and I'm testing programs in another periodically]. Of course I have to prepare each environment by mounting its own version of /proc. Sometimes I have to modify my startup scripts (such as sysklogd to add the -a option --- adding additional .../dev/log sockets to it's listening list) or play with .Xauthority files and DISPLAY variable settings. Sometimes I use mount --bind or even NFS loopback mounts to share access to selected directory trees among multiple chroot jails (bind mounts where only added in the 2.4 kernels). There are a number of tricks that help with specific cases.

However, each of these chroots is almost completely independent. The only things that they are sharing are their kernels, /proc and network interface states.

This is why the chroot() system call was originally created; as a development tool. (It actually doesn't work very well as a security tool; historically there have been too many ways for a maliciously subverted root process to "break out" of chroot "jails.")

This is not to discount the value of the technique that was being described. It is also useful to have completely independent installations (kernel and all) with boot-time isolation among them for some tasks; especially some testing harnesses. The techniques are not mutually exclusive, either. It is pretty simple for the /u1 directories (from my examples) to be mount points of independent installation filesystems.

Back when I was at Linuxcare one of the technicians took the time to take this technique to it's logical extreme. He had an elaborate installation of about a dozen Linux distributions (and FreeBSD, OpenBSD and Solaris x86) on a single system. All of the Linux distributions were configured to cross mount filesystems from any of the others. This allowed him to quickly test behaviors among many distributions, libraries kernels, etc.

I use this technique on my laptop to support Debian stable (boot time and core utilities and environment) and Debian unstable (keeping up with the bleeding edge). That allows me to access all the latest Debian software while providing a safety net of core functionality that's ... well ... stable!.

My wife uses another variation to keep a fully functional backup of her Debian laptop in a subdirectory of her S.u.S.E. desktop system. She uses rsync to move work in either direction (and she handles the occasional conflict by hand --- cases where she's made overlapping changes to the same fileset on both locations). So this functions both as a working copy *and* as a backup. (Arguably a bad idea if it was her only backup; but good enough in practice).

So, I hope readers will come away with some ideas. Linux is amazingly flexible (often too flexible for most users). This is just a sampling of what one can do with a bit of disk space and the chroot command.