Hi,
I have some Ansible code that inspects qcow images to verify the distro and version via shell --> virt-inspector...and then set facts for use later on in the code. However, upon downloading Fedora-Cloud-Base-33-1.2.x86_64.qcow2 image and executing my playbooks, Ansible errored out.
To see what was going on, I received the following when I manually executed "virt-inspector -a" against the image to inspect: # virt-inspector -a Fedora-Cloud-Base-33-1.2.x86_64.qcow2 libguestfs: error: filesize: /var/lib/rpm/Name: No such file or directory
Using the guestfs-browser, I noticed that the /var/lib/rpm directory for the F33 Cloud image was essentially empty, whereas on previous Fedora Cloud image releases I inspected ( 32-1.6, 31-1.9, 30-1.2 ), all had /var/lib/rpm directories that were populated (ie, Name was present). Is this a packaging "miss" for the F33 Cloud OpenStack QCOW image? Or a "feature" new to Fedora 33...and if so, should I adjust my automation to move to a more distro agnostic method, like probing and parsing /etc/os-release within images?
On 10/29/20 6:45 PM, Mike Savage wrote:
Hi,
Hi Mike,
I have some Ansible code that inspects qcow images to verify the distro and version via shell --> virt-inspector...and then set facts for use later on in the code. However, upon downloading Fedora-Cloud-Base-33-1.2.x86_64.qcow2 image and executing my playbooks, Ansible errored out.
To see what was going on, I received the following when I manually executed "virt-inspector -a" against the image to inspect: # virt-inspector -a Fedora-Cloud-Base-33-1.2.x86_64.qcow2 libguestfs: error: filesize: /var/lib/rpm/Name: No such file or directory
Using the guestfs-browser, I noticed that the /var/lib/rpm directory for the F33 Cloud image was essentially empty, whereas on previous Fedora Cloud image releases I inspected ( 32-1.6, 31-1.9, 30-1.2 ), all had /var/lib/rpm directories that were populated (ie, Name was present). Is this a packaging "miss" for the F33 Cloud OpenStack QCOW image? Or a "feature" new to Fedora 33...and if so, should I adjust my automation to move to a more distro agnostic method, like probing and parsing /etc/os-release within images?
I did some overhaul of the cloud kickstarts in the following PR: https://pagure.io/fedora-kickstarts/pull-request/679#
but I don't really think there is anything in there that stands out. This is probably related to the switch of the rpm database in F33 to sqlite: https://www.fedoraproject.org/wiki/Changes/Sqlite_Rpmdb
Dusty
This is probably related to the switch of the rpm database in F33 to sqlite: https://www.fedoraproject.org/wiki/Changes/Sqlite_Rpmdb
Dusty
Well, there you have it. Looks like virt-inspector needs to be updated to handle F33. In the meantime, I'll pivot to parsing /etc/os-release.
Thanks for the reply, Dusty...greatly appreciated.
Mike
-
Dusty Mabe -
Mike Savage