Bug 1409024

Summary:	[Debian] Missing db_dump abort inspection
Product:	[Community] Virtualization Tools	Reporter:	Laurent Bigonville <bigon>
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	ptoscano
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-03-26 12:57:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Laurent Bigonville 2016-12-29 01:11:05 UTC

Description of problem:
On a debian host, if db_dump is not installed, the inspection of a centos VM (probably all rpm based distro) is failing

Version-Release number of selected component (if applicable):
1.34.3

How reproducible:
Always

Steps to Reproduce:
1. Run virt-inspector /tmp/my_vm.img
2. libguestfs: error: /usr/bin/db_dump exited with error status 1.

Actual results:
The inspection fails

Expected results:
The inspection succeed without the list installed RPM's

Additional info:
I'm also wondering that in some conditions (other endianess or different Berkeley DB versiob) that the db_dump command can simply fail. That would probably also cause the inspection to fail.

Comment 1 Richard W.M. Jones 2016-12-29 06:40:15 UTC

Probably a missing dependency of the Debian package.

Comment 2 Laurent Bigonville 2016-12-30 13:09:43 UTC

Yes the dependency is indeed missing (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849597).

But what about the other concerns?

Comment 3 Richard W.M. Jones 2016-12-31 01:56:00 UTC

(In reply to Laurent Bigonville from comment #0)
> Additional info:
> I'm also wondering that in some conditions (other endianess or different
> Berkeley DB versiob) that the db_dump command can simply fail. That would
> probably also cause the inspection to fail.

The BDB format is designed to cope with these cases.

Comment 4 Pino Toscano 2017-01-03 18:29:46 UTC

While the Debian package missed a Depends (or Recommends/Suggests), IMHO the library (and the tools) should cope better with external programs used.

The support for dumping RPM databases (for packages) is enabled only when the libdb tools are found during at configure time, so in the same way the code block could be skipped when the tool is not found at runtime: this would enable packagers to use better "weak dependencies" for all the non-mandatory features that require external tools (for example dumping of RPM databases, extraction of icon from Windows and CirrOS guests, etc).

I'll come up with a patch to do this.

Comment 5 Pino Toscano 2017-01-12 10:37:59 UTC

(In reply to Pino Toscano from comment #4)
> While the Debian package missed a Depends (or Recommends/Suggests), IMHO the
> library (and the tools) should cope better with external programs used.
> 
> The support for dumping RPM databases (for packages) is enabled only when
> the libdb tools are found during at configure time, so in the same way the
> code block could be skipped when the tool is not found at runtime: this
> would enable packagers to use better "weak dependencies" for all the
> non-mandatory features that require external tools (for example dumping of
> RPM databases, extraction of icon from Windows and CirrOS guests, etc).
> 
> I'll come up with a patch to do this.

Series for this:
https://www.redhat.com/archives/libguestfs/2017-January/msg00034.html

Comment 6 Richard W.M. Jones 2017-10-05 13:20:27 UTC

v2 of the patch series was rejected upstream:

https://www.redhat.com/archives/libguestfs/2017-February/msg00043.html

(In reply to Pino Toscano from comment #4)
> The support for dumping RPM databases (for packages) is enabled only when
> the libdb tools are found during at configure time, so in the same way the
> code block could be skipped when the tool is not found at runtime: this
> would enable packagers to use better "weak dependencies" for all the
> non-mandatory features that require external tools (for example dumping of
> RPM databases, extraction of icon from Windows and CirrOS guests, etc).

I'm not sure I agree with this premise either.  The dependency could
still be required at build time, and then become a weak dependency
at run time.

It seems we don't handle this case very well at the moment.  But a minimal
change to fix this bug would be to just (re-)check if DB_DUMP is still
available at runtime before trying to run the command.  I'll have a go
at that.

Comment 7 Richard W.M. Jones 2017-10-05 13:42:02 UTC

https://www.redhat.com/archives/libguestfs/2017-October/msg00032.html

Comment 8 Richard W.M. Jones 2017-10-06 13:52:42 UTC

My second version posted:
https://www.redhat.com/archives/libguestfs/2017-October/msg00058.html

Comment 9 Richard W.M. Jones 2018-11-02 14:28:00 UTC

I think the patch in comment 8 was forgotten about so I've reposted it:

https://www.redhat.com/archives/libguestfs/2018-November/msg00011.html

Comment 10 Pino Toscano 2018-11-02 14:45:11 UTC

(In reply to Richard W.M. Jones from comment #9)
> I think the patch in comment 8 was forgotten about so I've reposted it:
> 
> https://www.redhat.com/archives/libguestfs/2018-November/msg00011.html

It was not forgotten, simply I don't agree with this approach, and I rather prefer a proper handling of _runtime_ tools at _runtime_.  Reply sent:
https://www.redhat.com/archives/libguestfs/2018-November/msg00013.html

This is my proposal:
https://www.redhat.com/archives/libguestfs/2017-February/msg00043.html

Comment 11 Richard W.M. Jones 2021-03-26 12:57:04 UTC

libguestfs 1.45.3 will use librpm directly to access the RPM database,
and removes the requirement for db_dump, therefore closing.