I get that, Wayne, and I don’t think that’s harsh. I should have commented on your suggestion. Better late than never: The weird thing I saw was when I did a download with debug, and then ran fdisk was I only saw one partition. I didn’t really understand that and still getting my feet wet with FOG decided to revert back to a snapshot before going any further. I really do appreciate the help and knowledge you guys have, I would be sunk without your help!! Thanks again. I’m going to try upgrading to the latest Trunk version and see what happens. Thanks!

For the Windows 7 machines try going into image management and change your image type to multiple partition image single disk. I had this same issue today and found that this fixed it.

@Vickie-Osbornr said:

Asus X200M

Are we working with this one?

Here is what I have set currently. menu.png
Maybe it would be simpler to add a check box to add these to the advanced menu amd then check the login box there.

@Wayne-Workman said:

It allows you to choose exactly what partitions you want to upload when you capture your image. I always choose “everything”, but there is probably a use for the others.

Thanks Wayne, i chose that one too.

I’m using fog 1.2.0, i’ve changed the date.timezone and now seems to schedule correctly, i can’t schedule for dates in the past.

anyway when i start the client the download doesn’t start, the fog menu appears… 😞

boot.php issues have been solved. Problems lie elsewhere.

vmxnet3 -> ipxe.pxe -> 100%, imaging, rebooting to windows without being stuck
82574L -> undionly.kpxe.INTEL -> 100%, imaging, rebooting to windows without being stuck
i217LM -> undionly.kpxe.INTEL -> 100%, imaging, rebooting to windows without being stuck
Realtek -> undionly.kpxe.INTEL -> 90%, imaging, rebooting to windows without being stuck - doesn’t seem to run all that smooth, but that may be due to Realtek being crappy.
ipxe.org/040ee119 is listed as error handler, which points to missing DHCP configuration - it just needs 3 tries it seems, also DHCP isn’t all that fast before PXE is even loaded.
11262255_834812966611489_1190040555_n.jpg
^ and somehow it started imaging after a few seconds. shrug

I think the undionly.kpxe file is somewhat broken. I’ll set up another ubuntu box, install FOG on there and copy over all the things to the production system.

@Joseph-Hales said:

As I understand it 4 things need to match the Operating system password for the fog user, the storage management password and username fog, the tftp password under the web ui in fog settings and finally the storageftpuser / storageftppassword in the /opt/fog/.fogsettings file. After they all match restart the fog services or just reboot the server.

#credentials

Been meaning to make a list anyways…

We’re not using the new client yet I upgraded to SVN 3463 this morning which fixed the missing client issue.

Please examine this:
https://wiki.fogproject.org/wiki/index.php/Known_FOG_Bugs#The_Image_Resize_Bug

I think you may be affected.

Please examine this:
https://wiki.fogproject.org/wiki/index.php/Known_FOG_Bugs#The_Image_Resize_Bug

I think you’re affected.

@Tom Elliott : Many thanks for your answer.
Now, i will use my brain and think if multicast is really necessary …
In french, a proveb say : “Le mieux est l’ennemi du bien”.

In few days, i will discuss with my collegue of the situation and we will choose a good decision about that.

PS : Learn guitar is hard but it’s a very cool hobbie 🙂

Thanks Wayne!

Thanks for the starting place. I was just gonna experiment when I got home tonight.

If you’ve changed your IP address, there are a number of files you need to change.

/var/www/fog/lib/fog/Config.class.php use "grep -r <old fog server ip> /var/www/fog/lib/fog/ " and find any references you missed there /tftpboot/default.ipxe /etc/hosts /etc/dnsmasq.d/ltsp.conf /etc/network/interfaces

Full list is here

https://wiki.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address

@Seydoo said:

My problem is solve, due to a bad password (user fog on linux with not the same password than fog tftp user)
tanks to ch3i for his help

The problem was that you have a password policy that does not accept the password “password”.

Now in the WiKi under Troubleshoot FTP.

https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP#You_must_first_upload_an_image_to_create_a_download_task

Thank you Tom for pointing in the right direction. There was one more place that the password needed to be change.
The second location is under:
Storage Management >> DefaultMemeber >> Management Password.
After changing the password and submitting the changes; it seems that it is back online.

Thank you so much!!!

Awesome, thanks I am up and running again. Glad it wasn’t something I did.

Chatted and found out the problem.

This was a two part problem.

Problem number one.

Location Plugin was installed, but no entries were made. I don’t know yet if there’s a bug specifically in this, but there was a location association at one point in time. This lost its association but made it so the default location was not set. This is why the http:///fog/service/ipxe/bzImage was display.

Problem number two.

The FOG Configuration->FOG Settings->TFTP Server->FOG_TFTP_PXE_KERNEL setting was literally set to /bzImage instead of bzImage

Any of the files being stated should not have a beginning precursor as such.

Hopefully we’ve helped out and helped figure out other means to troubleshoot.