Windows 7 image boots to blank screen after deployment
-
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=“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… -
Hi
I have the same problem with fog 1.1.2 and dell 780 with single partition
Is there a solution ?
Thanks
-
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.
-
Same problem here on Lenovo desktop and laptop products.
-
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
-
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/loop0Then 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.xzHope 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)
-
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.
-
bootrec /fixmbr does fix the deployed image, I am testing the fixed image by reuploading it and then deploying it.
-
Reuploading after running bootrec /fixmbr gives you a working image.
-
This is actually really good info. Joseph do you still have the “bad” image?
-
Actually no but I may update two similar models soon if it reoccurs what would you like me to do.
