Same partition as other Linux distro with persistent home and opt?

[Guy]

Tiny Core can be installed in the same partition as another operating system.

You can put the boot directory in the tce directory.

This will work if you use backup.

If you install Tiny Core in the same partition as another Linux distro, and use persistent home and opt, they would mess up the home and opt directories of the other distro.

Is there a way to install Tiny Core in the same partition as another Linux distro and use persistent home and opt?

[roberts]

That is by design. You can search the forums to see when it was discussed and when I implemented it.

That way with a single user can login to either tinycore or the embedded system and all your home files are in one place.

Besides the default 'tc' user is not likely an existing user on the embedded system. And not likely for conflicts in /opt either.

[maro]

I think the OP raises an interesting point insofar that I struggle to find a reason not also to support a 'home=partition/directory' style boot code (and of course by extension the same for 'opt=...').

Sure, the immediate number of users now wanting such a feature might not be large, OTOH it would allow more "cleanly" to seperate TC from the "legacy style" installation by allowing such an enhancement. Surely this does not need to be a huge code change (as the components are already present for the 'tce=...' boot code). I'd imagine that a bit of code refactoring would be possible to pull the treatment of these three boot codes further together via some (new) functions in '/etc/init.d/tc-functions', but maybe I'm overlooking something significant here.

Robert, I've spend at least 10 minutes to find "... when it was discussed ..." so that I can relate to the state of that former discussion, albeit I was unable to find it. Maybe you have a better idea either about the timeframe or some other "marker" that could be used to identify said thread.

[tinypoodle]

Sure, the immediate number of users now wanting such a feature might not be large, OTOH it would allow more "cleanly" to seperate TC from the "legacy style" installation by allowing such an enhancement.

I can't exactly understand "legacy style" in context. Could you please define?

[roberts]

* Improved support of persistent opt when sharing with an existing /opt directory.
http://forum.tinycorelinux.net/index.php?topic=1035.msg5840#msg5840

Note too that the booting CD with boot code of home=hda1 will automatically make /home/tc on hda1 or
if this is an already existing linux system, will simply add tc/ under the existing /home directory.
The home directory will be completely setup for persistency.

http://forum.tinycorelinux.net/index.php?topic=2833.msg14511#msg14511

The grub line as above shows that I want to have user tc added to the existing /home
from currently setup from Ubunutu.

http://forum.tinycorelinux.net/index.php?topic=3232.msg16781#msg16781

Even using persistent home, will in fact co-exist with an existing Linux home directory
same for persistent opt.

http://forum.tinycorelinux.net/index.php?topic=4044.msg21487#msg21487

Thank you for expanding the scope of persitent directories in TC 1.1
The majority of my hard drive is a single partition sharing data between 4 distros,
and it's very easy now to put my home and tclocal on that same partition.  
I was pleasantly surprised to see hda4/home now being mounted as /home rather than hda4/home/tc

http://forum.tinycorelinux.net/index.php?topic=633.0

I don't see the original request. That might be because it came up in IRC.
Back when I was visually able to keep up with IRC.

Bottom line it has been around since v1.1.

IMHO having two "home" directories and/or two "opt" on a single physical hard drive partition is "messing" up any Linux distribution. In fact I would say that it would be heresy.

You always have the option to make a separate partition for your complete un-embedded installation.

[Guy]

I struggle to find a reason not also to support a 'home=partition/directory' style boot code (and of course by extension the same for 'opt=...').

Tiny Core is about choices - letting the user set it up how they want. This would give the user more choices. I think it would be a good idea.


In the past, I have had 3 or more partitions with a different version of Tiny Core on each. This is useful for testing release candidates. I also tried experiments/modifications. If something did not work, I could always boot the previous one and fix it.

Now, I use one partition. This frees up a lot of hard drive space. I have Grub set up like this:

title   Tiny Core 3.3
root   (hd0,0)
kernel   /tinycore_3.3/bzImage quiet tce=hda1 opt=hda1 home=hda1 norestore
initrd   /tinycore_3.3/tinycore.gz

title   Tiny Core 3.3rc4
root   (hd0,0)
kernel   /tinycore_3.3rc4/bzImage quiet tce=hda1 opt=hda1 home=hda1 norestore
initrd   /tinycore_3.3rc4/tinycore.gz

title   Tiny Core 3.3rc3
root   (hd0,0)
kernel   /tinycore_3.3rc3/bzImage quiet tce=hda1 opt=hda1 home=hda1 norestore
initrd   /tinycore_3.3rc3/tinycore.gz

If there is a significant change in the tce or opt directory, the previous versions may not work properly. I could connect an additional hard drive, and use tce=hdb1 opt=hdb1. Having more options in the boot codes would eliminate the need for this.


The wiki is in need of an update.

I have not used Grub 2 yet. I am in the process of downloading some recent distros, so I can install them on the same computer as Tiny Core, and use Grub 2. When I understand it, I hope I will have time to update the wiki. The more flexible the installation options, the better.

[roberts]

Let me recap.  Lets not have home based off the root filesystem. While we are at it lets let the user decide where to move opt too . Oh, and what about persistent local. Got allow that too, in the name of "choices" to move that anywhere the user might desire. Lets throw the Linux Standard Base to the wind. The heck with KISS. It is about choices. While there how about /etc and /var and ... Lets move to a super hybrid any directory in any partition and at any location but not off the root filesystem. Gotta have those choices.

Well such machination of obfuscation is already possible. Although I have no interest to sanction such with official boot codes. One likely can deploy mount --bind to arbitrarily move, hide, deeply nest, and relocate directories. Use at your own risk. Have fun.

I think the above results in a scatter mode which is already available. Perhaps a virtual machine would give you the results that you want which is also already available.

[LaffinOne]

I had the same problem, i like to have multiple linuxes on a box.
My solution was to put the tiny/micro persistant directories under the tce directory, although right now this is all. I did this with a bit of hacking the etc/init.d scripts.

so my tce directory looks like
/tce
  /backup
  /home
  /local
  /opt
  /ondemand
  /optional

I am also thinking of also adding a customizable tce directory, so I can have various flavors of tiny/micro core running on the machine as well.
This was done with TMC 3.2, but I see 3.3 is released so may have a go at that

[maro]

Robert, First off thanks for listing all those links in reply #4. After some reading I still could not quite figure out what lead to the "design decision" to not support a 'home=partition/directory' style boot code. Nevertheless you make up for it by your later statement:

IMHO having two "home" directories and/or two "opt" on a single physical hard drive partition is "messing" up any Linux distribution. In fact I would say that it would be heresy.

I suppose that there are ways to really make a mess with having multiple 'home' directory structures. And I accept that for the "average" user (in particular to those new to Linux in general or TC in particular) this could be almost a "dangerous weapon".

OTOH it is my personal believe that the use of '/opt' in TC is not quite in line of what I've come to expect after using other distributions. I might have also spend to much time on larger Solaris production systems and have hence not expected to see system-wide setting and configuration files in '/opt' (instead of somewhere in '/etc'). So with that "baggage" I personally might go as far as to consider '/opt' to be "mis-used" by TC. But this is not the point as I had already pointed some of it out a while ago I've now come to expect that historically evolved conventions are not to be questioned, even though that arguments to consolidate, simplify and unify some code could be made.

My main point would be that TC prides itself to be a toolkit to "Build it your way". It would be my view that similar boot codes should support similar functionality. I don't read it that the intention of the OP is to throw everthing over board. So I interpret reply #6 a bit as "letting off some steam". What I'd find attractive would be something along the lines of reply #7, that is the chance to "isolate" TC in any area of a pre-existing EXT[2-4] file system. The point of using dedicated filesystems is that over the years I've always come to regret my choice of sizing. After a while something has always been either to large or to small. So not having to comit to a particular partition size but rather co-use (in a "clean-cut" way) a larger existing one is something that I'd value highly.

Most of this argument might be a matter of personal taste or opinion to which degree something "conflicts" with something else. I personally have the hope that using the 'tcvd' boot code might be a suitable alternative to "persistent home and opt embedding". I would just have to find more time to give it a serious crack ...

[Guy]

I don't think Tiny Core has to follow "Linux Tradition."

If improvements could be made by making it different, they would be improvements.

I think it would be an improvement if everything from the opt directory was put in the tce directory.

This would put all settings together, and make it simpler to set up, by eliminating the need to have persistent opt.

Can I suggest the team seriously consider this.

[gerald_clark]

You can't have opt in a persistent tce until you have a persistent tce.
Opt contains system information that needs to be vaild before and after tce is mounted, and valid if tce changes.

[Guy]

I am just thinking about all of the different situations which may be affected. I may not have thought of all of them.

The computer can find /tce/opt just as quickly and easily as finding /opt. It could have any name, for example, /tce/settings.

What about cloud mode? Would there be anyone who wants to save something in /opt but not in /tce? I think that would be extremely rare.

What about someone who wants to save something in /opt, but has not yet set up a /tce directory? There could be a note in the installation guide: "To save changes, set up a tce directory." This is simpler than setting up both /opt and /tce.

What if the /tce directory is moved? Extensions would need to be copied from the other one, or downloaded again. If copied, /opt could be copied too. If downloaded, /opt could be set up again.

Things would be different (simpler), but I think it would work.

Is there any genuine situation that I haven't thought of?


I think it would be an improvement, as it keeps things together, and makes it simpler.

[gerald_clark]

Having looked at all the files in opt again, I have to agree.
It would work no differently than having a persistent opt.

[curaga]

- tce on fat32. IIRC some files in /opt have permissions different from default.

[gerald_clark]

Good point.  
There are executable bash scripts in opt that wouldn't have an execute bit set on a windows FS.
They would have to be shelled.

.tce_dir, .backup_device etc. could be moved to /tmp/tce if necessary.  They get rewritten anyway.