On 2/2/22 08:15, Vyacheslav Yurkov wrote:
Hi Alejandro
On 02.02.2022 07:58, Alejandro Hernandez wrote:
Hey Vyacheslav,
...I definitely tried extending the overlay-etc class but it simply
does not work for this, since the rootfs becomes inaccessible once
the system has booted, ...
Hi Alejandro
On 02.02.2022 07:58, Alejandro Hernandez wrote:
Hey Vyacheslav,
...I definitely tried extending the overlay-etc class but it simply
does not work for this, since the rootfs becomes inaccessible once the
system has booted, ...
That's what I meant. What if we added another
Hey Vyacheslav,
Yes, in this case it is different and its specifically required if we
want to overlay the entire rootfs, also like it says in the commit
message and in the comments giving credit to the overlay-etc class I
definitely tried extending the overlay-etc class but it simply does not
Hi Alejandro,
Thanks for the v2, but my questions from v1 are still left unanswered.
1. Do you really need the whole rootfs to be in overlay? Perhaps you
have another use case in mind, but the more scope overlay has, the more
migration effort you need in order to update upper layer on image
When installed, this module mounts a read-write (RW) overlay on
top of a root filesystem, which is kept read-only (RO), free
from modifications by the user, this might prove to be useful
if we want to access or restore the original unmodified rootfs.
The existing overlay-etc.bbclass does
