This is another one of those threads about something that is impacting on variations in usage of USB and other types of live booting.
As I understand things presently, and I may be wrong of course as I am just basing this on what I think I have observed, the folowing applies:-
when using the changes_dev=
boot code, the destination partition, with an ext
filesystem, is given in some form that is usable. That form may be /dev/sdx,y
. On recognising this boot code the booting system will create, if it does not already exist, a changes
directory on the specified partition, within which will be stored the various system folders which hold changes made during the session.
If the changes directory already exists, then the contents are written into the booting system and are thus present when booted.
boot code is somewhat similar. This boot code accepts the path to a specially prepared file. The file must contain an ext
filesystem, and is loop mounted in the booting system, for reading previously made changes and writing new changes to the system directories which it will contain.
Unfortunately, unlike a changes directory, a changes file size must be predetermined when creating it, so it always takes up the same space whether used or not. Not very efficient. Nonetheless it has one attractive feature for some ..... it can be stored on most filesystems and is not limited to ext
like the changes directory, because of course the ext filesystem is contained within the file.
So most usage situations are covered, even if it is a bit awkward to implement sometimes.
The most awkward situation, in my view, is where the user wants to save all changes from maybe booting different versions of PCLOS ( or other distro Boo! ) on one single partition, to keep all such changes in one location for convenience.
I expect this to become a more common situation in the future, as USB flash sticks become more used and the utilities for their use as boot devices for different distros becomes more common.
I have been up against this problem for quite some time.
I have not found an easy solution.
Most of the time I resort to putting the changes directory for different versions on different ext partitions, which keeps them separated. I have tried using the changes_file=
boot code but found it less than satisfactory for my use.
While up against this problem again today I began to wonder ...... and such musings brings me to the following .....
Is there any real reason why two separate boot codes are needed for this purpose?
Would it not be more convenient, more flexible, and ultimately more useful, if there was just the one such boot code?
I have in mind a boot code of changes=
which can be followed by a path, and if requird a file name.
So to replace a boot code like thischanges_dev=LABEL=LivePCLOS
which will create (or use if it exists) a changes
directory on the specified partition
we would writechanges=LABEL=LivePCLOS/changes
In other words we would write the complete path to the directory where the changes are to be stored.
If we were using the changes_file=
boot code this might be what happens ....changes_file=LABEL=LivePCLOS/<file name>
which would be changed tochanges=LABEL=LivePCLOS/changes/<file name>
It should be a simple matter to determine if the path given contains a file name at the end or not, and thus determine whether such a file would be loop mounted or a directory would be used, as done presently with two different boot codes.
Of course such a scheme would also give the user much more flexibility about the naming of the directory into which the changes would be saved.
That would allow changes for multiple distros/versions to reside without interfering with each other, on a single partition.
So the user might have the following changes directories on their specified partition ...
etc etc ... or any other scheme of locating their changes they decide.
I have not gone so far as to investigate where (in what file) these boot codes are determined.
I suspect it should not be a big problem to edit the code to eliminate one of the boot codes, as described, and allow the user to determine the location of the saved changes.
Presently it seems that the saved changes are hard coded to the changes directory on the specified partition.
What I propose would overcome that limitation and allow the user to determine what such a directory is named.
That alone would allow multiple changes to be saved on a single partition using the path to a specified directory.
If using a non-ext filesystem there would be very little change ..... the path to the file and file name would be specified.
Your challenge, should you decide to accept it, is to discuss the above and comment on why it is a good or bad idea .... or maybe impossible to implement for some reason I have not considered.
This thread should not, I hope, self-destruct!
Over to you