make persistent storage pathnames fully configurable

[Ian Bruce]

I am working on a project which allows the installation of multiple Linux live ISO images
on a single USB flashdrive.

http://sourceforge.net/projects/multibootusb/

We would like to make use of the Ubuntu live ISO feature wherein persistent changes
to the live ISO filesystem may be saved on the same USB flashdrive, and restored across
reboots.

From inspection of the casper source code, it appears that persistent data may be stored
in two different filesystem images; one for system data, and the other for user data.

Since our project expects that several bootable distributions will coexist on the same
flashdrive, it would clearly be a bad thing if changes to one operating system affected
the others, and thus persistent system data ought NOT to be shared between them.
However, it would be quite inconvenient for users if files that they had saved while
running one distribution were not available from another, and therefore persistent
user data SHOULD be shared between the installed distributions.

Unfortunately, it appears that it is not currently possible to accomplish this outcome,
because the names of the persistent filesystem images are not configurable; they
must be "casper-rw" for the system data, and "home-rw" for the user data. The only
thing that may be configured is the directory within which these two filesystem images
reside. Thus either both filesystems, or neither, may be shared between different
distributions. It is not possible to have one shared and the other unshared.

The attached patch removes this limitation, by making the full pathnames of the two
persistent filesystem images independently configurable. It does this by introducing
two new initrd boot options: "persistent-root=" and "persistent-home=". These were
chosen in conformance with the existing boot option "persistent-path=", whose function
remains unchanged if neither of the new options is used (except that it is no longer
necessary to also specify the flag option "persistent" when it is present).

It is intended that the new options will specify the full pathnames of the persistent
filesystem images (or possibly only one of them), relative to the root directory of
some attached device, as does the "persistent-path=" option. If they are not used,
the code functions exactly as it did before, ensuring full backward compatibility with
other interacting software. There is some amount of overlap with the code for "snapshots",
which I did not entirely understand, but I took care that its function would be completely
unaffected.

I would point out that the current code contains this comment:

    # FIXME: add a custom mounts configurable system

I believe that this is exactly what I have just done.

*******

I am aware that a new version of Ubuntu will be released soon, according to the standard
schedule. Because this patch is extremely small and self-contained, yet provides a significant
improvement in functionality, as described above, I would ask that it be considered for the
upcoming release. I should say that my description of multiple (Ubuntu-based) distributions
coexisting on the same flashdrive, and sharing the same set of persistent user data, is not
hypothetical. It is already working perfectly in our development version. We cannot yet
enable (unshared) persistent system data, for reasons already discussed, but this will also
be functional as soon as this patch is accepted into released ISO images.

Thanks for your consideration.

-- Ian Bruce

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "this patch provides the requested new functionality" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Ian Bruce (ian-bruce)]

Perhaps I did not understand the full intent of the comment in the
original code, "FIXME: add a custom mounts configurable system".

It might be that what the author of that comment had in mind was
not just full configurability of the names and locations of the root
and user persistent filesystem images, but generalizing the code
to allow arbitrary filesystem mount points, and the possibility of
more than two of them.

For example, we could introduce a new boot option for persistent
filesystems:

    persist=<fs-mount>:<fs-image>[, ...]

This would allow any number of persistent overlay filesystems, and
their mount points, to be specified. The current situation, with one
root and one user overlay filesystem, would be just one possible
case, specified like this:

    persist=/:/casper-rw,/home:/home-rw

It appears that given the existing infrastructure for overlay filesystems,
this would be fairly easy to write, consisting of not much more than
the code to interpret and apply the boot option proposed above.

One obvious use for this functionality would be to have the persistent
data for different users contained in separate filesystems, to make it
possible to move them around independently of each other.

Is there any interest in pursuing this feature? If so, I would volunteer
to write code for it, although I would also want to consult with other
people who were familiar with the issues involved.

-- Ian Bruce

[Ian Bruce (ian-bruce)]

> Changed in casper (Ubuntu):
> importance: Undecided -> Wishlist

It's a bit more important than "wishlist", since I provided a patch which implements
exactly what I was asking for, and a good part of what the original author meant
by "FIXME: add a custom mounts configurable system".

I didn't just wish for it, I made it happen. You don't have a category like "patch available"
or "solved and awaiting review"?

Or is this just a polite way of saying "get lost, we don't accept external contributions"?
If so, please let me know, so I can direct my efforts elsewhere.

[Dimitri John Ledkov (xnox)]

On 25 March 2013 22:38, Ian Bruce <email address hidden> wrote:
>> Changed in casper (Ubuntu):
>> importance: Undecided -> Wishlist
>
> It's a bit more important than "wishlist", since I provided a patch which implements
> exactly what I was asking for, and a good part of what the original author meant
> by "FIXME: add a custom mounts configurable system".
>

Please read Ubuntu Bug Status and Importance pages:
https://wiki.ubuntu.com/Bugs/Importance
https://wiki.ubuntu.com/Bugs/Status

Wishlist means missing functionality.

> I didn't just wish for it, I made it happen. You don't have a category like "patch available"
> or "solved and awaiting review"?
>

Please note that the bug report is already tagged with "patch" and
Ubuntu Reviewers team is subscribed, who review incoming patches on
regular basis and move the bug report further in the workflow to get
this merged into the archive.

More information on how bug triange is organised in ubuntu is
available from Bug Squad wiki pages:
https://wiki.ubuntu.com/BugSquad

> Or is this just a polite way of saying "get lost, we don't accept external contributions"?
> If so, please let me know, so I can direct my efforts elsewhere.
>

Please respect Ubuntu Code of Conduct at all times.
http://www.ubuntu.com/project/about-ubuntu/conduct

Many people volunteer to do work on Ubuntu, and your patch
specifically is being in progress to be reviewed and merged.
Please note that ubuntu release is immenent, and we are past Feature
Freeze. And although your patch may be merged before Raring release,
it will likely be uploaded into the archive (and land in the daily iso
image builds) early in S-series cycle.

Regards,

Dmitrijs.

[Ian Bruce (ian-bruce)]

FYI:

    $ dict 'wish list'
    3 definitions found

    From WordNet (r) 3.0 (2006) [wn]:

    wish list
      n 1: a list of events that you wish would occur

    From The Jargon File (version 4.4.7, 29 Dec 2003) [jargon]:

    wish list
    n.

      A list of desired features or bug fixes that probably won't get done for a
      long time, usually because the person responsible for the code is too busy
      or can't think of a clean way to do it. ?OK, I'll add automatic filename
      completion to the wish list for the new interface.? Compare {tick-list
      features}.

    From The Free On-line Dictionary of Computing (26 July 2010) [foldoc]:

    wish list
    want list

     <jargon> A list of desired {features} or {bug fixes} that
     probably won't get done for a long time, usually because the
     person responsible for the code is too busy or can't think of
     a clean way to do it. "OK, I'll add automatic filename
     completion to the wish list for the new interface."

     Compare {tick-list features}.

     [Does anybody call this a "want list"?]

When I go to the trouble of writing up a very detailed bug report,
with a complete explanation of the source of the problem, a proposed
solution, a use case which explains why it matters, and most importantly,
a patch which completely resolves the issue, and this is immediately
categorized as "wishlist", with no further comment, then I'm not sure
how to interpret that, except as an insult.

[Zack behragam (clarkmajidi)]

Yeh if this could be fix asp that would really help!
thanks

[Sundar (sundar-ima)]

This new bug/feature was filed with patch to fix on 24/03/13. But the status is still new and not even assigned? It is really disappointing since it offer excellent feature required by many and it is not hard to include/test.

[Ian Bruce (ian-bruce)]

It seems that substring replacement is not supported in Bourne shell:

    y=${x//aaa/bbb}

-- does not work, and therefore the patch which was provided above
is invalid. See below for a new patch which uses the standard utility
program "tr" to accomplish this purpose.

After rebuilding a patched initrd, these changes have been tested
with the following distributions:

bodhi-2.3.0
linuxmint-14.1-mate-dvd
linuxmint-14.1-cinnamon-dvd
ubuntu-12.10-desktop
kubuntu-12.10-desktop
xubuntu-12.10-desktop

All six ISOs were installed on a single USB flashdrive, and could be
rebooted with shared persistent user data, and unshared persistent
system data, as described above. Further testing is required, but
currently this patch seems to be a complete solution to the problem.

-- Ian Bruce

[Adam Baxter (voltagex)]

This patch would be great for more complex liveUSB setups. Maybe it could be applied for Saucy?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.