Slava, Richard, On 8/6/21 2:06 PM, Vyacheslav Yurkov wrote: > 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. This class provides a way to achieve that > by means of overlayfs and at the same time keeping the base rootfs read-only. > > Signed-off-by: Vyacheslav Yurkov <uvv.m...@gmail.com> > --- > meta/classes/overlayfs.bbclass | 111 +++++++++++++++++++++++++++++++++ > 1 file changed, 111 insertions(+) > create mode 100644 meta/classes/overlayfs.bbclass > > diff --git a/meta/classes/overlayfs.bbclass b/meta/classes/overlayfs.bbclass > new file mode 100644 > index 0000000000..8d9b59c9bf > --- /dev/null > +++ b/meta/classes/overlayfs.bbclass > @@ -0,0 +1,111 @@ > +# Class for generation of overlayfs mount units > +# > +# 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. This class provides a way to achieve that by means > +# of overlayfs and at the same time keeping the base rootfs read-only. > +# > +# Usage example. > +# > +# 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. > +# QA check fails to catch file existence if you redefine this variable in > your recipe! > +# > +# OVERLAYFS_MOUNT_POINT[data] ?= "/data" > +# > +# The class assumes you have a data.mount systemd unit defined in your > +# systemd-machine-units recipe and installed to the image. > +# > +# Then you can specify writable directories on a recipe base > +# > +# 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: > +# > +# OVERLAYFS_MOUNT_POINT[mnt-overlay] = "/mnt/overlay" > +# OVERLAYFS_WRITABLE_PATHS[mnt-overlay] = "/usr/share/another-application" > +# > +# Note: the class does not support /etc directory itself, because systemd > depends on it
Many thanks for this new class and the corresponding documentation. Richard, I guess that's something we'll need to document in the manual, once it's merge, right? Thanks again, Michael. -- Michael Opdenacker, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154557): https://lists.openembedded.org/g/openembedded-core/message/154557 Mute This Topic: https://lists.openembedded.org/mt/84706478/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
