personally, i would recommend using a folder such as /var/www/html/ISO because this folder will not be touched in fog upgrades, but the /var/www/html/fog/service/ipxe/ folder will be moved

[quote=“Fhajad, post: 31428, member: 24675”]You’re not supposed to use pxelinux.0 anymore, you’re supposed to use [B][COLOR=#000000][FONT=sans-serif]undionly.kpxe[/FONT][/COLOR][/B][COLOR=#000000]. You’ll need to update that in your DHCP option settings.[/COLOR][/quote]

This just solved my issue.
Just upgraded from 0.32 to 1.1.2 and TFTP was all “no way Aieesha, I aint no doin dat!”

Changed the DHCP server options (that i had setup ages ago for .032) and BAMO AIEESHA…

Thats right, all you would need to change is “bootfile pxelinux.0” to “bootfile undionly.kpxe”.

As for which version I would recommend 1.2 personally, I switched our systems about a month ago and the changes have all been positive for me: I found the linux handling is vastly improved and iPXE seems much more flexible. The front page of the wiki ([url]http://fogproject.org/wiki/index.php/Main_Page[/url]) has a summary of some of the more important changes.

Incidentally when I put up my fog server I also thought I wouldn’t be using it a lot, but I ended up using it ways I wasn’t expecting (system rescue, “backing up” or migrating hardware), I leave it up all the time now 🙂

I re-uploaded the image as a Single Disk (NTFS Only). and now I can download the image to similar hardware.

I just verified that the .mntcheck exists in both of those directories, and I changed the permission on the images folder on the NAS (labeled fimages) with the following command:
[CODE]chmod -R 777 fimages[/CODE]
Still receiving the same error.

Hi,

[quote=“Tom Elliott, post: 32893, member: 7271”]Normal method of update is download the new file and extract and go to bin/ and rerun installfog.sh[/quote]

i downloaded svn 2040 did a installfog.sh rerun and after that i hang in this:
[IMG]http://i.imgur.com/RqUK3tg.png[/IMG]

the db schema updater page is just empty
[url]http://fogip/fog/management[/url] always redirects to aboves empty page.

EDIT:

Same issue after db drop an reinstall, hmm.

Regards X23

No, there is a “funny” bug once in a while I’m aware of, but don’t remember exactly when I fixed it. It should be fine in SVN though.

Hi,

why isn’t the project driving your recommendations? grrr 😉
i really want to have fog this time running well i tried a first run with 0.32 and was working hard on it but in the end it was useless for our business. This will be the second run i want fog so hardly for a nice automated backup of workstations.

Regards X23

Good luck!

I do not know any more how BOOT my ISO about the server FOG

sorry i didn’t make it very clear - this is what i meant, i’m using a port say :25280 but doing an internal rewrite (so u don’t have to specify port in web address) but ALL traffic fitting the pattern for fog gets directed to apache/fog box using the port:25280 and have no issues… with ur port-translation it seems the initial traffic i.e. /fog/ is going to apache but further traffic is not… try looking into apache config, also check logs they will give u a clue with what is wrong and whether apache is seeing the request. like tom said it is environment/routing issues not fog gui, fog gui doesn’t care what port it’s ur apache doing the listening 🙂 u could test the theory by getting apache to listen on 25280

junkhacker’s avatar is actually a live feed of his expression…

update

I’m noticing some bizarre activity troubleshooting this fog box, going to reinstall fog and post results.

so the plugin should be an msi

snap-in run with should be c:\windows\system32\msiexec.exe
snap-in run with Argument /i
snap-in file blahblahblah.msi
anp-in arguments /qn

this works for me… I use smart packager discovery for every little thing i want to change pulled from a vm deployed specifically to grab changes i want done.

works great.

You can grant and rerun with the new settings, just place them in the .fogsettings.

i deleted another image and rebooted the server and ITS WORKING!!!

YAY!

The problem was that this was an AIO motherboard and it was trying to use a built in display.
[url]http://www.intel.com/support/motherboards/desktop/sb/CS-033024.htm[/url]

[quote=“RLane, post: 32598, member: 23505”]In previous versions of FOG, there was a limit (10 by default) where when you multicast for active PCs. Now, using 1.1.2, is that setting or default changed? I had a group with 32 computers in a lab and started them today assuming only specified number (figured 10 as default) would start, but all of them started. Sadly I have 10/100 switches to the class rooms and a Gb backbone. Has this changed or am I just missing the setting?

I figured something like this would be displayed when I started my multicast:

[url]http://www.fogproject.org/wiki/images/3/3d/Queue.jpg[/url]

Edit: I guess reading the wiki further states this was only for [I]ten[/I] unicast tasks, but multicast is considered one task itself. Is there a way to break the multicast down into parts other than making a separate group? I don’t know why 32 multicasts would be significantly slower than 8.[/quote]

Sounds like you figured it out there towards the end, Unicast has a limit to how many machines can be imaged at once, it can be increased or decreased by modifying the configuration settings.

As far as Multicast goes, your best bet is to start a group and name is Session1, Session2, etc. and put 10 or 12 machines in there and run the multicast for the group.

Unfortunately at the moment there are no ways to break down a multitask imaging task any further, but it may be something we will look into in the future.

Personally, I prefer to unicast to multiple machines at once, as you stated there is already a 10 client limit, and you can set up multiple machines to image and when a space opens in the queue it will fill it otherwise it will wait. This may be a little more beneficial to you than multicasting since you seem to want your machines to wait their turn so not to bog down the network, I’ve had multicast hurt me more times than it has helped.

If you want to use the Queue you need to use Unicast. Multicast makes sure all hosts are on the same “checkpoint” before proceeding and does not rely on the Queue.