Replies: 4 comments 4 replies
-
Yes, correct, and you can find some information scattered about on the wiki and discussions about this. We could use some better documentation for these steps.
You'll specify the device in the XML file, and a partition name. You can use the /dev/disk sysfs paths to find the partition by name.
The main reason to overlay /etc is that systemd gets unhappy if /etc isn't writeable. You can find some threads about this here or elsewhere. You might reconsider whether you actually need the entire rootfs overlayed. In my experience it's better to let things which try to write to places in the filesystem you don't expect fail, hopefully loudly, so you can figure out why they think they need to write there and redirect to a more suitable location which either is persistent if needed or tmpfs if not necessary to persist across reboots. One way to do the overlaying is through the initrdscripts - see https://github.com/OE4T/meta-tegra/tree/master/recipes-core/initrdscripts/tegra-minimal-init - this allows you to do overlay mounts before the rest of the system starts up. I think there are some public examples of this floating around but I couldn't find any in a quick search. |
Beta Was this translation helpful? Give feedback.
-
Hello , |
Beta Was this translation helpful? Give feedback.
-
I just noticed/remembered yesterday there is a recipe for data overlay at https://github.com/OE4T/tegra-demo-distro/tree/master/layers/meta-tegrademo/recipes-demo/data-overlay-setup as well. I haven't used it myself. |
Beta Was this translation helpful? Give feedback.
-
Sorry for reopening this thread... |
Beta Was this translation helpful? Give feedback.
-
Hi,
First of all thank you for providing this layer!
So basically what i want/need is a jetson device that is using swupdate with an ab partitioning scheme. I see that there is already a flag for a redundant partitioning scheme and i also see that there is already an example in the demo distro that uses the swupdate mechanism.
Sadly i need some data (configuration data, certificates or logs) to be persistent between system updates. Therefore i want to have another partition that can be used as an upperlayer in a overlayfs. So basically i would have a readonly rootfs (a or b) as lower layer and an another partition as upper layer for the persistent configuration data .
My state of knowledge right now is as follows:
What i don't know:
Is there already something in this direction that i missed? Or is there another approach more suitable ? Any hints, documentation or help in this direction would be appreciated.
Beta Was this translation helpful? Give feedback.
All reactions