Added a new storage and still the same display.

[ATTACH]1115[/ATTACH]

Hardware Information

General Information
Storage Node VaubanVieux
IP 10.121.84.7
Kernel 2.6.32-31-generic
Hostname fog0210003P
Uptime 15:53:13 up 1 day, 7:04, 0 users, load average: 0.16, 0.13, 0.05
CPU Type GenuineIntel
CPU Count 1
CPU Model Intel® Xeon® CPU E5-2620 0 @ 2.00GHz
CPU Speed 1995.192
CPU Cache 15360 KB
Total Memory 497
Used Memory 146
Free Memory 350
File System Information
Total Disk Space 196.8 GB
Used Disk Space 89.4 GB
Network Information
lo Information
lo TX 14.93 KiB
lo RX 14.93 KiB
lo Errors 0
lo Dropped 0
eth3 Information
eth3 TX 10.8 MiB
eth3 RX 7.61 MiB
eth3 Errors 0
eth3 Dropped 0

[url=“/_imported_xf_attachments/1/1115_Sans titre.jpg?:”]Sans titre.jpg[/url]

Just to update you, I have just tested updating the image in fog 1.1.2 which uses part clone to capture and the progress bar is now working. 😉

[quote=“RLane, post: 32372, member: 23505”]After hours of troubleshooting, I really feel like a moron. We established the problem being a core switch/VLAN issue. Existing VLANs when I inherited the environment had ‘ip multicast-routing’ enabled - right… but when I added new VLANs, consequently the “Server” VLAN, I didn’t re-add ‘ip pim sparse-dense-mode’ and ‘ip cgmp’ commands to get the multicasts on the same broadcast. Disappointing I spent a good week on this but didn’t check it. Thanks Tom for the help – obviously not a FOG issue. Worked fantastic afterwards.[/quote]

I tried saying it all, and I’m sorry I couldn’t help any further. I tried all of my knowledge and it felt/sounded like environment. I appreciate the feedback though thank you.

[quote=“Ronny Olsen, post: 32296, member: 18879”]As I said in the first post, it is enabled on the fog client.
I have all services enabled on the client, and on the registered host.
And disable things globally if I don’t need it.
But thanks for the reply 😃

But I have an update. It seems like it is working if I disable/enable the service.
So I added a startup-bat that does this, but it still seems like some kind of a bug.
It has only happened on this Optiplex 7010 with Windows Ent. (Could be a windows update, I will test this on an other model with latest updates).[/quote]

Have you tried adjusting the service to “Automatic (Delayed)”?

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.