From: "Vyacheslav Yurkov" <uvv.mail@gmail.com>
To: Openembedded-core@lists.openembedded.org
Cc: Vyacheslav Yurkov <uvv.mail@gmail.com>
Subject: [PATCH v2 8/8] docs: add overlayfs class
Date: Fri, 9 Jul 2021 13:31:46 +0200 [thread overview]
Message-ID: <20210709113146.69020-8-uvv.mail@gmail.com> (raw)
In-Reply-To: <20210709113146.69020-1-uvv.mail@gmail.com>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
---
documentation/ref-manual/classes.rst | 46 ++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 09878c480f..6d80e7dc4f 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -1708,6 +1708,52 @@ one such example. However, being aware of this class can reduce the
proliferation of different versions of similar classes across multiple
layers.
+.. _ref-classes-overlayfs:
+
+``overlayfs.bbclass``
+=======================
+
+
+It's often desired in Embedded System design to have a read-only rootfs.
+But a lot of different applications might want to have a read-write access to
+some parts of a filesystem. It can be especially useful when your update mechanism
+overwrites the whole rootfs, but you want your application data to be preserved
+between updates. The ``overlayfs`` class provides a way to achieve that by means
+of overlayfs and at the same time keeping the base rootfs read-only.
+
+To use this class, set a mount point for a partition overlayfs is going to use as upper
+layer in your machine configuration. Underlying file system can be anything that
+is supported by overlayfs. This has to be done in your machine configuration::
+
+ OVERLAYFS_MOUNT_POINT[data] = "/data"
+
+.. note::
+
+ QA check fails to catch file existence if you redefine this variable in your recipe!
+
+The class assumes you have a data.mount systemd unit defined elsewhere in your BSP
+(e.g. in systemd-machine-units recipe) and it's installed to the image.
+
+Then you can specify writable directories on a recipe basis::
+
+ OVERLAYFS_WRITABLE_PATHS[data] = "/usr/share/my-custom-application"
+
+To support several mount points you can use a different variable flag. Assume we
+want to have a writable location on the file system, but not interested where the data
+survive a reboot. Then we could have a mnt-overlay.mount unit for a tmpfs file system.
+
+In your machine configuration::
+
+ OVERLAYFS_MOUNT_POINT[mnt-overlay] = "/mnt/overlay"
+
+and then in your recipe::
+
+ OVERLAYFS_WRITABLE_PATHS[mnt-overlay] = "/usr/share/another-application"
+
+.. note::
+
+ The class does not support /etc directory itself, because systemd depends on it
+
.. _ref-classes-own-mirrors:
``own-mirrors.bbclass``
--
2.28.0
prev parent reply other threads:[~2021-07-09 11:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-09 11:31 [PATCH v2 1/8] overlayfs-qa: common functions for overlayfs Vyacheslav Yurkov
2021-07-09 11:31 ` [PATCH v2 2/8] overlayfs.bbclass: generate overlayfs mount units Vyacheslav Yurkov
2021-07-09 11:31 ` [PATCH v2 3/8] maintainers.inc: overlayfs bbclass maintainer Vyacheslav Yurkov
2021-07-09 11:31 ` [PATCH v2 4/8] rootfs-postcommands: add QA check for overlayfs Vyacheslav Yurkov
2021-07-09 11:31 ` [PATCH v2 5/8] systemd-machine-units: add bbappend for meta-selftest Vyacheslav Yurkov
2021-07-09 11:31 ` [PATCH v2 6/8] overlayfs: meta-selftest recipe Vyacheslav Yurkov
2021-07-09 11:31 ` [PATCH v2 7/8] oeqa/selftest: overlayfs unit tests Vyacheslav Yurkov
2021-07-10 9:01 ` [OE-core] " Alexander Kanavin
2021-07-10 9:41 ` Alexandre Belloni
2021-07-10 12:47 ` Vyacheslav Yurkov
2021-07-10 17:15 ` Alexandre Belloni
2021-07-11 15:16 ` Vyacheslav Yurkov
2021-07-12 9:14 ` Alexandre Belloni
2021-07-12 9:42 ` Vyacheslav Yurkov
2021-07-09 11:31 ` Vyacheslav Yurkov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210709113146.69020-8-uvv.mail@gmail.com \
--to=uvv.mail@gmail.com \
--cc=Openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox