AFAIK, ZFS is not supported on Linux due to licensing issues.

Thaks for quick reply. I wont waist time looking further then.

And what about butter fs (btrfs) this file system has pooling, and is supported by kernel right? but young and unstable. but might achive the goals of OP. just a thought.

ah ok, thanks Tobi. I have never used WUBI but know of people who have and the way they told me about it didn't explain it fully. Thanks again.

I beg to differ. I completely understand that a distro-independent /boot partition is (relatively) no problem. I've done it before, and dropped it as it was a bit onerous for me to maintain. Every time something changes in one of the distros (like a kernel upgrade), you have to manually edit the GRUB menu to reflect the changes. Since it is distro independent, there is no way to use "update-grub" to effect those changes.

However, I disagree that "6 distros don't require 6 bootloaders," unless you mean the one in the MBR. As I stated, in the root partition of each distro I've ever had is a /boot directory. In that directory are files and a directory that are vitally important to that distro.

First, there is the /grub directory. GRUB is not only what gives you the directory you see on boot-up (i.e., the GRUB menu). Later stages of GRUB are what launches the OS associated with it. The GRUB associated with the bootloader in the MBR just points to the subsequent stages of GRUB of the distro (partition) that you select for booting.

Second, and certainly not least, are the Linux kernel files. Those are the basis of the whole shebang. If a separate /boot directory is not required for every distro, then where do these files (especially the kernel files) reside?

I'm perfectly willing to accept that I might be wrong, but I don't think that I am.

To OP:

There are perhaps solutions to your problem AFAIK:

- The difficult one: you need to understand distro of your choice. Since this choice determines the success of merging the six distros. Some distro has similar directory hierarchy that you cannot mix them, e.g /etc/init.d or /etc/sysconfig. Having choosing the right distro you need to recompile their /sbin/init (because init is binary)to suit your purpose and then rename it as their init{rd|ramfs} refer to, e.g, /sbin/init-mint /sbin/init-vector-11. This also require you create your own initramfs containing script to find those inits.

Problems that will come with this setup: some distro need certain version of kernel, its header and some tools to work properly.

- Another alternative: create read-only compressed rootfs (that can be mounted rw for later update) along with script that automatically mount their (separated) /home and virtualfs. This can also be done by using initramfs.

You need 6 kernel or just a recompiled one, 6 init{rd|ramfs} (each refers to their respective /sbin/init-*) and six modified inits. One grub partition, so grub is independent. Regardless kernel version these are usually virtualfs and/or mount points: /proc /sys /dev /srv /run /misc /media /mnt /net (btw, someone might want to correct this).

In addition, you can frugal-install some distro such as Slax, Porteus, Tiny Core and Slitaz. You can also use grub2 loopback function to load directly from iso hence saving space.

Apologize for my English.

Nope, just use symbolic links to your kernel, then you have not to change anything on the bootloader partition.

Again, a bootloader is only needed once. If you don't install one in the second (third, fourth, ...) distro on a computer you will nonetheless be able to boot that distro, done that, works fine. You will most likely also don't have the /boot/grub directory when you don't install grub.
You understand the differences between a bootloader, the /boot directory and a boot partition? Why should the /boot directory (or the kernel files in it) be removed if you don't install a bootloader?

OK, I stand partially corrected. I have primarily dealt with Debian-based distros, which have 4 boot stages.

http://www.debian.org/doc/manuals/de..._debian_system

I didn't realize that not all distros used these extra GRUB stages.

And yes, I do know the difference between a bootloader, a /boot directory, and a /boot partition, though in operation the last two operate the same way. The /boot directory is the /boot directory, whether it resides on the root partition or is on it's own separate partition. It's considered a directory by Linux, no matter where it actually resides.

This is not a Grub stage. The usage of an initrd is also not distro dependent, you can use Debian without it if you compile a custom kernel and you can use it in any distro, if you need to (for example if your /-partition is a software-RAID).
To make that clear: The bootloader (Grub or any other, not every distro is using Grub) loads the kernel (and if configured to do so the initrd) to RAM and then hands over the control to the kernel. This is what happens at the beginning of stage 3. From that point the bootloader is not anymore involved in anything on that system, those extra stages are not related to the bootloader.

/boot is only 17 MB anyway, not an issue at all, it can stay as an actual directory.

Symbolically linking just /usr is causing failure in mint. But unlike /boot, this cannot stay as actual because it is huge and may grow. Maybe it was not moved properly causing credentials to be affected or any non-regular files to be affected.

So what is the proper way to move /usr or any other directory? "cp -a" then "rm -fr"?

Mint 11-64, vectorlinux 6 and tinycore are probably the best options worth investigating if trial and error is the way.

Tinycore is happy inside a directory in mint's partition or any other partition. Sorted.

It remains to be seen which directories of vectorlinux can happily go inside a directory in another partition rather than stay as actual. Clearly NOT an issue of compatibility but an issue of symbolic links and that alone.

Here's a screenshot of mint failing, if this is of any use.

Attached Thumbnails

 

Seems that it can't find some executables, which means they are either not at the expected location or not marked executable.

If you have to put it in another partition it is showing that there is incompatibility that even symbolic linking cannot fix.

Are you saying that a problem would not have occured if mint was alone with no other distros installed and /usr was moved to another partition? But a problem occurs or will occur because vectorlinux is installed in yet another partition and could be doing the same with its /usr directory? So it is a compatibility issue between distros as you've been saying all along (64bit versus 32bit etc in post #19)? Can't believe how much obvious BS they allow you to post and never withdraw it.

If it is caused by executables that are not marked executable, probably because the moving is not done correctly, I'll try moving the files by other means: duplicate the entire mint partition with gparted. Then symbolically link to selected directories, and the remaining dirs can be temporarily renamed. And see what happens.