Created attachment 1469732 [details] libguestfs-test-tool and guestfish trace and debug $ guestfish --version guestfish 1.34.6 How reproducible: 100% Steps to Reproduce: $ guestfish --rw -a d.vmdk -m/dev/sda1:/ -i copy-in appwall-config.tgz /appwall_7.6.2.0_b195/master/appwall/ Actual results: fails. and no file is copy-in the image. Expected results: the file should be copy-in. with $ export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 I can notice: ... libguestfs: trace: is_whole_device = 0 libguestfs: trace: mount_ro "/dev/sda1" "/" guestfsd: main_loop: proc 395 (is_whole_device) took 0.00 seconds guestfsd: main_loop: new request, len 0x40 commandrvf: stdout=n stderr=y flags=0x0 commandrvf: mount -o ro /dev/sda1 /sysroot/ [ 11.558704] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) libguestfs: trace: mount_ro = 0 libguestfs: trace: part_to_dev "/dev/sda1" ... which suggests that '--rw' as mount option failed. also using '-m/dev/sda1:/:rw' does not help. Additional info: My installation is just-installed debian 9.5 latest (as of July 22 2018, installed as vmware at ESX 6.0 ). $ uname -a Linux itzik-deb95 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) x86_64 GNU/Linux the only package to install was: $ apt-get update # apt-get upgrade $ apt-get install libguestfs-tool
I tried on ubuntu 18.04 also without success. same results.
(In reply to Itzik Yarhi from comment #0) > Steps to Reproduce: > > $ guestfish --rw -a d.vmdk -m/dev/sda1:/ -i copy-in appwall-config.tgz > /appwall_7.6.2.0_b195/master/appwall/ > > Actual results: > > fails. and no file is copy-in the image. The actual issue is at the end: ----- guestfish: no operating system was found on this disk If using guestfish '-i' option, remove this option and instead use the commands 'run' followed by 'list-filesystems'. You can then mount filesystems you want by hand using the 'mount' or 'mount-ro' command. If using guestmount '-i', remove this option and choose the filesystem(s) you want to see by manually adding '-m' option(s). Use 'virt-filesystems' to see what filesystems are available. If using other virt tools, this disk image won't work with these tools. Use the guestfish equivalent commands (see the virt tool manual page). ----- Indeed, looking at the log there is no actual partition that can be detected as root, and thus no OS is found in the image. The content detected in the image is: - /dev/sda1, ext4, apparently a /boot partition (there is a /grub/menu.lst in it) - /dev/sda2, swap If that is the expected layout of the disk, then you can mount the partition using e.g. -m /dev/sda1:/ If that is not what the disk image actually contain, then please provide more information on what's in it. Note that, if the OS spans multiple disks, then you need to pass all of them to libguestfs tools. > I can notice: > > ... > libguestfs: trace: is_whole_device = 0 > libguestfs: trace: mount_ro "/dev/sda1" "/" > guestfsd: main_loop: proc 395 (is_whole_device) took 0.00 seconds > guestfsd: main_loop: new request, len 0x40 > commandrvf: stdout=n stderr=y flags=0x0 > commandrvf: mount -o ro /dev/sda1 /sysroot/ > [ 11.558704] EXT4-fs (sda1): mounted filesystem with ordered data mode. > Opts: (null) > libguestfs: trace: mount_ro = 0 > libguestfs: trace: part_to_dev "/dev/sda1" > ... > > which suggests that '--rw' as mount option failed. This is done during the inspection, when all the partitions are mounted read-only. > also using '-m/dev/sda1:/:rw' does not help. Please provide the output (with -v -x) of that, then.
I attached the output of: $ guestfish --rw -v -x -a d.vmdk -m/dev/sda1:/:rw -i copy-in appwall-config.tgz /appwall_7.6.2.0_b195/master/appwall/ This vmdk image is bootable and installed (Ubuntu 16). I wander what hints guestfish the os, and then I can put these hints into the vmdk.
Created attachment 1470317 [details] guestfish with -x -v flags
(In reply to Itzik Yarhi from comment #3) > I attached the output of: > $ guestfish --rw -v -x -a d.vmdk -m/dev/sda1:/:rw -i copy-in > appwall-config.tgz /appwall_7.6.2.0_b195/master/appwall/ This still fails because you are still asking guestfish to inspect the guest, and mount the partitions based on the result of the inspection -- see the -i option. If you remove -i, then it should work fine, and mount /dev/sda1 as /. > This vmdk image is bootable and installed (Ubuntu 16). Is it a "classic" installed system, or some kind of live system? How did you get/install it?
Created attachment 1470516 [details] guestfish withour -i flag
I attached output of: $ guestfish --rw -v -x -a d.vmdk -m/dev/sda1:/:rw copy-in appwall-config.tgz /appwall_7.6.2.0_b195/master/appwall/ it fails: ... guestfsd: main_loop: new request, len 0x48 commandrvf: stdout=n stderr=y flags=0x0 commandrvf: mount -o rw /dev/sda1 /sysroot/ qemu-system-x86_64: Could not write to allocated cluster for streamOptimized qemu-system-x86_64: Could not write to allocated cluster for streamOptimized qemu-system-x86_64: Could not write to allocated cluster for streamOptimized qemu-system-x86_64: Could not write to allocated cluster for streamOptimized qemu-system-x86_64: Could not write to allocated cluster for streamOptimized qemu-system-x86_64: Could not write to allocated cluster for streamOptimized [ 15.838071] sd 2:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 15.838823] sd 2:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current] [ 15.839329] sd 2:0:0:0: [sda] tag#0 Add. Sense: I/O process terminated [ 15.840671] sd 2:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 00 08 00 00 00 08 00 [ 15.841238] blk_update_request: I/O error, dev sda, sector 2048 [ 15.841584] blk_update_request: I/O error, dev sda, sector 2048 [ 15.841906] Buffer I/O error on dev sda1, logical block 0, lost sync page write [ 15.845260] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) libguestfs: trace: mount_options = 0 libguestfs: trace: copy_in "appwall-config.tgz" "/appwall_7.6.2.0_b195/master/appwall/" libguestfs: trace: is_dir "/appwall_7.6.2.0_b195/master/appwall/" guestfsd: main_loop: proc 74 (mount_options) took 0.22 seconds guestfsd: main_loop: new request, len 0x58 libguestfs: trace: is_dir = 1 libguestfs: trace: tar_in "/dev/fd/3" "/appwall_7.6.2.0_b195/master/appwall/" guestfsd: main_loop: proc 38 (is_dir) took 0.04 seconds .... 1. this is not live system. the image is not connected to any running ova. 2. it is ubuntu ova. with one partition as root fs, and swap for the second partition.
Most probably the read-write support in qemu for VMDK is not perfect nor bug-free. Where did you get that OVA from? Did you create it, or downloaded it from somewhere?
This is basically the same as https://bugzilla.redhat.com/show_bug.cgi?id=1600789
(In reply to Richard W.M. Jones from comment #9) > This is basically the same as > https://bugzilla.redhat.com/show_bug.cgi?id=1600789 For the VMDK issues, yes, thanks. I'm still interested in the detection of the guest.
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.
Reopening because Virtualization Tools has not been discontinued.