I should have known that. Thanks it fixed that issue.

Because of potential dangers that could happen while in debug we’ve removed this as a standard selection model. There two methods to still get debug though. First is to schedule a task as simply debug. This is probably easiest. Second method is to enable hidden menu and choose which key sequence you want to get back to menu. At boot it will ask for this key sequence. After pressing that key sequence you will receive a login prompt. Type in a valid fog GUI login and pass and it will display the menu with debug as we are all so used to. Hope this helps.

Just an update: We found that if we pull the AC power and the Network cable. Then plug back in, all works fine.

Thank you Tom, I will try and do that and see if I can get it by adding more CPU’s and more Memory.

Fog: 0.32
Os : ubuntu 12.04
-And the image that i’m capturing is have a free installed windows 7
-and i already installed tweak and apps that i needed

the size of my harddisk is 500Gb
-the total used on my hdd is 30Gb

When i always uploading image into my fog server the size of image is very large 190GB comparing on clonezilla 20GB+

Thanks sir Tom for helping me.

No success Tom. All of the Surface Pros have SSDs so I think those parts of the error logs are because the OS boots up immediately and the network devices lag behind.

I’ve seem to narrowed it down to the FOG client having a problem working in Windows 8.1 64 bit. I just tested the same thing with the FOG server and it works fine in Windows 7 32 bit. Even running the client as admin and in compatibility mode doesn’t fix the printer manager service is disabled issue.

[quote=“Bill Hasker, post: 30415, member: 24313”]Thanks Jaymes : I found the problem when I entered the time zone I didn’t notice It was also commented out . I did a clean install of 1310 Ubuntu and used 1.1.1 . My multicast still doe’s not work ,still hangs at partclone . What am I missing . the log says Task (18) Multicast group Quick deploy is no longer running .[/quote]

Try the latest revision, Tom has made some changes that have finally fixed some of the multicast issues.

[quote=“Tom Elliott, post: 30393, member: 7271”]Based on this is 192.168.1.1 the appropriate DNS Server for your setup?[/quote]

Yes

[quote=“Tom Elliott, post: 30393, member: 7271”]
Is this DNS Server a forwarder or just the DNS Masked from your router?[/quote]

I think it is just the DNS Masked from my router.

[quote=“Tom Elliott, post: 30393, member: 7271”]
Typically 192.168.1.1 is the Gateway address for home routers. This same gateway also translates to your ISP’s DNS Servers, or the DNS Server’s you’ve put in place to override your ISP’s DNS server. Why is this important to know? Most typically, the “Masking” of the DNS to your router’s gate is done via DNSMasq, the same protocol you’re trying to use to PXE boot your servers.

With that said, you could try commenting out the:
[code]port=0[/code]

You do this by making it:
[code]#port=0[/code]

Then restart the dnsmasq service.
[/quote]

This solved the problem.

Thank you very much!
Tob

Please see the following issue with possible fix for this issue.

This is being posted so all can try and see if this helps.

[url]https://github.com/mastacontrola/fogproject/issues/1[/url]

Thank you Tom for looking into it. I’ll update as soon as I can figure out why the database schema does not update … 😞 … see separate post here:

[url]http://fogproject.org/forum/threads/fog-error-access-web.10812/#post-30283[/url]

sorted thank you

Yep, noticed that when I edited the original post - back up and running though. I’m still not sure what’s causing the issue with the 4530s. 4520s and 4540s work perfectly.

I’ll just use a USB until I can figure out what’s causing it -

Rob

Try to ssh into your stroage nodes using the same username and password for the storage node in Storage Management --> <select node>–> [FONT=Ubuntu][COLOR=#555555]Management Username & [/COLOR][/FONT][FONT=Ubuntu][COLOR=#555555]Management Password. [/COLOR][/FONT]This will confirm that the password info is correct. As a reminder certain browsers will prefill info so make sure to disable prefill for your browser when looking at this information.

Well, you led me to the solution!

We have four different storage groups with their respective master nodes. In our ‘main’ group, we were retiring our server “fog1” and replacing it with “fog2.” Last night, I made the switch: I disabled “fog1” from master and set “fog2” to master on the ‘main’ group.

The issue wasn’t with those settings, but “fog2” still had “max clients” set to 0. Setting this to 10 fixed the issue. I had only looked at the configuration summary – which looked fine to me! (master node set correctly).

Thanks!

correct

Hi Tom,

Thanks for that! Adding the password to the correct config.php file was the ticket! I was able to do the schema update with only this (hopefully inconsequential) error:
[CODE]The following errors occured
Update ID: 36 - 5

Database Error:

Duplicate entry ‘400-28’ for key ‘gmHostID’
Database SQL:

ALTER TABLE fog.groupMembers ADD UNIQUE ( gmHostID, gmGroupID )[/CODE]

Thanks again!

Jeff

[COLOR=#555555] [/COLOR]

It was actually our image that was busted, so we’re good with imaging with multicast now! Sorry for the confusion, updating fog somehow made the image break.

I had a go on my failing system today, when I rename run.php to something else I get the problem back, i.e. no options for capone.
I’ve tried clearing the browser cache, on both Firefox on the server and ie8 on xp, and it makes no difference.
My home system is fine, I’ll try building a new one and see if I can reproduce the problem.

Just the one time, because you will upload this “now good” image and push that to your other hosts.

That’s correct, unless you tell it to image in raw format.