Transfer Windows to another computer using Linux
After reading the article “Frivolous cloning of MS Windows XP / Server 2003 OS with your own hands, using GNU / Linux”, there was a natural desire to supplement it in accordance with the realities of the end of 2014.
In general, the problem of deploying a particular version of Windows consists of two parts - first, you need to copy the partition data from the reference PC to the new one, and, second, you must ensure that Windows is loaded on the changed hardware.
Let's start by copying the data. What data do we need to copy? For Windows XP, this is the MBR (446 bytes at the beginning of the disk, the main partition table and the final signature 55AAh), data about the extended partitions and the actual data of the Windows system partition. For Vista and Windows 7, a 100 Mbyte system partition is also added (we do not consider GPT). It should be remembered that the first partition in Windows XP by default starts from sector 63, and in Windows Vista / 7 - from sector 2048. Naturally, we will carry out all operations on non-running Windows, booting from the System Resque CD .
So, you should not copy the MBR "in the forehead", for this in Linux there is a utility ms-sys, which records the bootloader of any version of Windows from Win95 to Win7 in the MBR. To save and restore partition structure there is the sfdisk utility.
')
For example:
Added by:
In order for WIndows to boot, you must also create a disk signature (disk signature). To do this, read the contents of the registry key HKLM \ SYSTEM \ MountedDevices \ <\ DosDevices \ "Partition name on the disk with a colon">, and select the first 8 bytes (in hexadecimal), for example: 4F BE 4F BE. You can do this on an NTFS volume mounted on Linux using the reged utility described below. It should be noted that in the reged key name containing a slash, you need to specify a double slash, for example: \\ DosDevices \\ C :. Then, these 8 bytes should be written to disk starting at offset 0x01B8 with the hexedit utility. After that, the disc is ready to boot.
After copying the MBR and partition structure, you can copy the actual partition data using partclone. The partclone tool allows you to create images of ext2 / 3/4, fat, ntfs, xfs, btrfs, reiserfs, etc., by analyzing the internal structure of the file system and including only used sectors in the image. Create a partition image on the reference PC using partclone, the image size will be equal to the size of the space used on the volume.
and on the target computer will deploy it
or
It is also possible to directly copy data from one device to another using the -b key:
Now consider the issue of data recovery per partition size, smaller than the reference. To do this, mount the partclone image and either copy files from it to the target volume while preserving the attributes, permissions, hardlink and other NTFS properties, or reduce the size of the NTFS partition inside the partclone image, and then copy this reduced partition to the target volume with the command partclone.ntfs with the -b option.
I don’t know the tools that could be used to copy files and hardlink from Linux NTFS volumes to one with all attributes and streams (if anyone knows, please, in the comments), so we only have the option of decreasing the size of the volume. Fortunately, there is an imagemount tool that exports the partclone image as a nbd block device and supports image mounting including recording, while the changes are saved in a separate file (-c key). Export the volume to write
Now we will change the size of the file system on the NTFS volume. A test run will be done first (-n key)
and then the real one:
Clone section:
Unfortunately, partclone does not support image compression, but this problem can be bypassed with the help of Linux's crutches and backups. Create an empty qcow2 format image with a virtual size that is known to exceed our needs (for example, 1 Tb). Its real volume will increase depending on the amount of data that we write there.
We mount it as a block device
Now let's copy the file system to the virtual device.
unmount the device and as a result we get a qcow2 file with a size slightly larger than the size of the original NTFS volume. Now you can apply internal compression to the file:
It is easy to see that this method requires double the disk space to store the original and compressed images, as well as additional time for compression. If we use another crutch, we will get rid of these shortcomings. After mounting the qcow2 image (using the qcow-nbd -c / dev / nbd0 <image file> command), format it into the btrfs file system
and now mount with compression:
and create an NTFS file system image
After that, unmount everything.
As a result, we get a file image with compression, which includes only used sectors and which can be mounted via imagemount as a file system and read its contents.
For example, I managed to reduce the size of an image from freshly installed Windows XP from 2.7 Gb to 587 Mb. In this case, you can mount the image without unpacking and view the files inside.
Much better than scolded dd | gzip, right?
Now we are faced with the second task - to make so that the NTFS Windows installed on the volume can start. In the case of Windows 7, we also copy the boot partition, for Windows Vista, we additionally (with the Windows Vista Live CD) overwrite the BCD so that the data in this area matches the hard disk serial number, check that the boot partition has the appropriate boot flag ( through parted) and reboot. Then with some probability we get a blue screen with the inscription 0x0000007B Inaccesseble boot device. In this case, for Windows XP, it is recommended to set the correct HAL, but luck, I haven’t met single-core PCs without APIC and, all the more, ACPI, so our reference image most likely already contains the correct multi-processor HAL. Therefore you should not hope that replacing HAL immediately fix our problem. Most likely, the reason is that Windows did not recognize the hard disk controller, and, accordingly, could not continue loading it.
Suppose we didn’t use sysprep to create a benchmark (otherwise it’s unsportsmanlike, because sysprep will do all the work for us). Let's try to understand why Windows does not find the disk controller on the new hardware, despite the fact that in the case of a “clean” installation, it sees this controller. The fact is that at the final stage of the installation, Windows disables (ostensibly to speed up boot) all disk controller drivers that do not have system partitions. It turns out as with a gopher in the film "DMB": the system does not see it, but it exists.
For Windows XP, there is a well-known MergeIDE patch, which, in fact, includes IDE device drivers in the registry back, copying the driver files from driver.cab to \ system32 \ drivers. The problem is that this patch is designed to run from under Windows. Let's try to put it under Linux manually. Let the partition with Windows XP mounted on / mnt with us, then:
In order to impose the patch MergeIDE.reg on the registry, you need to edit it, removing line breaks with the “\” symbol in the last lines of the file, and then use the reged utility with the -I key
It may also be necessary to fix the CurrentControlSet key, which is not available on unlocked Windows, on ControlSet001 / 002.
After that, you can reboot. It must be said, in my practice there were several cases where it was not possible to launch an image on other equipment either using the above method or using paid tools like Acronis Universal Restore.
Looking at the contents of the MergeIDE.reg file, you can see that the whole magic of running the boot driver is to add entries to two registry branches — HKLM \ SYSTEM \ CurrentControlSet \ Control \ CriticalDeviceDatabase and HKLM \ SYSTEM \ CurrentControlSet \ Services.
The CriticalDeviceDatabase branch contains the list of devices necessary for successful system boot and sets the correspondence between the device class and the service (driver) that is responsible for it, and the Services branch contains the parameters of specific drivers. Of particular interest is the Start parameter - the launch level:
0 - boot before the kernel starts with the OS loader
1 - load at the moment of kernel initialization
2 - loading during OS startup
3 - load on demand
4 - do not download
Obviously, if our driver’s launch level differs from 0, then we will not see the corresponding controller at boot time.
MergeIDE.reg operates with a class identifier 4d36e96a-e325-11ce-bfc1-08002be10318 - ATA / ATAPI disk controllers. ClassGUID identifiers for various classes of devices are known, they can be found, for example, here .
Thus, it is possible to force the system to start at the moment of kernel loading into memory any driver, for example, for a network card, if you boot via AoE or iSCSI.
For Windows Vista / 7, you can simply go through the Services branch in search of drivers containing the word IDE in the title, and then change the startup type (Start key) from “3-delayed launch” to “0-load at the time of loading the kernel”. For these OSs, there is another way - we find the msachi and iaStorV entries in the Services branch (the universal AHCI driver and the AHCI driver for Intel devices) and also change the startup type from “3” to “0”, and then go to the BIOS and change there type of disk controller on AHCI. With Windows XP, such a focus, unfortunately, does not work, due to the lack of a built-in universal AHCI driver.
Therefore, we turn our attention to the absolutely magic driver of the UniATA disk controller from Alexander Telyatnikov aka Alter. This driver initializes any controller that considers itself IDE- or AHCI-compliant, and therefore is great for our purposes. The installation procedure is exactly the same - copy the driver file, register in CriticalDeviceDatabase and in Services.
Now we integrate the my_uniata_inst.reg file into the image as follows
Here ven_8086 & dev_2922 is the identifier of the installed SATA controller. We also believe that we do not have CurrentControlSet and use the active branch - ControlSet001, whose number is specified in HKLM \ SYSTEM \ Select \ Current.
If this method does not work, you can try more “dirty” installation methods using the uniata_w2k.reg file from the driver archive or following the instructions on the developer’s website.
The main set of utilities can be found in the System Rescue CD . These include ms-sys, mkfs.btrfs, sfdisk, partclone and reged. Imagemount can be taken from the partclone-utils package by simply unpacking it into the root systemresquecd file system. With qemu-utils, things are more complicated. I created a minimal Debian installation in a separate directory using debootstrap, then chroot there and then installed qemu-utils via apt-get. Before running qemu-nbd, you need to remember to mount / proc, / sys and / dev inside the chroot.
In general, the problem of deploying a particular version of Windows consists of two parts - first, you need to copy the partition data from the reference PC to the new one, and, second, you must ensure that Windows is loaded on the changed hardware.
MBR, partition table and disk signature
Let's start by copying the data. What data do we need to copy? For Windows XP, this is the MBR (446 bytes at the beginning of the disk, the main partition table and the final signature 55AAh), data about the extended partitions and the actual data of the Windows system partition. For Vista and Windows 7, a 100 Mbyte system partition is also added (we do not consider GPT). It should be remembered that the first partition in Windows XP by default starts from sector 63, and in Windows Vista / 7 - from sector 2048. Naturally, we will carry out all operations on non-running Windows, booting from the System Resque CD .
So, you should not copy the MBR "in the forehead", for this in Linux there is a utility ms-sys, which records the bootloader of any version of Windows from Win95 to Win7 in the MBR. To save and restore partition structure there is the sfdisk utility.
')
For example:
sfdisk -d /dev/sda > ./parttable.txt ( ) sfdisk -f /dev/sda < ./parttable.txt ( ) ms-sys -mbr /dev/sda ( MBR Windows XP) Added by:
In order for WIndows to boot, you must also create a disk signature (disk signature). To do this, read the contents of the registry key HKLM \ SYSTEM \ MountedDevices \ <\ DosDevices \ "Partition name on the disk with a colon">, and select the first 8 bytes (in hexadecimal), for example: 4F BE 4F BE. You can do this on an NTFS volume mounted on Linux using the reged utility described below. It should be noted that in the reged key name containing a slash, you need to specify a double slash, for example: \\ DosDevices \\ C :. Then, these 8 bytes should be written to disk starting at offset 0x01B8 with the hexedit utility. After that, the disc is ready to boot.
NTFS partition data
After copying the MBR and partition structure, you can copy the actual partition data using partclone. The partclone tool allows you to create images of ext2 / 3/4, fat, ntfs, xfs, btrfs, reiserfs, etc., by analyzing the internal structure of the file system and including only used sectors in the image. Create a partition image on the reference PC using partclone, the image size will be equal to the size of the space used on the volume.
partclone.ntfs -c -s /dev/sda1 -o < > and on the target computer will deploy it
partclone.ntfs -r -s < > -o /dev/sda1 or
partclone.restore -s < > -o /dev/sda1 Unfortunately, internal compression is not supported in the image.It is also possible to directly copy data from one device to another using the -b key:
partclone.ntfs -b -s /dev/sda1 -o /dev/sdb1 Now consider the issue of data recovery per partition size, smaller than the reference. To do this, mount the partclone image and either copy files from it to the target volume while preserving the attributes, permissions, hardlink and other NTFS properties, or reduce the size of the NTFS partition inside the partclone image, and then copy this reduced partition to the target volume with the command partclone.ntfs with the -b option.
I don’t know the tools that could be used to copy files and hardlink from Linux NTFS volumes to one with all attributes and streams (if anyone knows, please, in the comments), so we only have the option of decreasing the size of the volume. Fortunately, there is an imagemount tool that exports the partclone image as a nbd block device and supports image mounting including recording, while the changes are saved in a separate file (-c key). Export the volume to write
modprobe nbd max_part=16 imagemount -w -D -d /dev/nbd0 -f /mnt/images/winxp.img -c ./cow.bin Now we will change the size of the file system on the NTFS volume. A test run will be done first (-n key)
ntfsresize -s < > -n /dev/nbd0 and then the real one:
ntfsresize -s < > /dev/nbd0 Clone section:
partclone.ntfs -b -s /dev/nbd0 -o /dev/sda1 And now - a pinch of pichalki
Imagemount, even the latest version - 0.3.1, does not work with disks for writing on the x86_64 architecture (hangs tight) and practically does not work on the i386 architecture (writes an image with errors), so resizing the partition is currently not possible. I will write in bugclitek partclone-utils.
Unfortunately, partclone does not support image compression, but this problem can be bypassed with the help of Linux's crutches and backups. Create an empty qcow2 format image with a virtual size that is known to exceed our needs (for example, 1 Tb). Its real volume will increase depending on the amount of data that we write there.
qemu-img create -f qcow2 < > 1024G We mount it as a block device
modprobe nbd max_part=16 qemu-nbd -c /dev/nbd0 < > Now let's copy the file system to the virtual device.
partclone.ntfs -b -s /dev/sda1 -o /dev/nbd0 unmount the device and as a result we get a qcow2 file with a size slightly larger than the size of the original NTFS volume. Now you can apply internal compression to the file:
qemu-img convert -c < > < > It is easy to see that this method requires double the disk space to store the original and compressed images, as well as additional time for compression. If we use another crutch, we will get rid of these shortcomings. After mounting the qcow2 image (using the qcow-nbd -c / dev / nbd0 <image file> command), format it into the btrfs file system
mkfs.btrfs /dev/nbd0 and now mount with compression:
mount -o compress-force=zlib /dev/nbd0 /mnt and create an NTFS file system image
partclone.ntfs -c -s /dev/sda1 -o /mnt/ntfs-image.bin After that, unmount everything.
As a result, we get a file image with compression, which includes only used sectors and which can be mounted via imagemount as a file system and read its contents.
For example, I managed to reduce the size of an image from freshly installed Windows XP from 2.7 Gb to 587 Mb. In this case, you can mount the image without unpacking and view the files inside.
Much better than scolded dd | gzip, right?
Running Windows on new hardware
Now we are faced with the second task - to make so that the NTFS Windows installed on the volume can start. In the case of Windows 7, we also copy the boot partition, for Windows Vista, we additionally (with the Windows Vista Live CD) overwrite the BCD so that the data in this area matches the hard disk serial number, check that the boot partition has the appropriate boot flag ( through parted) and reboot. Then with some probability we get a blue screen with the inscription 0x0000007B Inaccesseble boot device. In this case, for Windows XP, it is recommended to set the correct HAL, but luck, I haven’t met single-core PCs without APIC and, all the more, ACPI, so our reference image most likely already contains the correct multi-processor HAL. Therefore you should not hope that replacing HAL immediately fix our problem. Most likely, the reason is that Windows did not recognize the hard disk controller, and, accordingly, could not continue loading it.
Suppose we didn’t use sysprep to create a benchmark (otherwise it’s unsportsmanlike, because sysprep will do all the work for us). Let's try to understand why Windows does not find the disk controller on the new hardware, despite the fact that in the case of a “clean” installation, it sees this controller. The fact is that at the final stage of the installation, Windows disables (ostensibly to speed up boot) all disk controller drivers that do not have system partitions. It turns out as with a gopher in the film "DMB": the system does not see it, but it exists.
Turn on IDE-controllers: patch MergeIDE
For Windows XP, there is a well-known MergeIDE patch, which, in fact, includes IDE device drivers in the registry back, copying the driver files from driver.cab to \ system32 \ drivers. The problem is that this patch is designed to run from under Windows. Let's try to put it under Linux manually. Let the partition with Windows XP mounted on / mnt with us, then:
cabextract -d /tmp/drivers "/mnt/WINDOWS/system32/Driver Cache/i386/driver.cab" cd /tmp/drivers cp atapi.sys intelide.sys pciide.sys pciidex.sys /mnt/WINDOWS/system32/drivers In order to impose the patch MergeIDE.reg on the registry, you need to edit it, removing line breaks with the “\” symbol in the last lines of the file, and then use the reged utility with the -I key
reged -I /mnt/WINDOWS/system32/config/system HKEY_LOCAL_MACHINE\\SYSTEM ./MergeIDE.reg It may also be necessary to fix the CurrentControlSet key, which is not available on unlocked Windows, on ControlSet001 / 002.
After that, you can reboot. It must be said, in my practice there were several cases where it was not possible to launch an image on other equipment either using the above method or using paid tools like Acronis Universal Restore.
Looking at the contents of the MergeIDE.reg file, you can see that the whole magic of running the boot driver is to add entries to two registry branches — HKLM \ SYSTEM \ CurrentControlSet \ Control \ CriticalDeviceDatabase and HKLM \ SYSTEM \ CurrentControlSet \ Services.
The CriticalDeviceDatabase branch contains the list of devices necessary for successful system boot and sets the correspondence between the device class and the service (driver) that is responsible for it, and the Services branch contains the parameters of specific drivers. Of particular interest is the Start parameter - the launch level:
0 - boot before the kernel starts with the OS loader
1 - load at the moment of kernel initialization
2 - loading during OS startup
3 - load on demand
4 - do not download
Obviously, if our driver’s launch level differs from 0, then we will not see the corresponding controller at boot time.
MergeIDE.reg operates with a class identifier 4d36e96a-e325-11ce-bfc1-08002be10318 - ATA / ATAPI disk controllers. ClassGUID identifiers for various classes of devices are known, they can be found, for example, here .
Thus, it is possible to force the system to start at the moment of kernel loading into memory any driver, for example, for a network card, if you boot via AoE or iSCSI.
For Windows Vista / 7, you can simply go through the Services branch in search of drivers containing the word IDE in the title, and then change the startup type (Start key) from “3-delayed launch” to “0-load at the time of loading the kernel”. For these OSs, there is another way - we find the msachi and iaStorV entries in the Services branch (the universal AHCI driver and the AHCI driver for Intel devices) and also change the startup type from “3” to “0”, and then go to the BIOS and change there type of disk controller on AHCI. With Windows XP, such a focus, unfortunately, does not work, due to the lack of a built-in universal AHCI driver.
Boot from any IDE or SATA controller: UniATA driver
Therefore, we turn our attention to the absolutely magic driver of the UniATA disk controller from Alexander Telyatnikov aka Alter. This driver initializes any controller that considers itself IDE- or AHCI-compliant, and therefore is great for our purposes. The installation procedure is exactly the same - copy the driver file, register in CriticalDeviceDatabase and in Services.
wget http://alter.org.ua/ru/soft/win/uni_ata/BusMaster_v45d.tgz tar -xzvf ./BusMaster_v45d.tgz cp uniata.sys /mnt/WINDOWS/system32/drivers cp atactl.exe /mnt/WINDOWS/system32 Now we integrate the my_uniata_inst.reg file into the image as follows
UniATA_Inst.reg
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_8086&dev_2922] "ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}" "Service"="uniata" [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\UniATA] "Type"=dword:00000001 "Start"=dword:00000000 "ErrorControl"=dword:00000000 "Group"="System Bus Extender" "ImagePath"=hex(2):53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,52,00,49,00,56,00,45,00,52,00,53,00,5c,00,75,00,6e,00,69,00,61,00,74,00,61,00,2e,00,73,00,79,00,73,00,00,00 [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\UniATA\Parameters\PnpInterface] "1"=dword:0x00000000 "5"=dword:0x00000000 "SkipRaids"=dword:0x00000001 Here ven_8086 & dev_2922 is the identifier of the installed SATA controller. We also believe that we do not have CurrentControlSet and use the active branch - ControlSet001, whose number is specified in HKLM \ SYSTEM \ Select \ Current.
reged -I /mnt/WINDOWS/system32/config/system HKEY_LOCAL_MACHINE\\SYSTEM ./my_uniata.reg If this method does not work, you can try more “dirty” installation methods using the uniata_w2k.reg file from the driver archive or following the instructions on the developer’s website.
Another pichalka
As it turned out, UniATA cannot initialize the Intel 8086: 2922 virtual controller, which is emulated by QEMU. The "neighboring" virtual IDE controller initializes remarkably. Whose bug is QEMU or UniATA is not entirely clear.
About tools
The main set of utilities can be found in the System Rescue CD . These include ms-sys, mkfs.btrfs, sfdisk, partclone and reged. Imagemount can be taken from the partclone-utils package by simply unpacking it into the root systemresquecd file system. With qemu-utils, things are more complicated. I created a minimal Debian installation in a separate directory using debootstrap, then chroot there and then installed qemu-utils via apt-get. Before running qemu-nbd, you need to remember to mount / proc, / sys and / dev inside the chroot.
Conclusion
Hidden text
Buy better Acronis Universal Restore
Source: https://habr.com/ru/post/245663/
All Articles