Bug 803643

Summary:	inspect-is-multipart return false when inspection results should be true
Product:	Red Hat Enterprise Linux 7	Reporter:	Yuyu Zhou <yuzhou>
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED WONTFIX	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	huzhan, leiwang, lkong, qwan, wshi
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-04-20 08:45:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	1113520, 1205796

Description Yuyu Zhou 2012-03-15 10:44:46 UTC

Description of problem:
As the document says: If "inspect_get_format" returns "installer" (this is an install disk), then this returns true if the disk is part of a set.
But it returns false when the disk is not the first disk of the set. And it returns true sometimes when the disk is integrity.

Version-Release number of selected component (if applicable):
libguestfs-1.16.10-1.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. download a disk that is part of set, but not the first one, for example: RHEL5.8-Server-20120202.0-x86_64-disc3-ftp.iso
2. Inspect the DVD iso as following:
# guestfish
$ add-ro RHEL5.8-Server-20120202.0-x86_64-disc3-ftp.iso
$ run
$ inspect-os
/dev/vda
$ inspect-get-format /dev/vda
installer
$ inspect-is-multipart /dev/vda
false
3. download a disk that is not part of set, for example: RHEL5.8-Server-20120202.0-x86_64-DVD.iso
4. Inspect the DVD iso as following:
# guestfish
$ add-ro RHEL5.8-Server-20120202.0-x86_64-DVD.iso
$ run
$ inspect-os
/dev/vda
$ inspect-get-format /dev/vda
installer
$ inspect-is-multipart /dev/vda
true

Actual results:
At step2
$ inspect-is-multipart /dev/vda
false
At Stpe4
$ inspect-is-multipart /dev/vda
true

Expected results:
At Step2
$ inspect-is-multipart /dev/vda
true
At Step4
$ inspect-is-multipart /dev/vda
false

Additional info:
code is wrong in libguestfs:
-  fs->is_multipart_disk = totaldiscs > 0;
+  fs->is_multipart_disk = totaldiscs > 1;

Comment 1 Richard W.M. Jones 2012-03-16 10:46:28 UTC

I've fixed the obvious bug:

-  fs->is_multipart_disk = totaldiscs > 0;
+  fs->is_multipart_disk = totaldiscs > 1;

However generally I'm going to defer all of this installer
inspection code to 6.4.  There seem to be many bugs, and
most likely upstream we will switch to using ISO metadata
detection (from libosinfo) as a more reliable way to do
this.  That is not implemented yet upstream and is too large
a change for 6.3.

Comment 3 RHEL Program Management 2012-07-10 06:19:30 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 4 RHEL Program Management 2012-07-11 00:01:44 UTC

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 7 Richard W.M. Jones 2012-11-01 11:26:04 UTC

I suspect we'll just not fix this bug, and try to fix
it properly in RHEL 7.  The proper fix (using libosinfo)
is quite invasive; essentially a rewrite of the CD inspection
code.

Comment 8 Richard W.M. Jones 2012-11-29 18:32:13 UTC

Upstream I have started to integrate libosinfo
database information:
https://github.com/libguestfs/libguestfs/commit/90e7981082a2685b235724a6dd9b737cb90fe553

However the current libosinfo database does not
contain information about whether a disk is
part of a multipart set, meaning that this bug
is not directly fixed yet.

In any case it's a RHEL 7 issue.

Comment 13 Richard W.M. Jones 2015-04-20 08:45:06 UTC

I'm closing this bug as WONTFIX because:

(a) Not reported or affecting any customers

(b) Other tools (libosinfo) give the same or better information

(c) Has been around for years without attracting enough interest to fix