After image download windows boots to pxe then black screen

  • So I, finally, got a Windows 7 image uploaded and last night I set it up to download to 5 computers (identical specs to master). This morning I came in and all 5 were sitting on a black screen. No blinking cursor just black. This behaviour doesn’t change if I disable pxe, disconnect from network, or F12 to single boot from HDD. I found this ([url][/url]) but his solution is for an older version and the script in 1.2 is different. I’ve also tried changing the pxe menu exit behaviour from sanboot to exit with no effect. The HDD is visible from the BIOS and the sytem passed the self test. The server is Debian 7 on ESXi, FOG 1.2.0, OS is Win 7 Pro 64 bit with OEM licensing (not volume), and the client boxes are Optiplex 760’s with Core 2 Duos.

  • Redeploy finished and the box rebooted to the PXE menu. Booted to HDD and get the same black screen. Output of d1.original.partitions is the same.

  • Alright. I’ve done that and am redeploying to one of the test machines.

  • Senior Developer

    works retroactively.

    Follow these steps:

  • Ok. So where can I get the latest SVN? And from there should I just reimage the master and attempt to redeploy? Or does the fix work retroactively?

  • Developer

    [quote=“Michael Green, post: 38323, member: 26877”]
    /dev/sda1 : start= 63, size= 128457, Id= 7, bootable
    /dev/sda2 : start= 128520, size=156167865, Id= 7

    yep, looks like tom guessed right. this has been fixed in the SVN

  • The upload image was from a fresh install that I deployed some standard applications to (Avast, Some equipment drivers, Foxit). This is my first time attempting to use FOG (or pxe booting in general). The output you requested:

    partition table of /dev/sda

    unit: sectors

    /dev/sda1 : start= 63, size= 128457, Id= 7, bootable
    /dev/sda2 : start= 128520, size=156167865, Id= 7

    Additionally following your sig’s advice I checked the apache logs and they don’t contain anything applicable.

  • Senior Developer

    Also, if you’d be so daring, can you try the Latest SVN?

    It should have the workaround fixes to do the sector 63 issue as described in the previous posting in a more appropriate methodology.

  • Senior Developer

    My guess is the image that you “uploaded” from came from a resizable image downloaded to the machine from a 0.32 image. The upload was to bring it into current specs.

    Can you check the file:
    [code]/images/<imagename>/d1.original.partitions[/code] and give us the output of the /dev/sda1 partition?