Ok guys : it’s solved!!!

The issue was due to the chipset selection…
I finally tried on a default VM hosted on an Ubuntu for testing (maybe it was the virtualbox /windows version causing the issue) and it launched the fog pxe environment.
So I changed to the same settings on my windows host and that was fine…

I hope it would help if someone has the same situation.

Thank you all!!

I installed the last stable version of fog (1.3.5) and find it awesome: the improvements since the 0.32 are really great!!

I don’t know (and don’t want) to make software developement but I’d like to help about french translation (if you need it) when my windiws 10 migration will be done. Tell/contact me if you want 🙂

Thread solved.

Found the issue.

The maxClients field was being scanned for. This only allowed a “maxClients” of between 1 and 9999. The idea for this range was to get nodes that were not set to 0 max clients. I was trying to make the sql handle the return, but this would imply some form of array to search for. I just moved the check to look if it is less than 1.

Here is an better pic… Yes I will update tonight.!

0_1490310548304_rsz_20170321_135330 (1).jpg

@george1421 I think we can mark this as solved. This conditional test works very well. I ended up using the MAC address for this and then creating a separate menu for each iso.
Example: In fog.local parameters
iseq ${net0/mac} f4:4d:30:65:23:94 && goto fog.Ubuntu-16 ||
iseq ${net0/mac} 00:30:1b:82:d2:d2 && goto fog.Gparted ||

Thanks,
Scott

@oraniko sweet. See just a little knowledge (where to look) grants great power.

We keep “scheduled” tasks listed so you have a sort of record of actions and their “activity” from a scheduled standpoint.

@george1421 I have ran this like before start installation. mount -o remount,exec /tmp

@dloudon96 said in FOG_1.3.4 - Image location issue:

/images/dev/00232497514f:

If you see files in /images/dev after the upload is completed [ /images/dev/00232497514f: ] then you have an FTP issue. I outlined the steps to fix this just yesterday in another post. https://forums.fogproject.org/topic/9755/storage-management-not-showing-my-images/12

There is also a wiki page for helping sort out FTP error messages: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

My bet during upload you were getting either an ftp authentication error (as in the picture in the link I referenced first) or a database update error. Both are related to the linux fog user account being out of sync with the FOG management gui.

@oraniko When a snapin or snapinpack runs forever, usually this means it’s waiting for input. And snapins are not allowed to receive input, nor interact with the end-user in any way.

So, to troubleshoot, Step back and start without even involving fog. Unzip all these files to somewhere - open an elevated command prompt, cd to the directory and run setup.exe and see what happens. If it doesn’t “just go” without asking for any input whatsoever - then it needs work. Once you have it “just going” without any help, take that work and those commands and make a snapin or snapinpack with them. The links I posted below are full of resources & ideas.

Hi,

try this style:

FOR /F "tokens=4 skip=3" %%i IN ('REG QUERY "HKLM\Software\Firma\Produkt" /ve') DO SET Pfad=%%i```

@Jaymes-Driver thanks mate

@Tom-Elliott

Your command has changed something.
Now, it runs “single snapin” only on the host that have it added (it means only 1).
Is this normal ? lol

edit : Found out, with Thomas, that I have to associate this snapin to each host to create a working task for every host using group single snapin task.

This works now. Thanks All.

@cleric.marcos You’re more than welcome. I do want to say I did very little to help anything here. I think @george1421 deserves more of the kudo’s here than I do.

Juste une légère correction, tout fonctionne jusqu’à ce que j’essaie de télécharger le noyau mis à jour, puis je reçois la même erreur que rdaval3.

Aucune erreur n’a été signalée dans le journal des erreurs apache.

English:
Just a slight correction, everything works until I try to download the updated kernel, then I get the same error as rdaval3.

There is no error posted in the apache error log.

@george1421
Thanks a alot 🙂
that works now

@BardWood If you still have the original backup file from when you upgraded the server originally, this would be your best bet. It should be in /home/fogDBbackups

It typically is time stamped.

Once you reinstall 1.2.0, you’ll need to use the backup sql file to restore it as a lot changed in the DB between the two.

Also remember, with the exception of WOL, Shutdown and Restart “on demand” Power Management items are not “immediate”. As @Junkhacker stated, they require the New FOG Client on the systems to be “tasked” and they will be performed on the next time the check in with the FOG Server.