Libguestfs - Dec 2014 - does guestfs_list_partitions() work with Windows 95 images?

Hello,
Been a long time since I broke out your libguestfs tools.
Current employer has some old machines they want to virtualize before they
croak.

I was able to virtualize a Win2000 box but when I tried the same with a
Windows 95 machine the call to guestfs_list_partitions returned null.

I did make that image with a different tool (my linux box wasn't available
so I wound up using Macrium Reflect on Windows) - but I don't believe the
image was corrupted.

Thanks,

Skippy

On Sun, Dec 14, 2014 at 09:13:59PM -0500, Skippy VonDrake
wrote:
> Hello,
> Been a long time since I broke out your libguestfs tools.
> Current employer has some old machines they want to virtualize before they
> croak.
> 
> I was able to virtualize a Win2000 box but when I tried the same with a
> Windows 95 machine the call to guestfs_list_partitions returned null.
You'd probably be the first to try it.

As far as I know it _should_ work.  You could try doing the following
which should give more information about what's really going on:

  guestfish -v -x --ro -a win95.img run : list-partitions

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Let's keep all replies on the list]

On Tue, Dec 16, 2014 at 12:43:21AM -0500, Skippy VonDrake
wrote:
> Looks like that returned an empty array. Could the image be corrupt?
> 
> Here's the output:
> 
> # guestfish -v -x --ro -a /home/skippy/disk_images/[...]/old.img  run :
list-partitions
[...]
> [    0.558351] scsi2 : Virtio SCSI HBA
> [    0.560916] scsi 2:0:0:0: Direct-Access     QEMU     QEMU HARDDISK
>  2.0. PQ: 0 ANSI: 5
> [    0.562418] scsi 2:0:1:0: Direct-Access     QEMU     QEMU HARDDISK
>  2.0. PQ: 0 ANSI: 5
> [    0.590401] sd 2:0:0:0: Attached scsi generic sg0 type 0
> [    0.592464] sd 2:0:0:0: [sda] 4122952 512-byte logical blocks: (2.11
> GB/1.96 GiB)
> [    0.594758] sd 2:0:1:0: Attached scsi generic sg1 type 0
> [    0.595840] sd 2:0:1:0: [sdb] 8388608 512-byte logical blocks: (4.29
> GB/4.00 GiB)
> [    0.597380] sd 2:0:0:0: [sda] Write Protect is off
> [    0.598437] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [    0.600092] sd 2:0:1:0: [sdb] Write Protect is off
> [    0.601216] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [    0.603609]  sda:
The appliance kernel couldn't find any partitions at all on the disk.

Is it a raw format disk image, or some other format that qemu can
reasonably be expected to read?

If it is, then yes I'd say the image is corrupted.  However you'd
probably want to hexdump it to see what's really going on.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

>
> The appliance kernel couldn't find any partitions at all on the disk.
>
> Is it a raw format disk image, or some other format that qemu can
> reasonably be expected to read?

I used the "Advanced Options" of Macrium Reflect (on Windows 7) to do
a raw
byte copy.

If it is, then yes I'd say the image is corrupted.  However
you'd
> probably want to hexdump it to see what's really going on.
>
I looked at the first sector wondering if Macrium prepended its own stuff
but it looks like the start of a boot sector to me.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  EB 3E 90 4D 53 57 49 4E 34 2E 30 00 02 40 01 00  ë>.MSWIN4.0..@..
00000010  02 00 02 00 00 F8 FC 00 3F 00 40 00 3F 00 00 00  .....øü.?.@.?...
00000020  41 E0 3E 00 80 00 29 91 2C 95 24 20 20 20 20 20  Aà>.€.)‘,•$
00000030  20 20 20 20 20 20 46 41 54 31 36 20 20 20 F1 7D        FAT16   ñ}

As for examining the rest of the image at the hex level and making an
assessment - that is beyond my scope of expertise.
But certainly it could have been corrupted.
I'll see if I can get access to the drive and use Linux (and dd) to make a
new image.