Virtual Disk used for Persistence?

[CentralWare]

I have an HP laptop with a 160GB drive, junk for BIOS options (overlapping AMD/ATI video memory), 4GB DDR3 and the desire to split the drive off more times than partitioning will normally allow (ie: A testing/working/development environment for 4x86, 4x64, 5x86, 5x64 and 5xPure totaling out to ~15 partitions.)  Each version needs its own persistent home, opt and tce directories.

I tried boot codes of tce=sda1/tce4x86 -- this works fine.
I tried boot codes of opt= and home= the same as tce= and it fails, claiming the other two are being disregarded, thus I have to assume only tce-setup (tce=something) supports paths?
I tried boot codes with labels...  again, only tce= followed the need.

As such, I considered since the number of environments will exceed the normally allowed partition count of a single drive, what about using virtual drives?  I ran a quick search in the forum here but haven't come across anything pertaining to what I'm after.

Example:
/dev/sda1 has a label of tinycore
sda1/images/tc4x86.img would be an image (say 5GB) with a single partition formatted ext4.
The "goal" here would have boot codes with an outcome similar to
vdisk=sda1/images/tc4x86.img  tce=vdisk  opt=vdisk  home=vdisk or something of the sort.
Is there anything in place that comes close already?

Thanks for your time!

[gerald_clark]

Look at the tcvd boot option
http://wiki.tinycorelinux.net/wiki:boot_options?s[]=tcvd

[CentralWare]

@Gerald: From what I read (last paragraph of wiki) some time ago, it sounded as though Qemu images required said software to create and utilize the images their software built.  Strangely enough, it also sounded as though the images themselves had to have a partition table, but to mount the image, it had to be bypassed (offset=32k) which sounded a bit "out in left field" to me.

What I was hoping is that we had something in-house that could be used in a fashion to AoE images (I'm wondering if we could actually use AoE images for that matter, just hosted through loopback instead of ethernet if worst came to worst.)

The "ideal" scenario would be:

1) Create an empty image dd if=/dev/zero of=filename.img bs=1024 count=(#ofGigs)M
2) If a partition table is required for some reason, fdisk it
3) Format directly or, if fdisk'ed, block-mount then format the partition
4) From tc-config/tce-setup mount the disk/partition and utilize tce=/opt=/etc. thereafter.

Because of the offset=32k I have to assume the above design doesn't fit tcvd=imagename.ext??
I'm going to experiment in different directions; I'm just hoping there's something already tried and tested without the need for remastering as I'm hoping this particular project leaves the kernel and ramfs "as is" as it's intended for a development environment and a customized boot could easily cause unnecessary mishaps.  (If necessary I could always just implement a boot script launched from bootsync which checks and dismounts opt/home and relocates tce...  but that seems a bit redundant if it can be avoided.)

Thanks once again for your time and efforts!

[Rich]

Hi centralware
These might be of some interest to you:
http://samindaw.wordpress.com/2012/03/21/mounting-a-file-as-a-file-system-in-linux/
http://unix.stackexchange.com/questions/119364/how-can-i-mount-a-block-device-from-one-computer-to-another-via-the-network-as-a