Red Hat Bugzilla – Bug 1388407
virt-sysprep will fail detecting OS if "/usr" is a distinct partition mounted in "/" via fstab
Last modified: 2017-03-21 04:56:21 EDT
Created attachment 1213796 [details] virt-sysprep -a -v output for the failed case. Description of problem: This is a bug for RHEL6, which has the same issue with BZ 1318440. Version-Release number of selected component (if applicable): libguestfs-1.20.11-17.el6.x86_64 How reproducible: 1. Install a RHEL7 VM guest, in RHEL6 kvm host. 2. During installation, set `/usr` as a separated partition/LV. 3. Perform `virt-sysprep` in rhel6. Actual results: ~~~ # virt-sysprep -a /home/vm/feichashao_RHEL72_ks_sysprep.qcow2 Examining the guest ... virt-sysprep: no operating systems were found in the guest image ~~~ Expected results: ~~~ # virt-sysprep -a /home/vm/feichashao_RHEL72_ks_sysprep_nousr-corrupt.qcow2 Examining the guest ... Performing "yum-uuid" ... Performing "utmp" ... Performing "udev-persistent-net" ... Performing "tmp-files" ... Performing "sssd-db-log" ... Performing "ssh-userdir" ... ........... ~~~ Additional info: 1. Attached debug log of `virt-sysprep -a xxx -v` for the failed case. 2. Customer need to create/run RHEL7 guests on RHEL6 hosts, so customer need this tool to make templates.
Fixed in RHEL 7.3 (bug 1318440) You can get the preview packages from https://people.redhat.com/~rjones/libguestfs-RHEL-7.3-preview/ or wait a few days for the official release. For RHEL 6 (this bug) the patch seems backport-able. I'll see what Pino thinks because he is RHEL 6 maintainer.
(In reply to Richard W.M. Jones from comment #1) > For RHEL 6 (this bug) the patch seems backport-able. I'll see > what Pino thinks because he is RHEL 6 maintainer. Yes, the patch for the inspection API is easy enough.
Verified with packages: libguestfs-1.20.11-20.el6.x86_64 Verify steps: 1. On RHEL6 host ,install a RHEL7 VM guest(set `/usr` as a separated partition/LV during installation): RHEL7.2-usr.img 2. # virt-sysprep -a RHEL7.2-usr.img Examining the guest ... Performing "yum-uuid" ... Performing "utmp" ... Performing "udev-persistent-net" ... Performing "tmp-files" ... Performing "sssd-db-log" ... Performing "ssh-userdir" ... Performing "ssh-hostkeys" ... Performing "smolt-uuid" ... Performing "script" ... Performing "samba-db-log" ... Performing "rpm-db" ... Performing "rhn-systemid" ... Performing "random-seed" ... Performing "puppet-data-log" ... Performing "password" ... Performing "pam-data" ... Performing "package-manager-cache" ... Performing "pacct-log" ... Performing "net-hwaddr" ... Performing "net-hostname" ... Performing "mail-spool" ... Performing "machine-id" ... Performing "logfiles" ... Performing "hostname" ... Performing "firstboot" ... Performing "dovecot-data" ... Performing "dhcp-server-state" ... Performing "dhcp-client-state" ... Performing "delete" ... Performing "cron-spool" ... Performing "crash-data" ... Performing "blkid-tab" ... Performing "bash-history" ... Performing "abrt-data" ... Performing "lvm-uuids" ... So verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2017-0564.html