@Tom-Elliott

That is pretty much what I have with the bashrc settings. The issue is that the no_proxy points to localhost and the script calls the fog server IP address [from my memory].

BUT I could use bits of what you posted with something like this. (understand I already have the exports for the http_proxy… in my bash rc)

no_proxy="<ip_add_fog_server>" ./installfog.sh -y

That would allow the installer script to run unaltered and still tell wget to no proxy for the fog server IP address. I don’t know how big an issue this is or how many fog servers are behind proxy servers. I just wanted to get it documented for others that may find this post.

Also so everyone knows, I helped @sacha-marin earlier. he had two symbolic links pointing at each-other in /var/www and /var/www/html I deleted both of them and that fixed the installation.

@jeremy-mcflight said:

Update: For a strange reason - I have deleted the previous image file, created a new one , re-uploaded the new image, changed back the Deploy method to “PartClone” - and now it’s working fine! However, I still want to thank everyone for giving me a hand. You guys rock!

In that order, exactly? That doesn’t make sense to me.

While I don’t have an answer for you, I do have a feature request out there for the exact same thing. https://forums.fogproject.org/topic/6014/create-the-concept-of-a-foreignmasterstorage-deployment-node
Right now there the only way to do this is manually or scripting via sql dump and sql import of the images and snapins tables between the deployment nodes.

You can do something similar but with storage nodes (not a master deployment node), and you will need to install the /tftpboot files on the storage node. You will need to use the location plugin and storage groups.

Yep upgrade worked like a champ. So in short all it needed on my end was the upgrade and update. But adding the code wouldn’t be a bad idea as most of us wouldn’t think it that far through. Still not sure what happened with NTP.

@Sebastian-Roth
Thanks for reply. I come back to last settings.
Regards

@Tom-Elliott Thank you sir…I’m sorry I didn’t have much info to help diagnose. Appreciate everyone’s help.

Look at the path in the error, ...URL /fog//service... It has two slashes back to back. That’s probably the issue.

What OS are you using? What’s your web-root setting for this storage node set to?

@Joseph-Hales said:

It is likely that I am the only one who is trying to run SVN at this time most large shops won’t upgrade till final release.

And that is greatly appreciated, you’re helping support FOG just by running trunk in your organization and working with the developers on issues. People like you help make FOG releases solid for everyone else.

Per SVN 5211 resource issue corrected…no longer are there excessive apache processes.

This is normal and expected output for OU or any active directory operations from the group I have attempted to make resetting stick for groups so long as every host in the group already have this setting however this is only in the development version 1.2 did not have this feature

Thanks for clarifiying!

Sure you followed this part of Tom’s suggestion: “cd to your fog web directory”?
If not the command might have tried to search through all the files on your whole system. That’s not a real problem bust usually does not come to an end because it hangs when trying to read pipe files (stuff mostly sitting in /var …).

The string is found in those files:

./management/index.php:ob_start('ob_gzhandler'); ./management/static/help.php:ob_start('ob_gzhandler'); ./lib/fog/ProcessLogin.class.php: ob_start('ob_gzhandler'); ./lib/fog/ProcessLogin.class.php: ob_start('ob_gzhandler');

See if you can fix things for you.

Multicast “SHOULD” be the FOG Master Node. Unless your NAS Box can install web and run UDP, it MUST be done with a different box.

That said, NAS’s have a lot of their own problems with FOG Beyond multicast. 1.2.0 just isn’t very friendly with them. I’ve made some strides with the issue’s most NAS’s tend to cause in FOG Trunk, but what you’re wanting to do (Multicast from a NAS) is still not something I would try.

First, as I stated earlier, the NAS would need to be it’s own node completely for it to work best. While many NAS box’s have a form of linux running them, I don’t think they have the utilities available to install UDP-Cast which would be needed.
Your best option would be to mount the NAS’s storage to a more appropriate system that has a FOG Server installed.

Second, if you go with the option to mount the NAS’s storage, the work is, most times, mounted from the network. Multicast just wouldn’t work very well because of how UDP works. UDP spams its packets out without caring who or what see’s them. This, typically, floods a network. As the NAS is network connected, it would also be spammed by these Packets. Essentially, this could cause a complete disconnect of the NAS’s shared filesystem, ultimately affecting the imaging you’re doing.

If you must use a NAS for storage I would highly staying away from Multicast.

I guess I should clarify. We use MDT to create our reference image on a VM with a 40GB disk. During the MDT deploy task we apply all of the windows updates. If we are making a fat image then we install the additional software at that time (using a fat image task sequence in MDT). When we have the image the way we want it, then we sysprep it and capture the image. At this capture point we still only have a 40GB disk. So we deploy that 40GB disk to the target computer and then once on the target computer we extend the disk with diskpart.

We do it this way because we rebuild the golden image each quarter. If you have everything setup to create your reference image automatically, the actual hands on time is very small. What takes the most time from start to finish is windows updates. So far with the WIndows 7 updates it takes overnight to apply them all (~14 hrs).

While I got a bit off point, the key is to deploy a smaller image to your client computers than their smallest disk size then extend their logical disk to the physical size during the cleanup process.

@Drevonovic You are welcome! Do you want to stick with pxelinux or try to get the normal way with default.ipxe up? See my other post and feel free to ask if you need further assistence.

I’ve readded the code that supposedly fixed this earlier. I’m hoping it can be put to bed, but my track record or something.

This issue as well as a few others have been pushed. Thanks for reporting.

I have used this configuration and it works! Link from Wayne Workman! Kudos to you my brother! Thanks!

Example 1

Here’s a complete configuration example where TFTP and DNS is on the same Server. No router is defined in this configuration but can easily be added by changing X.X.X.X and un-commenting the line.

option space PXE; option PXE.mtftp-ip code 1 = ip-address; option PXE.mtftp-cport code 2 = unsigned integer 16; option PXE.mtftp-sport code 3 = unsigned integer 16; option PXE.mtftp-tmout code 4 = unsigned integer 8; option PXE.mtftp-delay code 5 = unsigned integer 8; option arch code 93 = unsigned integer 16; # RFC4578 use-host-decl-names on; ddns-update-style interim; ignore client-updates; next-server 192.168.1.1; authoritative; subnet 192.168.1.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; range dynamic-bootp 192.168.1.10 192.168.1.254; default-lease-time 21600; max-lease-time 43200; option domain-name-servers 192.168.1.1; #option routers x.x.x.x; class "UEFI-32-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006"; filename "i386-efi/ipxe.efi"; } class "UEFI-32-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002"; filename "i386-efi/ipxe.efi"; } class "UEFI-64-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007"; filename "ipxe.efi"; } class "UEFI-64-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008"; filename "ipxe.efi"; } class "UEFI-64-3" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009"; filename "ipxe.efi"; } class "Legacy" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000"; filename "undionly.kkpxe"; } }

@mjcrane Great! Got it right this time 😄 You are welcome!

Take a look at this script: http://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/src/ipxe/src/ipxescript

This is compiled into the iPXE binary Tom is building for all of you (the original undionly.kpxe you had in /tftpboot sitting). The last line is chainloading default.ipxe from the FOG server. In your case the variable ${next-server} is being set to your ISPs router IP. So I just compiled a new binary and exchanged the varibable with a “hardcoded” 192.168.0.111 - pretty ugly but still working…
If you want to play with this without installing all the building tools you can go to https://rom-o-matic.eu/ (But be warned, getting all the settings right is kind of tricky!)
Just give it a try. There is a lot you can learn about PXE booting by trying out these things.

As I already said there might be a fix in the script that we could add which hopefully should work for others too. @Tom-Elliott What do you think? See in one of my earlier posts. Either that or we just overwrite next-server without checking it being set or not in case proxydhcp is set?!

#!ipxe ... isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} ...