Red Hat Bugzilla – Bug 1318440
virt-sysprep will fail detecting OS if "/usr" is a distinct partition mounted in "/" via fstab
Last modified: 2016-11-04 08:30:46 EDT
Description of problem: virt-sysprep will fail detecting OS if "/usr" is a distinct partition mounted in "/" via fstab Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. Create a VM with "/var", "/", "/usr", "/home" partitions 2. Try to virt-sysprept it 3. Actual results: Fails with "cannot detect operating system" Expected results: Should detect the OS Additional info: I can reproduce this issue to.
I'd agree with a suggestion from David that an option like "--force-os=linux" or something similar would be an acceptable workaround, if the problem is only with detecting the operating system.
This has been reported already as upstream bug #1186935.
(In reply to Vagner Farias from comment #2) > I'd agree with a suggestion from David that an option like > "--force-os=linux" or something similar would be an acceptable workaround, > if the problem is only with detecting the operating system. This won't work, as the inspection done by libguestfs does more than just detecting the OS: for example, it detects all the different partitions in the disk image, and how they are eventually mounted for each guest.
Verified with the packages: libguestfs-1.32.5-10.el7.x86_64 Verify steps: 1. Prepare a RHEL7 guest image with separate partition for "/var", "/", "/usr", "/home": # guestfish -a rhel7.2-distinct_partition_for_usr.qcow2 -i sh "df -h" Filesystem Size Used Avail Use% Mounted on /dev/mapper/rhel-root 4.9G 54M 4.9G 2% / /dev/mapper/rhel-usr 2.0G 817M 1.2G 42% /usr /dev/mapper/rhel-var 1014M 65M 950M 7% /var /dev/sda1 473M 123M 350M 27% /boot /dev/mapper/rhel-home 1014M 33M 982M 4% /home /dev 237M 0 237M 0% /dev 2. # virt-sysprep -a rhel7.2-distinct_partition_for_usr.qcow2 [ 0.0] Examining the guest ... [ 3.3] Performing "abrt-data" ... [ 3.3] Performing "bash-history" ... [ 3.3] Performing "blkid-tab" ... [ 3.4] Performing "crash-data" ... [ 3.4] Performing "cron-spool" ... [ 3.4] Performing "dhcp-client-state" ... [ 3.4] Performing "dhcp-server-state" ... [ 3.4] Performing "dovecot-data" ... [ 3.4] Performing "logfiles" ... [ 3.4] Performing "machine-id" ... [ 3.4] Performing "mail-spool" ... [ 3.4] Performing "net-hostname" ... [ 3.4] Performing "net-hwaddr" ... [ 3.4] Performing "pacct-log" ... [ 3.4] Performing "package-manager-cache" ... [ 3.4] Performing "pam-data" ... [ 3.4] Performing "puppet-data-log" ... [ 3.4] Performing "rh-subscription-manager" ... [ 3.4] Performing "rhn-systemid" ... [ 3.4] Performing "rpm-db" ... [ 3.4] Performing "samba-db-log" ... [ 3.4] Performing "script" ... [ 3.4] Performing "smolt-uuid" ... [ 3.4] Performing "ssh-hostkeys" ... [ 3.4] Performing "ssh-userdir" ... [ 3.4] Performing "sssd-db-log" ... [ 3.4] Performing "tmp-files" ... [ 3.4] Performing "udev-persistent-net" ... [ 3.4] Performing "utmp" ... [ 3.4] Performing "yum-uuid" ... [ 3.4] Performing "customize" ... [ 3.4] Setting a random seed [ 4.5] Performing "lvm-uuids" ... The command finished successfully. 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-2016-2576.html
*** Bug 1391789 has been marked as a duplicate of this bug. ***