If you enter Audit mode and intend to sysprep, you can make all the changes you need. Then before running the sysprep command, you can upload the image to the Fog server and keep it safe and use it as a “back up” in case you need to revert to a point before you ran the generalize command.

A better solution is to build the image virtually and use snapshots and revert that way.

Either way, you will be able to make a back up before using the generalize command.

I only recommend using the skip re-arm when you are learning to set up your unattend.xml file. But then again using a snapshot, or keeping a back up on the fog server would also negate the need to skip re-arm.

Hope this helps!

Just make sure you don’t upload over top of the “Before” image O.O

are you using a multi partition single image? it shouldn’t expand on it’s own

Ok, well after setting up the computer back up, all is well and working like it is supposed to.

[quote=“Bcundiff, post: 31717, member: 22232”]This is where sysprep can be useful-- we use a master image with a ~40GB Windows install partition and then use ExtendOSPartiiton in the answer file to extend the C:\ drive to fill the remaining space in whatever drive the image is deployed to. The same answer file can also be used to make partitions, but that seems a bit riskier.
Sysprep’s generalize flag could also help with other hardware issues-- I’ve spent a few months working with Fog 0.32, Ubuntu 12.04, and W7 Pro x64 clients, and I’ve been able to get away without sysprep on occasion while testing, but, in my experience, sysprep /generalize really helped us deal with varying hardware, including things as trivial as getting an image from a 120GB drive to a 128GB drive.[/quote]

Hi, and thanks for your input.

I started to “play” with creating an image and sysprep last week.

I followed these instructions:
[url]http://fogproject.org/forum/threads/windows-7-deployment-fog-sad2-driver-tool.380/[/url]

and did this on a virtual box.

It went fine until “Step 8” (Drivers- SAD2). I did the suggestion at the end of Step 8 which says “you might want to try the tool out manually”. I did this and it updated a lot of drivers in the image on the virtual box. When it was all done, my network adapter was gone (i.e. without a driver) and several other critical path components too. I didn’t have more time to play with this, so I wiped it out and got a fresh image.

Do you follow these same procedures? Has this situation with drivers ever happened to you?

[quote=“Matt Harding, post: 8912, member: 1207”]If anyone is interested, I’ve put together a snapin to change the resolution on a PC. It uses 12noon’s Display Changer which is free for personal and educational use. I’m happy to share the information with anyone needing a windows 7 solution.[/quote]

I am interested in this snap-in. I am using Fog v.32.

How can I get this?

[quote=“Bronzli, post: 28203, member: 24373”]Hello,
I’ve just upgrade my fog server to 1.0.1 and have problème to boot the host under pxe!!!
few informations :
ubuntu 12.04 ; fog 1.0.1
service tftpd-hpa running
my fog config.php :
…
[/quote]

I run Fog under the same version of Ubuntu as you and in the past I have had PXE boot issues. I don’t remember exactly what all the symptoms were, but over time I have come up with this two line script and I just run this every time, first thing, after I reboot the Fog server… since I started this practice…never had any problems again:

sudo this file

start isc-dhcp-server
restart tftpd-hpa

Oddly enough, this problem fixed itself. All of the workstations are working just the way they are supposed to, no errors, images deployed just peachy. Going to chalk this one up to gremlins.

awesome, thanks i’ll try that!

Can you try these steps:
[url]http://fogproject.org/forum/threads/ipxe-issues-work-around.10727/[/url]

[quote=“astrouga, post: 8526, member: 907”]BTW, the solution ullawolf1 suggested works really well:

"So tftpd-hpa starts “to early”. You can fix this by editing the /etc/rc.local and add the line

[CODE]/bin/sleep 30 && /etc/init.d/tftpd-hpa restart[/CODE]

to restart the daemon after 30 seconds."

The thread is here:
[U][SIZE=2][COLOR=#0060e0][url]http://fogproject.org/forum/threads/tftp-stops-on-reboot-after-install.488/#post-5353[/url][/COLOR][/SIZE][/U]

[SIZE=2]astrouga[/SIZE][/quote]

Just wanted to add that I needed this fix on clean install of Debian 7.5 and fog 1.1.0 to get the TFTP server talking to my clients.

[quote=“need2, post: 27785, member: 21891”]I’ll look about some more.[/quote]
Thanks a heap for the assistance mate.

[quote=“Tom Elliott, post: 27440, member: 7271”]svn 1709 should address that error as well as remove mysql_ functions and use the $this->DB calls for database purely where needed.[/quote]

Nice, upgraded to revision 1710 and everything works now. So far.
Thx.

Hi Tom,

Thank you very much for your answer. I will try to answer your questions. I did not have to much time to debug this situation.

“Does the table recognize GPT information?”
Yes.
“Does the d1.mbr file size equal 32256 bytes or 512 bytes?”
The size of d1.mbr is 17920.
I restored it with sgdisk but something strange happened. Just to be sure that everything is ok, I did a sgdisk -Z /dev/sda first to delete the GPT and MBR tables. Then I did a restore using sgdisk -l /images/d1.mbr /dev/sda. When I did a gdisk -l /dev/sda it showed no partitions. A read on a forum that before you restore you have to issue sgdisk -G /dev/sda. Apparently this command “Randomizes the disk’s GUID and all partitions’ unique GUIDs (but not their partition type code GUIDs). This function may be used after cloning a disk in order to render all GUIDs once again unique”. After I issued this command and did a restore again, all partitions were created on /dev/sda.

When I have a little more time I will continue debugging and post the results.

Thank you for your time.

Bogdan

We had issues on the 740s as well with fog .32. Before we had to leave the computers on bios version 1.1.3 and use a specific kernel. I don’t remember exactly which one but now that we are on fog 1.0 it doesn’t seem to matter for the kernel. I haven’t tried with an updated bios yet.

I didn’t set that up, it’s just the way the network administrators set it up at the university many years ago before I was even here.

But, it looks like none of that matters now. After updating FOG to the most recent update it magically works the way it is. Because someone, most likely Tom Elliott, is a super hero magician server fixing machine and did something in the most recent commit that fixed my problem.

Now onto my subnet and snapin adventures.

Thanks for all the help 🙂

-JJ

[quote=“Tom Elliott, post: 26107, member: 7271”]Don’t setup as JUST ME, install for everyone.[/quote]
That seems to have done it. Thank you very much. I swear that the last district I was in had this installed for Just Me, but I am content with this solution for the time being. Thank you.

David,

Also be cognisant of the kernel. I know my kernel’s don’t always work on All lenovo’s but there is a kernel floating around the forums here that seems to work well for troublesome kernels. As BPSTravis states, also verify the Drives are in MBR if you’re using 0.32. This does require a little extra work on your part, but ultimately will help you in the long run.

Finally, my problem to deploying came from network Access control list.
Thanxs for your help. 😉

Hi Danvaida,

Any good news on this.

I am facing the same issue with Lenovo L440o_O