Description of problem: 1.inspect-os report error: could not parse integer in version number: V7Update2 2.inspect-os cannot parse the os-release of neokylin OS which the VERSION_ID is "V7Update2" os-release show follows: ><fs> cat /etc/os-release NAME="NeoKylin Linux Advanced Server" VERSION="V7Update2 (Potassium)" ID="neokylin" ID_LIKE="fedora" VERSION_ID="V7Update2" PRETTY_NAME="NeoKylin Linux Advanced Server V7Update2 (Potassium)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:neokylin:enterprise_linux:V7Update2:GA:server" HOME_URL="https://www.cs2c.com.cn/" BUG_REPORT_URL="https://bugzilla.cs2c.com.cn/" NEOKYLIN_BUGZILLA_PRODUCT="NeoKylin Linux Advanced Server 7" NEOKYLIN_BUGZILLA_PRODUCT_VERSION=V7Update2 NEOKYLIN_SUPPORT_PRODUCT="NeoKylin Linux Advanced Server" NEOKYLIN_SUPPORT_PRODUCT_VERSION="V7Update2" Version-Release number of selected component (if applicable): root@cvk24:~# guestfish --version guestfish 1.36.3 How reproducible: Steps to Reproduce: 1. use fedora OS; 2. modify VERSION_ID of os-release to VERSION_ID="V7Update2" 3. run guestfish -a /path/to/mb-neokylin7.22-64 -i Actual results: failed and report : root@cvk24:~# guestfish -a /vms/images/mb-neokylin7.22-64 -i libguestfs: error: could not parse integer in version number: V7Update2 Expected results: Additional info: https://www.freedesktop.org/software/systemd/man/os-release.html shows: VERSION_ID= A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, ".", "_" and "-") identifying the operating system version, excluding any OS name information or release code name, and suitable for processing by scripts or usage in generated filenames. This field is optional. Example: "VERSION_ID=17" or "VERSION_ID=11.04". But, guestfs_int_version_from_x_y_or_x() cannot parse the VERSION_ID="V7Update2" format.
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.