@Trevelyan Yes, I just restarted it to test, and it came right back up and I was able to login. So it looks good so far! Thanks for trying to help so much btw, I really appreciate it.

There might be relevant parts in that article, but it was last updated in 2011.

I should re-write it… I’ll put it on my to-do list (I actually have a to-do list here).

If you can get another HDD in, format it, mount it, etc, you could simply add a new storage node and point the path to your new HDD. Set your permissions on that new directory as 777 and it ought to work.

Firstly, please check back to this thread because a developer might provide a solution.

So, normally, when a client “exits” from the FOG PXE environment (when it sees that there are no tasks waiting for it), it can hand off control to the local system in three different styles, all of which assume booting from the local HDD.

See picture:

ExitToHardDriveType.png

Somehow, one of those (or add a new one?) will need to be modified to detect if said system needs to boot to the HDD or to the network. Because currently all of those point to the local HDD.

Chainloading to the appropriate boot-file will be involved for the systems that need to boot to network.

The Advanced Configuration Options will likely need to be used to accomplish this:

advancedconfigoptions.png

I’m not sure how that’d be accomplished.

@techpromise said:

Thanks for the help guys, I decided to manually add the images back in as the SQL dump carried over some errors from the old system.

How do I mark this as solved?

Ask us and we will oblige.

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”.