Have you noticed this proposal below? Doesn't seem extraordinary at all. The question is whether kernels are happy with this:

If /dev may NOT be moved to the big partition and symbolically linked to, maybe /bin /opt /sbin /sys /var /boot /etc /media /proc /tmp /home /lib /mnt /root /srv and /usr can.

Then the installation partition of each distro only contains /dev and symbolic links. So it can be resized with gparted to something very small, leaving all the free space in the big all-in-one partition.

The effort required to get each distro working as it should with 5 other distros all in the same partition (remembering, even though it is Linux, distros like Debian and RedHat do have very different configurations) would far outweigh any benefit and probably cause huge compatibility issues.

Why are you saying there would be extra effort after moving directories and resizing partitions? Is it just a guess or symlinks are known to cause trouble?

Didn't you read it?

How many symlinks are you willing to make? How long are you going to spend to have 6 distros in the one partition each competing against each other?

mint 8 does not have ureadahead or plymouth (good thing to)
mint 11 does have ureadahead and plymouth. How are you going to stop Mint 11 negatively affecting mint 8?
mint 11 AMD64 how do you propose to run a 32 bit system and a 64 but system from the same /? Debian is just now bring in multiarch support and it takes more than symlinks to do it, how do you propose to do it?
slackware-based vectorlinux 6 lite I know nothing of except what I read here and apparently you install and work through your own dependancies. How will you install things in this system when you have apt-get in 3 others? how will you stop vector breaking dependancies in a dpkg system?
vectorlinux 6 STD etc
tinycore etc.

The level of work, skill and expertise required would be phenomenal and, not being slack just pointing out the bleeding obvious, the fact you are even having to ask says to me you don't have that level of skill and expertise.

It was not specific enough.

15 symlinks for mint 8 (/bin /opt /sbin /sys /var /boot /etc /media /proc /tmp /home /lib /root /srv and /usr), another 15 or so for vectolinux, etc. Maybe a for loop can create them after moving the actual directories.

I do not see any competition if they operate on different files ignoring the files of other distros. Maybe you expect competition because you are thinking of a setup different to the setup proposed, so here it is explicitly:

partition hda1 (mint 8) root directory:
/dev (actual directory)
/mnt (actual directory)
/etc (symlink -> /mnt/hda7/mint8/etc)
/proc (symlink -> /mnt/hda7/mint8/proc)
... etc

partition hda2 (vectorlinux) root directory:
/dev (actual directory)
/mnt (actual directory)
/etc (symlink -> /mnt/hda7/vectorlinux/etc)
/proc (symlink -> /mnt/hda7/vectorlinux/proc)
... etc

partition hda3 (redhat) root directory:
... similarly

partition hda4 (tinycore) root directory:
... similarly

partition hda5 (suse) root directory:
... similarly

partition hda6 (arch) root directory:
... similarly

partition hda7 (holding all actual directories pointed at above):
/mint8/etc
/mint8/proc
/mint8/... (rest of mint8 root dirs)
/vectorlinux/etc
/vectorlinux/proc
/vectorlinux/... (rest of vectorlinux dirs)
/redhat/etc
/redhat/proc
/redhat/... (rest of redhat dirs)
/tinycore/etc
/tinycore/proc
/tinycore/... (rest of tinycore dirs)
/suse/etc
/suse/proc
/suse/... (rest of suse dirs)

So in this setup, isn't ureadahead irrelevant? Isn't 64bit versus 32bit irrelevant too? Is the ext3 filesystem different for 64bit architectures?

But distros do not look at each other's files in the above setup, only files that belong to each distro.

If there is any application that refuses to follow symlinks, then it's the application's broken design, not the distro's.

Or does any distro refuse to follow symlinks and requires actual dirs?

Crucial: when /dev/hda7 is mounted at /mnt/hda7, what system files have been accessed up to that point?

(Boot manager can be on a separate partition just for booting, no symlinks there).

I'm not writing a book for you.
I don't think so, if you want to try it then do it, you have been given answers yet you seem to be determine to do it. If that is the case then just do it and report back when you have it working as individual OSs and working as each should.

If it works, perhaps with one or two more dirs being actual instead of symlinks, will you come back here and say sorry for the incorrect answers?

Ah...booting. In your symlink list above, I noticed that you neglected to mention the "/boot" directory. A separate partition for "/boot" won't work for that. Contained in each "/boot" directory (or partition) is THE key part of any Linux Distro...the Linux kernel itself. Each Linux Distro has a relatively unique kernel. They might be numbered the same, but they are tweaked and configured according to requirements of the Distro they come with.

How will you handle accessing the correct kernel for 6 different Distros when they're in 1 directory, with some of them named and numbered exactly the same?

Also contained in the "/boot" directory is GRUB Stage 2 and beyond. Each one is set up by the installer and launches its Distro. The bootloader in the MBR is only stage one...a very small segment of code that points to the rest of GRUB in the "/boot" directory of the Distro that put it there, usually the Distro that was installed last (unless you know what you're doing at installation time).

How does the controlling GRUB differentiate between them and detect them for inclusion in the GRUB boot list when the files are all in the same directory? How does "update-grub" do this when one of them has been upgraded (if it can be...I'm not sure how apt-get would differentiate)?

I don't think k3lt01 was saying it would be impossible. He was saying the task would be monumentally difficult. I think I agree. If you take it down that road, my hat's off to your tenacity. If you accomplish it, I will be the first to bow before you. I'm also sure there would be any number of dev teams that would be delighted to welcome you to their team.

I seriously don't know. The root directory "/" is just that. It is the highest up the directory tree as you can go. The concept of creating some kind of "super root" which contains several "root" directories, let alone how such could be accomplished, is beyond my level of comprehension. Yet, it has been done...it's called Wubi...so obviously it's possible.

If you have that level of ability in programming and development, you might want to up the ante and try some developer sites and mailing lists. You'd be a lot more likely to find help with such advanced concepts. I don't know about anyone else, but I'm at my limit.

Missed this earlier, BTW:

To me, that just sounds like you'd be stuck with the 6 Distros you already have. Wouldn't it still be possible to use that drive to process and store files and such? Or does that cause shutdown, too?

What answers have I given that could be considered incorrect?

That's exactly my point.

See the quotes below. At NO STAGE have I said it would be impossible.

Are you now going to apologise for your statement Ulysses? I doubt you would.

Any news?

You also need at least the directories /bin, /sbin and /etc on that partition.

@-kg-: It is absolutely no problem to use a distro independent partition for booting/installing a boot-loader. It also is no problem to install the boot-loader only in one bootloader. If you have 6 distributions that doesn't mean that you have to install 6 boot-loaders, one is totally sufficient.

@k3lt01: Wubi is not installing Ubuntu to a directory, it uses a loop mounted image file.

To the original question: Yes, it should be possible. But considering the vast amount of space on modern harddisks I think that nobody has tried it, just because there seems to be no need for it. Who really cares for 1 or 2 GB nowadays, except you really have a space issue, like on a netbook with a very small SSD?

1 members found this post helpful.

Have you thought about virtual machines? Why do you need it 6 distros in the same machine/hard drive? Wouldn't be easier to run virtual machines? That way you can have more than one distro running at once? About Tinycore it can live in a couple directories and doesn't need own partition(s) as you can see here,
But then if what you are doing is a project and virtual machines don't apply, you still have the hint about Tinycore!

Regards

Ok now i'll put my hands up and say this is just an idea and I don't want to get any bad flame from any one for it or do want to have to apologise to anyone, nor will I.

Have you considered a zfs file system that lets you use multiple, seperate mount points that share the same common pool of space. This would avoid your free space being fragmented and would save you a head ache.

I say again.... Just an idea.