LIVE-BOOT(5) | Live Systems Project | LIVE-BOOT(5) |
persistence.conf - Configuration file for persistence media in live-boot
If live-boot probes a persistence volume with the label (or GPT name, or file name, but from now on we will just say "label") "persistence", that volume's persistence is fully customizable through the persistence.conf file stored on the root of its file system. Any such labeled volume must have such a file, or it will be ignored.
The format of persistence.conf allows empty lines and lines starting with a "#" (used for comments), both which will be ignored. A so called "custom mount" has the format:
which roughly translates to "make DIR persistence in the way described by the list of OPTIONs".
For each custom mount DIR must be an absolute path that cannot contain white spaces or the special . and .. path components, and cannot be /live (or any of its sub-directories). Once activated all changes (file deletion, creation and modification) to DIR on the live file system are stored persistently into a path equivalent to DIR on the persistence media, called the source directory. The default way to achieve persistence is to simply bind-mount the corresponding source directory to DIR, but this can be changed through the use of OPTIONs.
All custom mounts will be done in an order so that no two custom mounts can "hide" each other. For instance, if we have the two DIR:s /a and /a/b it would always be the case that /a is mounted first, then /a/b. This remains true no matter how the lines in persistence.conf are ordered, or if several persistence.conf files on different persistence media are used at the same time. However, it is forbidden for custom mounts to have their source directory inside the source directory of another custom mount, so the source directories that are auto-created by live-boot does not support "nested" mounts like /a and /a/b on the same media. In this case you must use the source option (see below) to make sure that they are stored in different source directories.
When a source directory doesn't exist on the persistence media for a certain custom mount, it will be created automatically, and permissions and ownership will be optimistically set according to DIR. It will also be bootstrapped by copying the contents of the DIR into its source directory on the persistence media. The bootstrapping will not happen when the link or union options are used (see below).
Custom mounts defined in persistence.conf accept the following options in a comma-separated list:
The following options are mutually exclusive (only the last given one will be in effect):
Let's say we have a persistence volume VOL with the a persistence.conf file containing the following four lines (numbered for ease of reference):
The corresponding source directories are:
It was necessary to set the source options for 1 and 2, since they otherwise would become nested with 3's source, which is invalid.
Line 3 will be taken care of before line 1 and 2 in order to prevent custom mounts 1 and 2 from being hidden by 3. When line 3 is handled, VOL/home is simply bind-mounted on /home. To illustrate what happens for lines 1 and 2, let's say that the following files exist:
Then the following links and directories will be created:
One could argue, though, that lines 1 and 2 in the example persistence.conf file above are unnecessary since line 3 already would make all of /home persistent. The link option is intended for situations where you don't want a complete directory to be persistent, only certain files in it or its sub-directories.
Line 4 can be mounted at any time since its DIR (and source directory) is completely disjoint from all the other custom mounts. When mounted, VOL/usr will be the rw branch due to the union option, and will only contain the difference compared to the underlying read-only file system. Hence packages could be installed into /usr with great space-wise efficiency compared to bind-mounts, since in the latter case all of /usr would have to be copied into VOL/usr during the initial bootstrap.
More information about live-boot and the Live Systems project can be found on the homepage at <https://wiki.debian.org/DebianLive> and in the manual at <https://live-team.pages.debian.net/live-manual/>.
Bugs can be reported by submitting a bugreport for the live-boot package in the Bug Tracking System at <http://bugs.debian.org/> or by writing a mail to the Live Systems mailing list at <debian-live@lists.debian.org>.
live-boot was written by Daniel Baumann <mail@daniel-baumann.ch>.
2015-09-22 | 5.0~a5-1 |