What were you trying to do that didn't work?
Upgrading RHDE systems, rpm-ostree based, with MicroShift workloads running on it. 
After upgrade of OStree, even for updates that doesn't touch MicroShift layers, some Containers, pulled from external registry, are in 'CreateContainerError' state. To recover it, it is needed to manually remove all the references from. 

It looks like that the rpm-ostree upgrades are touching some content with /var, which is not expected as per `/var` is RW and planned for data persistence according to RHEL manuals https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/introducing-rhel-for-edge-images_composing-installing-managing-rhel-for-edge-images#edge-difference-between-rhel-rpm-images-and-rhel-for-edge-images_introducing-rhel-for-edge-images. 

What is the impact of this issue to you?
It blocks connect-on demand deployments and adds manual overhead for self-maintained deployments.   

Please provide the package NVR for which the bug is seen:
On RHEL 9.4, osbuild-composer-core-101-1.el9.x86_64
On RHEL 9.2, osbuild-composer-core-76-2.el9_2.2.x86_64

How reproducible is this bug?:
Always for specific application containers. 

Steps to reproduce

1. create ostree-commit with microshift
2. create edge-installer and deploy new systems 
3. As day2 operation, deploy applications from external registries
4. Define HTTP Ostree Repo or local media 
5. Create new ostree-commit with updated packages (with or without updating microshift)
6. Extend existing  HTTP Ostree Repo or local media with additional ostree commit through pull-local
7. Upgrade the running system, with app workload.  

Expected results
rpm-ostree upgrades ** performed without additional manual steps to workaround image issues. 

Actual results
Additional manual steps to workaround image issues, impacting operational KPIs for far-edge/edge deployments.