Windows 7 (x64) - problems creating and deploying image



  • Good day,

    I’m in the progress of setting up a FOG Server with all the bells and whistles. This, of course, includes creating and testing an image.
    This has taken a long time already (over two weeks now) due to various problems (storage, networking, but also things that weren’t documented properly or at all on the Wiki).

    Anyway, the stadium I’m in now is to create an image.
    The FOG server is a virtual machine, the clients to be imaged are all physical (VLANs etc, hence “network problems”). See more info below.

    What I’m trying to do:
    Succesfully create an image of a Windows 7 (x64) installation and put it on another machine. Simple. Or so I thought…

    What I’ve tried:
    Already existing installation of Windows 7 (with just FOG service), had to remove the factory recovery partition. Ran FOGprep.
    [INDENT=1]With this, I successfully [I]created[/I] an image, but deploying failed with missing MBR. This is acceptable for one or two PC’s, but not if you want to image 50+ computers.[/INDENT]
    A fresh installation of Windows 7, drivers installed, FOG service installed, FOGprep and sysprep run.
    [INDENT=1]Same problem as previous.[/INDENT]
    A fresh installation of Windows 7 using IDE mode instead of AHCI mode. This because I keep reading you need to put IDE mode instead of SCSI mode (AHCI is definitely not IDE).
    [INDENT=1]Same problem.[/INDENT]
    A fresh installation of Windows 7 using default AHCI on just ONE partition with a hack/workaround during setup.
    [INDENT=1]FOG successfully starts imaging, resizing the partition fails, however. And thus it starts imaging the [I]entire disk, [/I]which I try to avoid due to space limits on the host.[/INDENT]
    [INDENT=1]When I try it again with a new image in FOG (changed configuration might have some issues, I thought) without changing the physical computer, FOG is saying there is no partition table found (unable to mount/umount /dev/sda1 /ntfs).[/INDENT]

    More information:
    I AM able to PXE boot the clients just fine, I can make an inventory of them just fine as well.
    I also updated the kernel to 3.3.3 saved it to fog/kernel/bzImage_3.3.3, and managed to get that working without any problems. Thus, I made this the default kernel clients boot with.
    FOG Host:
    Running on a ESXi 4.1 host
    Debian Squeeze with kernel 2.6.32-5-686
    Using a folder on an iSCSI storage node as FOG node (there are some problems with this as well, but I’m pretty certain those are unrelated to FOG. Heck, this took about 24 hours to set up.)
    Two network devices:
    [INDENT=1]eth0 = vLAN 14 -> 172.21.2.11 | this connects to the clients (located in network 172.21.7)[/INDENT]
    [INDENT=1]eth1 = vLAN 16 -> 172.21.3.24 | this connects to the iSCSI (same network)[/INDENT]
    1 GB RAM
    16 GB virtual HDD
    Plenty CPU :D

    If any one of you could assist me in this matter, it would be greatly appreciated.

    See attached my Unattend.xml file in txt format because .xml isn’t allowed it seems :p (FYI: the productkey is a public KMS key).

    Status update:
    I’ve made a new Windows 7 installation with default settings (+100 MB system recovery partition) and I tried to image it straight after the main installation (Copying, extracting, installing, updating, finalizing…)
    It starts off good, resize test, resizing (all done pretty fast too), then it starts imaging.
    System partition took a few seconds (less than 10).
    Main partition started, just fine. I go back to my seat, and about two minutes later as I go to check, it’s seemingly finished (computer shut down after job)… But it can’t be THAT fast, can it? (Approximate size was 8-9 GB.) So I go to check on the iSCSI:
    [CODE]ghost@DPO-GHOST:/iscsi/fog/CompaqElite8200$ ls -lah
    total 191M
    drwxrwxrwx 1 root root 256 Oct 31 16:30 .
    drwxrwxrwx 1 root root 352 Oct 31 16:30 …
    -rwxrwxrwx 1 root root 8.5M Oct 31 16:30 rec.img.000
    -rwxrwxrwx 1 root root 182M Oct 31 16:30 sys.img.000
    [/CODE]
    So yeah, failed. How is that possible? This is the second time this has happened now.
    I’d love to peek in the logs… If I knew where those logs are :\

    Restarted imaging, works now. Put it back to different client, worked. But I still get “Unable to load \windows\system32\winload.exe” (something like that… it’s a known issue it seems).
    The source client (WST279) boots just fine.
    The target client (WST281) gives that error.

    ANOTHER UPDATE!
    So I tried installing Windows 7 Pro 32-bit instead of Windows 7 Pro 64-bit. Right after the installation, I imaged it and restored to a different client… And it just works!
    Well, that’s a rather interesting development: restoring a 64-bit Windows 7 install does not work for me.
    This is a problem though, as several programs that are going to be deployed are 64-bit applications. Deploying 32-bit Windows is a definite no go.

    Well, that was a ‘it works once’ thing… Everything still fails at this point. I’ve decided I’m going to try out WDS instead of FOG.

    EDIT: added kernel info.
    EDIT2: Mods, please move topic to proper section if it should be under "Windows Problems"
    EDIT3: sitrep
    EDIT4: 32 bit
    EDIT5: thanks for the help (not).

    [url="/_imported_xf_attachments/0/183_Unattend.txt?:"]Unattend.txt[/url]


  • Moderator

    I have successfully imaged and deployed windows 7 pro 64 bit. I did nothing different than 32 bit, because FOG doesn’t care about the 32/64 bit part of the OS. Fog does have problems with OEM hidden/recovery partitions, so I either install fresh or use gparted to remove that partition and recover the space.

    I do not use FOGPREP or SYSPREP before I image. I do sysprep early on during the image creation process, but only to copyprofile. I then finish installing programs and changing settings, then remove from the domain and upload the image without sysprepping or fogprepping. Most of the time, I don’t even have to chkdsk or defrag.

    The one thing I do is use a mutliple partition - single disk image type because that’s how it got it to work and all machines I image have the same size or larger HD as the one I took the image from.

    FOG is free and we are all volunteers on the forums, trying to help when and where we can.



  • Bump because nobody cares


Log in to reply
 

454
Online

38968
Users

10709
Topics

101631
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.