Bug 1476081

Yup, this is a bug.

We have never really supported non-numeric versions for version strings of distributions.

While fixing this specific issue should be easy, the os-release file you provided shows the distribution on the guest is a new one we don't currently support.  This means that additional work would be required anyway, other than the version parsing fix.

From a quick search it seems that this is a commercial distribution -- unless there's also a free version I can try myself, the other options are either
a) who has a license of the NeoKylin OS provides patches for libguestfs
b) we can access to a guest of it, somehow

(In reply to Pino Toscano from comment #2)
> We have never really supported non-numeric versions for version strings of
> distributions.
> 
> While fixing this specific issue should be easy, the os-release file you
> provided shows the distribution on the guest is a new one we don't currently
> support.  This means that additional work would be required anyway, other
> than the version parsing fix.
> 
> From a quick search it seems that this is a commercial distribution --
> unless there's also a free version I can try myself, the other options are
> either
> a) who has a license of the NeoKylin OS provides patches for libguestfs
> b) we can access to a guest of it, somehow

Yes,you are right.
But,you can only fix the version parsing, because the format of VERSION_ID can include
0–9, a–z, ".", "_" and "-", not only X.Y format, some distributions may also use the letters. What do you think?

Of course，I can provide patches for libguestfs.

(In reply to Qingzheng zhang from comment #3)
> But,you can only fix the version parsing, because the format of VERSION_ID
> can include
> 0–9, a–z, ".", "_" and "-", not only X.Y format, some distributions may also
> use the letters. What do you think?

Since we represent the version of a guest with two numbers (for major and minor version numbers), fixing the parsing of the version strings actually means to add a proper pattern matching for the specific distribution.  This is because we support already formats like "X" and "X.Y" (and "X.Y.Z" and variants, but just because we ignore all the numbers after the second, so any other version string requires custom handling.

(In reply to Pino Toscano from comment #4)
> (In reply to Qingzheng zhang from comment #3)
> > But,you can only fix the version parsing, because the format of VERSION_ID
> > can include
> > 0–9, a–z, ".", "_" and "-", not only X.Y format, some distributions may also
> > use the letters. What do you think?
> 
> Since we represent the version of a guest with two numbers (for major and
> minor version numbers), fixing the parsing of the version strings actually
> means to add a proper pattern matching for the specific distribution.  This
> is because we support already formats like "X" and "X.Y" (and "X.Y.Z" and
> variants, but just because we ignore all the numbers after the second, so
> any other version string requires custom handling.

 "V7Update2" can be parse to  major=7 and minor=2, yes ,it is "abcXabcY" format.

The one line reproducer for this is:

$ virt-builder fedora-26 --edit '/etc/os-release: s/VERSION_ID=26/VERSION_ID="V7Update2"/' && virt-inspector -a fedora-26.img 
[...]
libguestfs: error: could not parse integer in version number: V7Update2
virt-inspector: no operating system could be detected inside this disk image.

The new inspection code doesn't fail here.

It parses the version as "7.0" which is a reasonable best effort.

Because NeoKylin is a real Linux distro we should probably add a
special case here.  Still be nice if NeoKylin could use a normal
version number though ..

(In reply to Richard W.M. Jones from comment #7)
> The new inspection code doesn't fail here.
> 
> It parses the version as "7.0" which is a reasonable best effort.
> 
> Because NeoKylin is a real Linux distro we should probably add a
> special case here.  Still be nice if NeoKylin could use a normal
> version number though ..

ok, thank you very much for solving this problem.

New inspection code is upstream, and it parses the version as:

    <major_version>7</major_version>
    <minor_version>0</minor_version>

Since NeoKylin is not available, I don't think we can do much
better here.  However if there are downloads of NeoKylin that I've
missed, or if you can provide copies of /etc/os-release from this
operating system, then you can reopen the bug and we'll try to
improve parsing.

Fixed in libguestfs >= 1.37.26 & >= 1.38.

Created attachment 1337488 [details]
The cope of /etc/os-release from NeoKylin  operating system.

This is the cope of /etc/os-release from NeoKylin  operating system. 
Thank you for improving parsing.

Thanks.  I reproduced this bug using:

$ virt-builder fedora-26 \
    --delete /etc/os-release \
    --delete /etc/lsb-release \
    --delete /etc/redhat-release \
    --upload /var/tmp/os-release:/etc/os-release

(where /var/tmp/os-release is the attachment from comment 10
downloaded to /var/tmp locally).

Then inspection shows:

$ virt-inspector fedora-26.img  --no-icon --no-applications
<?xml version="1.0"?>
<operatingsystems>
  <operatingsystem>
    <root>/dev/sda3</root>
    <name>linux</name>
    <arch>x86_64</arch>
    <product_name>NeoKylin Linux Advanced Server V7Update2 (Potassium)</product_name>
    <major_version>7</major_version>
    <minor_version>0</minor_version>
...

which is the not-quite-correct output.  I'll see if I can come up
with a quick patch for this.

Patch posted for testing:

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

After applying this patch the output is:

<?xml version="1.0"?>
<operatingsystems>
  <operatingsystem>
    <root>/dev/sda3</root>
    <name>linux</name>
    <arch>x86_64</arch>
    <distro>neokylin</distro>
    <product_name>NeoKylin Linux Advanced Server V7Update2 (Potassium)</product_name>
    <major_version>7</major_version>
    <minor_version>2</minor_version>
    <package_format>rpm</package_format>
    <package_management>dnf</package_management>

Please note I did not test this on a real NeoKylin image, and
I had to guess that the package format/manager is rpm/dnf.

Upstream in commit cd08039d2427b584237265237c713d8cf46536a0
and libguestfs >= 1.38.