[quote=“David Durr, post: 20805, member: 17319”]Folks,

I have set up three fog nodes on separate subnets. The master is on subnet A with storage nodes on subnets B and C. All of them work. Images are being replicated and clients on each subnet boot from the local pxe server and images get installed.

However, I am noticing that sometimes clients on subnet C are installing images from the nodes on subnets A or B. I started a client image from subnet C this morning and it pulled its image from the node on subnet C. When I started a second client image on subnet C, it was pulling an image from the node on subnet A.

Perhaps this is a load balancing mechanism, but this is causing problems because the WAN connection subnet C and the other two subnets is slow. I need clients on subnet C to install images from the node on subnet C.

I imagined that all clients on subnet B would install images from the node on subnet B, all clients on subnet A would install images from the node on subnet A and so on.

Is this not the case or do I have something else going on?

Thanks for any help.[/quote]

BryceZ answered this. His solution has fixed my problem:

Without using the location patch, you can set FOG up to do what you want, but it gets a little ugly… Using one master Storage Group you add your remote Node to it, and create your master image pointing to the master Group, this way FOGSync will replicate the image between the master Node and the remote Node. Then you set up a remote Group and a second Node definition that matches the first remote Node except it uses the remote Group instead of the master Group. Then you set up a second image definition that matches the first image except it uses the remote Group. So now when you set up a host at the remote location you assign it to the remote image and it will only pull from the remote Group, and because the remote Node is in both Groups the image is just a copy of the image you first created on the master Group. Not the easiest setup, but it works.

Or my kernel:

[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]

TRK booting NOT on an iso requires NFS to send files across the network. After TRK boots, the startup script copies files over NFS. keep in mind that NFS is not like samba and requires a full path. Thats what tripped me up.

I found my issue. I did not select the SNAP from the Host menu. I read through the fog doc and reliazed that I was not attaching SNAP Image to the host. Once I did that, I was able to schedule the Task. I also upadted the BIOS time and host local time.

I like to add extra column in the Host list page. I like to add Primary User column in the Host list. How can I do it?

Thanks,

Newbie.

I don’t know what KACE is, but it seems a little odd that your machines are dropping their network resources randomly. I’d look into your Service Options on the FOG Page and check that there isn’t a task set for rebooting the machines. This could be under the Green FOG settings or Task Reboot. I don’t know which one it will be. However as you state it only seems to happen when the WIFI is enabled, I’d check that the primary address for the hosts is the LAN not WIFI. If it’s not these options, it’s highly unlikely it’s the FOG Client causing the issue, but seemingly an issue with the image itself.

I hope this is somewhat helpful in narrowing down the issue for you.

I can’t boot from network now … it dosen’t work.

Dekar, Try using this. [url]http://fogproject.org/forum/threads/win-7-image-upload-no-partitions-found.1130/#post-5714[/url]

All props go to Madeyem for this. This fixed my issue. I hope it fixes yours.

Madeyem:

That worked like a charm! Excellent find! I followed the instructions as posted and it worked. It’s uploading the image as I type. I just don’t understand how I can create an image on a HP Elitebook 8470/8570p and it uploads without issues. I do the same on the HP Pro 4300 and it gives me that error. Both machines were prepped the same way and started fresh from the Windows 7 Setup disc. Too weird. Glad to have it working now though. Thank you Thank you Thank you.

Right now, everything (including the .mntcheck files) under /images has been already chmoded to 777 and it’s owned by fog:root. [S]Should I try changing the ownership to apache:apache?[/S] Since it’s been chmoded to 777 it shouldn’t matter who owns the file right?

EDIT: Also, how are images stored in its final form? Do I have to create a folder named prova beforehand?

Dan, that is correct, when a unicast host requests the image it is sent to the machine and then decompressed at the level.

For multicast, the image is decompressed and sent in “sections” to the hosts. Each machine will wait for the others to catch up with the current “section” before they will move on to the next step. This causes a high load on your server, but it helps when you are imaging a large amount of computers that are the same model.

Yes it’s on the server.

Again,

The fact that after it’s done the task for the systems to do get registered, you can register the other hosts, tells me it’s a limitation of connections. Maybe some other limitation is occurring on the server, but something is stopping the connections to allow the registration to happen. I’m fairly sure it’s not a problem in a configuration of the FOG stuff, but I could be wrong.

Also,

Try increasing the connection limit to mysql from 100 to, for testing this, to 999 and see if you run into the same issue.

I say this because sometimes connections can happen that just fail, so the system will create a new connection. 100, when doing enmass of 30, is not very much considering the overall number of connections made.

interesting update.
Alternative laptop… carried out same procedure as above… new image, new name etc… uploading now???
confused
RRM

[quote=“Tom Elliott, post: 20134, member: 7271”]Are you running FOGPrep before uploading your images?[/quote]Yes! I am doing the exact same process that I do for all of my X86 images. I decided to try another computer to make sure that it was just not that certain model. I took my ultrabook that is 64 bit and tried to creat an image and I get the same thing so I know it is not those machines or that install of windows 7.

Thank you very much, Tom, and thanks for everybody who spent time on this discussion thread. It has been of immense assistance to us. My production fog is running 64 bit Ubuntu Server, but I’ll try your kernel on my test fog in Virtual Box. We will virtualize the fog server within 6 months time, so a testing of a redo of the fog configuration is ahead of us, just after Christmas. Anyway, I fixed the problem by using another computer, without a DVI graphic, to upload the image the image of the computer with the DVI interface.

[quote=“Hongyun, post: 20045, member: 1117”]Thank you for replying, but it’s not very clear in that post on how to use partclone, install it on FOG server or included it in bzImage file? Sorry, I’m not a programmer, really can’t understand the attached files in that post, would you mind to explain it in more detail for me?

Thanks![/quote]

I would be happy to help, but I have never loaded partclone. If you look, Gilou was the one that set up the partclone to use because he has problems with partimage… I on the other hand have no complaints and partclone works great in my environment, get in touch with Gilou, or let Tom figure it out. I prefer to learn to do things myself, and when I get to that bridge and cross it, I will make sure to document the process thoroughly, I was more or less providing a lead for your journey.

That was a quick response.

I followed this post:

[url]http://fogproject.org/wiki/index.php?title=Adding_Storage_to_a_FOG_Server[/url]

And that did the trick.

It’s very likely that your reply would have pulled the trick as well since the commands you posted are exactly the same as what was posted on the link.

Thanks again!