2

Just to see if it could be done (and if so, move other physical XP machines to VM environments), I took the hard drive out of a decommissioned laptop, captured a WIM of it, and applied it to a QCOW2 disk. It fails to boot. It's stuck at "Booting from Hard Disk...". I've already seen this link. The behavior is what I'm seeing, but the solution has suggestions that are already set for this VM, and the machine started as a physical machine that I captured, not a converted Hypervisor machine.

The source drive has Windows XP. The WIM was captured on Windows using gimagex (GUI frontend for imagex). I installed wimtools in an existing Ubuntu Server 18 KVM machine ("US18"). With "US18" shut down, I added a new 40 GB QCOW2 disk to it, started it up, partitioned the disk with fdisk (partition type 7), marked the partition as active, and formatted as NTFS.

I used wimverify to verify the WIM ('twas good). I used wimapply WinXP.wim /dev/vdb1 to apply the captured WIM to the virtual disk. That went well.

I've set the CPU count and memory to an XP-era appropriate count and size. It's not set to boot using UEFI. It's using "BIOS" and "i440FX". It's stuck at the titular "booting..." message.

I've done all I can think of. I'd prefer to migrate an existing machine rather than install XP fresh and then move the programs and such to the VM.

I've changed the "Bus type" for the vdisk to IDE and SATA, with no effect.

Does anyone have any pointers for me?

Below are the full steps to prepare the disk and apply the WIMage.

root@US18 <01>:~# ls -l /dev/disk/by-path
total 0
lrwxrwxrwx 1 root root  9 Nov 23 17:19 pci-0000:00:01.1-ata-1 -> ../../sr0
lrwxrwxrwx 1 root root  9 Nov 23 17:19 pci-0000:00:07.0 -> ../../vda
lrwxrwxrwx 1 root root 10 Nov 23 17:19 pci-0000:00:07.0-part1 -> ../../vda1
lrwxrwxrwx 1 root root 10 Nov 23 17:19 pci-0000:00:07.0-part2 -> ../../vda2
lrwxrwxrwx 1 root root  9 Nov 23 17:19 pci-0000:00:09.0 -> ../../vdb
lrwxrwxrwx 1 root root  9 Nov 23 17:19 virtio-pci-0000:00:07.0 -> ../../vda
lrwxrwxrwx 1 root root 10 Nov 23 17:19 virtio-pci-0000:00:07.0-part1 -> ../../vda1
lrwxrwxrwx 1 root root 10 Nov 23 17:19 virtio-pci-0000:00:07.0-part2 -> ../../vda2
lrwxrwxrwx 1 root root  9 Nov 23 17:19 virtio-pci-0000:00:09.0 -> ../../vdb

root@US18 <02>:~# fdisk -l /dev/vdb
Disk /dev/vdb: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

root@US18 <03>:~# fdisk /dev/vdb

Welcome to fdisk (util-linux 2.31.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xefae0542.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p):

Using default response p.
Partition number (1-4, default 1):
First sector (2048-62914559, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-62914559, default 62914559):

Created a new partition 1 of type 'Linux' and of size 30 GiB.

Command (m for help): t
Selected partition 1
Hex code (type L to list all codes): 7
Changed type of partition 'Linux' to 'HPFS/NTFS/exFAT'.

Command (m for help): a
Selected partition 1
The bootable flag on partition 1 is enabled now.

Command (m for help): p
Disk /dev/vdb: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xefae0542

Device     Boot Start      End  Sectors Size Id Type
/dev/vdb1  *     2048 62914559 62912512  30G  7 HPFS/NTFS/exFAT

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

root@US18 <04>:~# mkfs.ntfs -f /dev/vdb1
Cluster size has been automatically set to 4096 bytes.
Creating NTFS volume structures.
mkntfs completed successfully. Have a nice day.

root@US18 <05>:~# wimapply WinXP.wim /dev/vdb1 --check
Verifying integrity of "/root/WinXP.wim": 9 GiB of 9 GiB (100%) done
Applying image 1 ("WIM1") from "/root/WinXP.wim" to NTFS volume "/dev/vdb1"
Creating files: 72106 of 72106 (100%) done
Extracting file data: 17 GiB of 17 GiB (100%) done
Done applying WIM image.

root@US18 <06>:~# mount /dev/vdb1 /mnt/

root@US18 <07>:~# ls -lh /mnt
total 5.1M
drwxrwxrwx 1 root root    0 Feb 12  2013  1a065bae91d7da681f18ce
-rwxrwxrwx 1 root root    0 Feb 10  2013  AUTOEXEC.BAT
-rwxrwxrwx 1 root root  211 Feb 19  2013  boot.ini
-rwxrwxrwx 1 root root   86 Feb 12  2013  chicony.log
-rwxrwxrwx 1 root root    0 Feb 10  2013  CONFIG.SYS
drwxrwxrwx 1 root root 4.0K Feb 19  2013 'Documents and Settings'
...
drwxrwxrwx 1 root root  24K Nov 21 22:32  temp
drwxrwxrwx 1 root root 256K Feb 27  2018  WINDOWS
-rwxrwxrwx 1 root root 956K Jul  6  2011  Xtension

root@US18 <08>:~# umount /mnt
2
  • 1
    It's Windows XP. You're going to be lucky to recover files. A fresh install ought to work, but really, it's so many years obsolete that someone could justifiably question the sanity of whoever told you to do this... That said, skip the WIM crap and just try booting the raw P2V disk image. Nov 23, 2018 at 22:58
  • @MichaelHampton, "sanity", that's cute. :) My company is moving buildings within the next six months and the software developer is leaving sooner. If we don't have the old software ported to a newer OS, we have to take the old hardware with us until the software is updated. If I can at least virtualize the environment I can make it so we're not beholden to old hardware at least.
    – user38537
    Nov 23, 2018 at 23:01

0

You must log in to answer this question.