This template is only 30% used.
As was suggested, I cloned the template to see what happened. There were
no apparent errors when cloning.
- Before testing the template clone with an appvm I did a "dnf update"
in each template (orig & clone). The clone got 135 updates, and the
original said it was already up to date. Clearly cloning is not an exact
copy mechanism.
- To check why the difference in the updates, an 'rpm -qa' verified that
they are both now on the exact same version #'s of the updated packages
that I checked, so the original template was not lying to me that it was
"up to date". How the copy could be out of date is then quite puzzling.
- As for the /opt directory found in each, the clone has the invalid
subdirectories in /opt, and the original template has the correct set of
directories. So cloning works just the same as OS provisioning in that
it collects the wrong data, and copies that.
- As for the planned appvm test, when using the cloned template, it
obviously saw the wrong /opt directories which were in the cloned template.
My plan to move myself forward is to update the new clone with the right
software packages and swap that template into sys-net, removing the bad
template.
But, understanding how this kind of corruption happened could be
important. Something is obviously broken with this original template, so
I went to look for any sign of cross-linked inodes in the image files or
directory structures, only to find that Qubes 4.0 totally changed the
way that VM image files are stored and handled. Wow, I don't even know
where to begin. An fsck in dom0 says everything is fine there. I have no
clue as to what constitutes an appvm filesystem image in the new design.
Steve