i’m guessing that something is blocking the client from communicating with the fog server, then. perhaps they are only allowed to communicate with web services when people are logged in? firewall, or network authentication issues perhaps?

Well, I did a “mysqlcheck -o” and will be keeping an eye on things.

Just to update with the solution. I downloaded 1.1.2 files again and than I ran 1.1.2 setup again; nothing more and now it works, thank you for pointing me in the right direction.

I’m having the same issue with the new Intel NUC Kit, they seem to have put in a different mainboard. The NUC’s manufactured in 01/14 worked flawless, while the newer series from 05/14 has some kinks (only accepts 1.35V RAM or 1333MHz 1.5V anything below and it doesn’t even start).
Anyway, they get stuck on “iPXE initialising devices…”. I’ve already tried every file from the /tftboot folder, no luck so far.
Maybe Mike has more luck.

P.S. I’m on 1.1.2

Thank you for quick response.
So will be this old pxe menu still available ?
It’s very important for me.
I’m using it in my company and it’s much easier to use this menu instead setting up everything through the web interface.
I’m asking because is not completely clear how this new menu works.
For now i got main menu
example:
IBM
DELL
HP
Other
so when you choose a brand (HP) will appear the list of available images:
DC7600
DC7700
etc.
and scrolling up/down you can choose exact image for machine you intending to imaging.
This is most important for me.
Of course you know how it works 🙂
Anyway i’ll check everything after the weekend.
I have no access to the server atm.

Yes i “Run as administrators” when i install the client

I’m having the same problem on Ubuntu 12.04

I find out that i had to put the main node in first in exports file and not second.
Since it’s the same datastore, it will use the first it an access.

Worked! You guys rocks! thanks !!

[quote=“darKpoiSon, post: 31800, member: 24148”]I just successfully compiled my Fog Service. I had trouble when still on 0.32 using newer Versions of Visual Studio, including 2010 and 2013, try to find a Visual Studio 2008 to compile it.[/quote]

That did the trick! Thanks for the quick update.

1996 has this field now.

I started 1 task for whole group (around 80 clients) and it ended up with 4 (and second time with 5) tasks with the same number of udp-sender processes, logs etc. The tasks had variable number of clients (around 20 in average)…
Last time it ended in a mess - made few tasks (I think 3 or 4) and then it couldn’t find clients or what:

[CODE]
[07-02-14 1:59:50 pm] | Task (20) cpu is new!
[07-02-14 1:59:50 pm] | Task (20) /images/cpunew image file found.
[07-02-14 1:59:50 pm] | Task (20) cpu failed to execute, no clients are included!
[07-02-14 2:00:00 pm] | Task (15) cpu is already running PID 19255
[07-02-14 2:00:00 pm] | Task (16) cpu is already running PID 19448
[07-02-14 2:00:01 pm] | Task (17) cpu is already running PID 19639
[07-02-14 2:00:01 pm] | Task (18) cpu is already running PID 19831
[07-02-14 2:00:01 pm] | Task (19) cpu is already running PID 20015
[07-02-14 2:00:01 pm] | Task (20) cpu is new!
[07-02-14 2:00:01 pm] | Task (20) /images/cpunew image file found.
[07-02-14 2:00:01 pm] | Task (20) 1 client(s) found.
[07-02-14 2:00:01 pm] | Task (20) cpu sending on base port: 62908
[07-02-14 2:00:01 pm] CMD: cat “/images/cpunew/d1p1.img”|/usr/local/sbin/udp-sender --min-receivers 1 --portbase 62908 --interface eth1.212 --full-duplex --ttl 32 --nokbd;cat “/images/cpunew/d1p2.img”|/usr/local/sbin/udp-sender --min-receivers 1 --portbase 62908 --interface eth1.212 --full-duplex --ttl 32 --nokbd;
[07-02-14 2:00:01 pm] | Task (20) cpu has started.
[/CODE]

I don’t know what went wrong - I was testing change of multicast interface, so was changing interface, creating task, looking if it works, killing the task few times until this mess… then I just restarted server, because everything was too slow (which I observe since upgrade to 1.1.1, but I’m not sure if the problem is in FOG or my server)… strange things :)… maybe the creating and killing of tasks made a bit mess in the database or what…

BTW: is this ok? (it’s from code excerpt above):

[CODE]
[07-02-14 2:00:00 pm] | Task (15) cpu is already running PID 19255
[07-02-14 2:00:00 pm] | Task (16) cpu is already running PID 19448
[07-02-14 2:00:01 pm] | Task (17) cpu is already running PID 19639
[07-02-14 2:00:01 pm] | Task (18) cpu is already running PID 19831
[07-02-14 2:00:01 pm] | Task (19) cpu is already running PID 20015
[/CODE]

Okay, I did something dumb, but learned something new…

In XUbuntu the password for the actual Linux user fog does not create/synchronize - This can be found under Storage Management, Default Member, Management Password - this should be the actual GUI login password for user fog in the Linux OS.

This password is randomly generated, and inserted in this field, and can be used to log in as user fog, although I’ve almost never need to do that. Instead of just changing the Linux login password to the randomly generated password found on the Web UI, Storage Management, Default Member, Management Password (which would have been smarter) I just changed this field to a common administrator password. I then made this common administrator password the actual login password for user fog on the Linux installation, and this issue is solved…

Just thought that I would post what happened,
D.L.

I probably should have described it better, but it sits at the “Starting to restore image screen” and the multicast task never actually begins, as described in this thread :
[url]http://fogproject.org/forum/threads/fog-1-1-0-multicast-sits-at-starting-to-restore-image-to-device-dev-sda1.10782/page-2#post-31993[/url]

Also (or as a result of this) in /opt/fog/log FOG version 1.1.2 does not create the multicast.udpcast.1.log (approximate file name) file, nor does it create any entries in the multicast.log file. Since I was confused by this I pulled up an old .32 installation - in .32 it has the same behavior, however it does make entries in the multicast.log to at least let you know what is going on:

[07-01-14 9:54:10 am] * Starting FOG Multicast Manager Service
[07-01-14 9:54:15 am] * [07-01-14 9:54:15 am] Checking for new tasks every 10 seconds.
[07-01-14 9:54:15 am] * [07-01-14 9:54:15 am] Starting service loop.
[07-01-14 9:54:15 am] | [07-01-14 9:54:15 am] Failed to connect to database server, will try again in next iteration.
[07-01-14 9:54:25 am] | [07-01-14 9:54:25 am] Failed to connect to database server, will try again in next iteration.
[07-01-14 9:54:35 am] | [07-01-14 9:54:35 am] Failed to connect to database server, will try again in next iteration.

And yeah, on one test installation I did create a password for the root user. I’ve checked in Config.class.php in /var/www/html/fog/lib/fog and it is correct and I’ve also verified it by running mysql -u root -p and entering the correct password. This test installation will not multicast, and gets stuck as described above. On another test installation I used all of the same settings, and I did not enter a SQL password on installation - this box will start multicast tasks…

Thanks Tom, you’re the man,
D.L.

Add to that a little,

It just says next-server as you were describing, and only specifies you to edit the Options 66 & 67 on a windows DHCP. I didn’t add the “this is what you need where” until 0.33b and forward.

Hello again

I just write here because I found another problem that didn’t allowed me to join computers to the Domain just in case anyone needs it.

In our University all the computers are on the same VLAN with many DHCP Servers and that made that sometimes, not always, the DHCP Client didn’t assign us the correct DNS to be able to join computers to our domain. Finally we decidided to filter via firewall that our clients only can get IP from our DHCP Server.

Thanks for giving me some light to solve our problem and for this nice product.

See you soon

[quote=“Meitar Ronen, post: 32024, member: 24536”]I’ve tried that…
No matter what I did I got the “Fatal Error” error…[/quote]

In the future, I recommend using VirtualBox and making a snapshot of your image before you sysprep. I know this doesn’t solve the problem at hand, and I don’t really have nay recommendations, but this should help with future endeavors.

If you you by chance need to sysprep again, you can revert the image to the previous snapshot and make adjustments without affecting the re-arm attempts. I hope this will help you to sort your problems later.

Did the resizable upload fix the issue?

If not are you opposed to pushing the image to a hard drive large enough AND WITHOUT BOOTING IT, editing the partition tables with a live gParted CD? This would allow use to manipulate the data into thinking it is smaller and possibly load it to another machine.

Here are those lines:
[CODE] if (ini_get(‘date.timezone’))
date_default_timezone_set(date_default_timezone_get());
else
date_default_timezone_set(‘UTC’);[/CODE]

Bios is set to UTC. Should I change something in the lines above?
[CODE]# hwclock --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1404282060 seconds after 1969
Last calibration done at 1404282060 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick…
…got clock tick
Time read from Hardware Clock: 2014/07/02 06:47:09
Hw clock time : 2014/07/02 06:47:09 = 1404283629 seconds since 1969
Wed 02 Jul 2014 09:47:09 AM EEST -0.688132 seconds
[/CODE]

PC time is 09:47 now.

I also have [CODE]date.timezone = “Europe/Athens”[/CODE]

Thank you!

Edit: With
[CODE] if (ini_get(‘date.timezone’))
date_default_timezone_set(date_default_timezone_get());
else
date_default_timezone_set(‘localtime’);[/CODE] times are correct (but why are times correct since my hardware clock is set to utc? ). Is this setting correct? Should I leave it like this?

[quote=“Tom Elliott, post: 31923, member: 7271”]svn 1983 should fix this for you.[/quote]
Indeed it does.

Just wanted to make sure that it was known.

Thanks.