One of my work tasks is to configure the computers that ship in our products with Windows OS images (Embedded and OEM) with a restore partition. I have been using Clonezilla Live with GRUB2 to implement this process. This worked fine with Windows XP/Embedded Standard 2009. This does not work with Windows 7 and I would presume anything later than Vista due to the Boot Manager changes. The current system image that I am trying to configure is as follows:
/dev/sda1, ntfs, PRIMARY, 62.5 GiB, 3.15 GiB, 59.35 GiB, no flags
/dev/sda2, ntfs, RESTORE, 4.00 GiB, 1.74 GiB, 2.26 GiB, hidden
/dev/sda3, fat32, CLONEZILLA, 4.00 GiB, 115.22 MiB, 3.89 GiB, hidden
/dev/sda4, ext4, BOOT, 1.00 GiB, 53.91 MiB, 970.09 MiB, boot
/dev/sda1 holds Windows 7 OEM (sealed), dev/sda2 holds a clonezilla based restore image (sealed)
/dev/sda MBR is GRUB2 bootloader
I can get GRUB2 to load fine and to restore the windows 7 image. However, I cannot get Windows 7 to boot and receive the 0xc0000225 error. Update: once I modified the boot sector as described below to get sda1 starting section to agree w/ the MBR, the 0xc0000225 disappeared and I started to receive the 0xc000000e error with the winload.exe file being the one it was complaining about to the user. However, this file is present and intact as far as I can tell via other utilities.
Information from Meierfrankenfeld's and Hulselmans's bootinfoscript show problems with sda1 (boot sector shows sda1 at sector 411648 verses fdisk which shows 2048) and sda3 (boot sectors shows sda3 at sector 0 and fdisk, which shows 164628480). I'm not sure what I need to modify at this point or the best tool for doing so. I'm fine with a hex editor if I could a good description of how the BCD and grub2 MBR are laid out. Update: I finally updated the boot sector to get agreement with fdisk for sda1.
Prior to sealing the machine and adding /dev/sda3 and /dev/sda4, I merged the Windows 7 boot partition onto on /dev/sda1. It rebooted and worked fine.
I have tried reading through the BCD materials that Microsoft provides and made sure that the Windows Boot Manager and Loader objects point to the correct partition (they had been using some custom=xyz syntax, which wasn't working either).
This restore worked nicely in the past as I was able to completely automate the restore process, which is a critical need for our end user. A restore disk is not an option here.
I have confirmed that the bcd is using partition=C: to refer to the device/os device/bootmgr device.
So, I have been able to confirm the MBR is present an intact, the VRB on sda1 is present and intact, the $MFT and $MFTMirr files exist at the location indicated in the VBR as confirmed by istat (not lstat) tool in sleuthkit. The winload file referenced in the above error exists at the location given to me by the fls sleuthkit utility and agrees with the filesize from other installations.
As an alternative, if you are an OEM and want to share a restore process that works well in a consumer/embedded environment, I would enjoy hearing that feedback as well. Thank you.
