Windows 7 image boots to blank screen after deployment

Eric Johnson

Hello all,

Fog 1.1.1 hosted on SL6 (RHEL6 ish) environment.

I got a win7 image uploaded. Yippie! But when I deploy (unicast) to a Dell T1500 with 250G hard disk after deploy (which looked like no errors) the system boots to a blank screen with a single underline cursor and never does anything else.

Doesn’t matter if I chain boot from upxe or F12 boot directly from disk.

Booting into debug shows the single partion is there and is even mountable vis ntfs-3g
(starts on 2048 sector)

Comparing MBR record installed (/usr/share/fog/mbr/win7.mbr) from this 1.1.1 fog and our old (working) .32 fog shows they are indentical and comparing current MBR on disk to /usr/share/fog/mbr/win7.mbr shows only the octets in partition table differ.

On a whim I also put back the original C:/Boot/BCD … didn’t help…

Any ideas?

Eric Johnson

Update 1. Windows boot/repair attempt was run from windows CD. Repair system finds nothing to repair. It thinks everything is just fine. Still doesn’t boot.

Junkhacker

will the system boot if you have it unplugged from the network?

Eric Johnson

No. It doesn’t matter if you chain boot off of upxe or use F12 to boot direct from disk, or disconnect the ethernet cable and have it skip the pxe boot. Same thing.

Tom Elliott

This sounds like the disk is partitioned through GPT, while the Windows system believes it’s an MBR style.

To fix this, boot the system into a Debug task (through the Basic Tasks->Debug, Debug - Download, Debug - Upload). After it boots, it will bring you to a command line prompt.

Do NOT run the fog script, simply run fixparts /dev/sda and press the letter w to fix the partitions, cancel the “debug created task”, reboot the system and see if all starts up properly. If it does, schedule and Upload task to fix the MBR tables.

Eric Johnson

Hi Tom, et al, Some updates:

ran fixparts on image before upload. Didn’t fix the problem. Still boots to a blank screen with single blinking underline cursor and nothing else.
took a working windows 7 image (one that was built on 0.32 and deploys just fine from our 0.32 fog server, moved it to 1.1.1 fog server and set the legacy flag and then told 1.1.1 fog server to use partimage to deply that image. Same result.

So… Im not sure what the issue is. As best I can tell the only diff between 0.32 and 1.1.1 with a partimage restore of single partition is that 0.32 puts the /dev/sda1 partition at sector 63 and 1.1.1 puts it at sector 2048.

But shouldn’t the MBR just be going to the first partition.

Im going to modify 1.1.1 to put win7 (type 5) first partition at sector 63 and see what happens. Stay tuned.

( Side note: On the positive side was able to get windows 8 image to upload and unicast download with no problems. )

Eric Johnson

Ok, so good news to report. Modifying the fog.download script to have single partition start at sector 63 for windows 7 (image type 5) has produced a successful deployment.

Now the question is why?

Is this because the uploaded image started on sector 63? Where/what in the OS would care about where partition 1 starts

(it is not the MBR, that is the same, and reflected partition start on 2048 on the non-successful deployments)

Having to be sure the single partition on deployed box always starts at same sector as the uploaded image seems to be a cumbersome long term solution.

Any windows experts care to chime in?

Here is the my current patch to make win7 deploy work. But like I said above, I consider this a hack, not a long term solution.

[code]
— fog.download.dist 2014-06-24 08:50:37.000000000 -0400
+++ fog.download 2014-06-24 08:36:46.000000000 -0400
@@ -41,6 +41,10 @@
win7imgroot=“$imagePath”;
if [ “$osid” == “5” ] || [ “$osid” == “6” ] || [ “$osid” == “7” ]; then
dots “Windows Boot Partition Exists”;

```
                 sectorstart=2048
```

                 if [ "$osid" == "5" ]; then

                         sectorstart=63

                 fi
                  if [ -f "$win7imgroot/rec.img.000" ]; then
                          echo "Yes";
                          win7partcnt="2";

@@ -76,7 +80,7 @@
parted -s $hd u kB rm 1 &>/dev/null;
echo “Done”;
dots “Preparing Hard Disks (Stage 3)”;

                                 parted -s $hd -a opt u kB mkpart primary ntfs 2048s $layPartSize &>/dev/null;

                                 parted -s $hd -a opt u kB mkpart primary ntfs ${sectorstart}s $layPartSize &>/dev/null;
                                  parted -s $hd u kB set 1 boot on &>/dev/null;
                          elif [ "$win7partcnt" == "2" ]; then
                                  dots "Preparing Hard Disks (Stage 2)";

[/code]

akakaffa

I too can confirm that I am experiencing this issue – running FOG Server 1.1.1 on Ubuntu 12.04.4 LTS.

Our Windows 7 PC’s original image was created from a clean windows 7 install (updates, couple programs installed - acrobat, etc, nothing special really) and imaged using the “Single Disk (NTFS Only) Resizable”

The partitions on the disk are as follows:

disk0part0: System (300MB)
disk0part1: OS (rest of drive - 248GB)

When I push the image to an identical spec’d PC, the image completes successfully but the cloned PC does not boot to windows (blank screen with single blinking “_” underscore )

Junkhacker

your windows boot partition must be 100mb, as per the standard default install.

user 1111122222

Eric:
How did you edit the Fog.download file? I can’t seem to find the same file on my system.
I have a fog.download file, but it is way different and does not contain the setting you describe.[SIZE=2] Can you please offer some [/SIZE]guidance[SIZE=2]?[/SIZE]
Admittedly, I am a linux noob so forgive me if this is obvious to others.

darKpoiSon

[quote=“user 1111122222, post: 31711, member: 24492”]Eric:
How did you edit the Fog.download file? I can’t seem to find the same file on my system.
I have a fog.download file, but it is way different and does not contain the setting you describe.[SIZE=2] Can you please offer some [/SIZE]guidance[SIZE=2]?[/SIZE]
Admittedly, I am a linux noob so forgive me if this is obvious to others.[/quote]

you would need to unpack the init.xz in /var/www/fog/service/ipxe/, do the changes and then repack it.
But I wouldn’t recommend doing that if your not familiar with linux…

phm2000

Hi

I have the same problem with fog 1.1.2 and dell 780 with single partition

Is there a solution ?

Thanks

user 1111122222

I found if I choose a RAW image it works perfectly. You have to wait 6 hours for the image to create the first time, and 40 minutes for each deploy, but at lease it works. RAW must get the boot sector correctly where the the others do not. Something is different because it works for me. It even works for Win8.1 and the new UEFI BIOS.

Jared

Same problem here on Lenovo desktop and laptop products.

Wile E Coyote

Hello All,
Has there been any update as to a full on fix for this issue? I am having the same issue with installing an image to Lenovo ThinkCentre M93p systems. I am willing to make the modifications to the init.xz , however I am not sure how to edit the init.xz after I’ve uncompressed it. When I open the file with a text editor its blank.

I’m looking to go back a few steps and use version .32 if this is not slated to be fixed soon…

Thank you for any help

Wile E coyote

Eric Johnson

Ok… here is a quick tutorial on modifying the init.xz image.

(this all based on my Centos 6 system, but i suspect would work pretty much the same on ubuntu)

First decompress the init.xz image that is used as the filesystem for the fog deployment kernel

xzcat /var/www/html/fog/service/ipxe/init.xz > /tmp/init

Then set it up as a loopback file system on /dev/loop0 (use /dev/loopX where X is something not in use if for some reason you have /dev/loop0 already in use)

losetup /dev/loop0 /tmp/init

Mount the loopback file system somewhere to modify it (again /dev/loopX same as above, and where you mount it can be any leaf difrectory)

mount /dev/loop0 /mnt

Then you can go in and modify /mnt/bin and modify fog.upload or fog.download

Once you have made the changes you want to make you first make sure no process has a current working directory or open file in the loopback file system, usually just cd / to effect that. Then you umount the file system and disconnect the loopback device

cd /
umount /mnt
losetup -d /dev/loop0

Then you recompress it and save it back where fog system looks for it…

mv /var/www/html/fog/service/ipxe/init.xz /var/www/html/fog/service/ipxe/init.xz.backup.YYYYMMDD
xz -C crc32 -9 -c /tmp/init > /var/www/html/fog/service/ipxe/init.xz

Hope that helps.

Ill post a diff to solve this same problem for 1.2.0 (above patch is 1.1.1) later this week.

(note… problem this all solves is when your win7 image starts on sector 63 instead of sector 2048)

Joseph Hales

I am having the same issue with a thinkcenter 5048 I was wondering if anyone had any suggestions for how to fix the windows boot partition to avoid this issue. I’m uncomfortable editing init.xz image and just resizing it seems to be a non starter because the existing data is more than 100mb.

Joseph Hales

bootrec /fixmbr does fix the deployed image, I am testing the fixed image by reuploading it and then deploying it.

Joseph Hales

Reuploading after running bootrec /fixmbr gives you a working image.

Tom Elliott

This is actually really good info. Joseph do you still have the “bad” image?

Windows 7 image boots to blank screen after deployment

170

12.0k

17.3k

155.2k