Yes, this use case makes sense. Then the reliable way is to cleanup
upperdir of overlayfs during image upgrade and make postinsts scripts
re-entrant.
On Tue, Mar 23, 2021, 07:56 Mike Looijmans wrote:
> So it's something exclusively for OpenBMC.
>
> As for running the scripts, you cannot simply
So it's something exclusively for OpenBMC.
As for running the scripts, you cannot simply conclude that a script
doesn't need to run if its contents did not change. It may very well
call the executable from its package to do the actual work and that may
have changed as well.
Met
Hi, Mike.
That is how OpenBMC is designed. Most of the targets are read-only rootfs
(squashfs) and overlayfs for RW.
It is not expected to overwrite binaries through overlayfs and there are
plans to scope RW areas (e.g. /etc).
Those files with 64-chars suffix are mostly hidden from regular
Two remarks below...
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl
Please consider the environment before printing
On Mon, 2021-03-22 at 16:45 +0100, Anton Kachalov via lists.openembedded.org
wrote:
> From: "Anton D. Kachalov"
>
> When running on read-only rootfs backed with overlayfs, the processed scripts
> are being marked as deleted on upperdir of overlayfs. When it comes to
> upgrade the main read-only
From: "Anton D. Kachalov"
When running on read-only rootfs backed with overlayfs, the processed scripts
are being marked as deleted on upperdir of overlayfs. When it comes to
upgrade the main read-only image, it might contain new postinst scripts that
are different from the already processed.
