Sorry to hear that your fog server went sideways on you.
Im a bit of a Luddite, but I’ve had great success with Centos 6.7. I’ve installed FOG and Centos 7 without issue either. Fedora works as well as Ubuntu. I find there is the least about of messing around with Centos. But mainstream linux platforms are supported.
If you have a mobile phone, you can grab the error message on the client if you are quick.
@FlareImp said:
My network admin suggested that our content filter may be screwing with something in the script if it’s trying to access a site out on the web.
This makes me think you do have a transparent proxy server/content filter enabled at this site. If you could white list sourceforge.net that should allow the installer to pull the client and kernel images.
[Edit] rereading your OP you will need to enable more than just sourceforge, since the installer reaches out to your linux distribution’s archives to bring in any missing packages. It may be easier to while list the FOG server’s IP address for a short time until you have it updated. [/Edit]
When I have a browser sitting on the dashboard page the following URL is called every second.
192.168.1.43 - - [02/Dec/2015:21:17:41 -0500] "POST /fog/management/index.php?node=home HTTP/1.1" 200 56 "http://192.168.1.88/fog/management/index.php" "Mozilla/5.0 (Windows NT 5.2; rv:42.0) Gecko/20100101 Firefox/42.0"
Based on Wayne’s information I hacked a bit on fog.dashboard.js
Through some trial and error and careful placement of some returns I found that if I comment out these calls cpu usage is normal (I understand by doing this I’m disabling major parts of the dashboard). I can either comment them out individually or together. If I enable either one there are 3 httpd processes launched with about 9% CPU consumed by each process, as reported by top.
UpdateClientCount();
UpdateBandwidth();
Again I’m not saying this IS an issue, its just could be an issue if you have several techs sitting on the dashboard page. This can be managed by workflow.
@Tom-Elliott The results were initially seen by ESXi reporting high CPU usage on the VM. I connected to the vm and ran top and sorted by CPU usage. There was the number of running httpd processes. I noticed that I had 3 different browser windows sitting on the dashboard (shame on me). I closed all of the browser windows except one. All but 4 of the http processes went away. Changing the remaining browser to any other page the http processes disappeared from the top list. Going back to the dashboard and they returned to the top processes. Closing the browser caused the top processes to go away, relaunching the browser and logging into the dashboard they came back. Adding additional browsers sitting on the dashboard brought back the overall CPU consumption.
This specific fog server is in the dev environment so there are no fog clients hitting the server. This fog server is a master replicator server with 2 storage nodes attached. This issue is not related to the replicator since all of the servers are currently in sync.
Is there anything we can do about it. As I said dropping the refresh rate on this graph would be OK with me.
During some testing [GIT 5596] I had 3 different browser pages open to the fog dashboard. CPU usage was about 95% on the FOG server not actively doing anything. Looking at the running process there was ~15 http processes consuming about 9% CPU each (yeah, I know the numbers don’t add up). Moving the browsers to any other page than the dashboard dropped total CPU usage to normal levels. With just one browser sitting idle on the dashboard there were either 4 or 5 httpd processing running at 8% ea. IMO this seems a little excessive for mostly static data. I think a 5 or 10 second update cycle would be sufficient for this page.
As I said above, I don’t know if this is expected behavior or there is something else going on.
Then take the wim file from MDT and move it to the ISO folder and rename it boot.wim. Then just follow the option 2 instructions. If you want to replicate what I’ve done here install MS waik and build this directory structure. None of this code belongs to me or my company.
@FlowLive said:
Is it important to actually use /var/www/html/ or can I just use /var/www/?
I read docs, in part http://ipxe.org/howto/winpe and I already have a wim file but also created an .iso from MDT 2012, now I’m trying to get all this to boot.
My issue is if I use the ISO, I have to press a key to boot from CD or DVD like if I was booting from an install disc which is a bit different than the current setup on PXE which brought us directly to the LiteTouch environment.
Can’t I simply take the wim file already in MDT and along with other needed files have the same “feel” as if I was using the old PXE boot?
Anyone did that or knows what I mean?
As for point 1. the path is specific to your distribution. The rhel branch of linux has /var/www/html the debian branch uses /var/www. To answer your question it needs to be what is correct for your distribution. What I should have said (maybe) is off the root of your web servers base directory (I’m not sure if that is any clearer).
OK, remember that the ISO image IS a CDROM image. This (press any key to boot) is exactly what you get when you boot from a CDROM. So on the plus side it is working exactly correct. Whoot!! but not as you need.
To get roughly the equivalent of what you have with WDS you need to use the option 2 from my post. This is a bit more complicated to setup, but in this case you will take the boot.wim (or what ever the wim file is called) from MDT rename it to boot.wim and install it in the ISO folder.
Let me see what I can do to archive my setup.
Whats going on here is the kernel is seeing the individual disks and not the raid controller. You can’t boot to /dev/sda since that is only half of your data (i.e. half a raid 0 array). So I can understand why its failing.
When you boot the computers isn’t there a banner or such that is displayed during post to show what raid card is installed?
What raid card did you try this on? Unless the drivers are built into the kernel or included dynamically in the root fs, the kernel will be ignorant of the array.
Actually what I think is going on here is that the boot kernel doesn’t have the required driver for the raid card. I’ve seen this in the server realm quite a bit. In this case it would be impossible to include every one off card in the kernel. It would also greatly expand the kernel size to include these random drivers.
If this was more than just a one off situation (thinking the Dell Precision T3400 through the T5600 series with an on motherboard raid card) depending on the number I had to deploy I might build my own kernel (bzImage) that would include the required drivers. But that is a bit beyond the capabilities of most users of FOG. But it would be a real interesting wiki page to go through the process of building a custom kernel.
@Tom-Elliott said:
@george1421 Correction, in the past 2 minutes lol.
WHAT so I’m out of date from 5 minutes ago… nice.
I would recommend that the OP upgrade to the latest SVN since that is at 5590. I know there was some fixes with the snapins in the past 2 weeks.
Well now I’m confused. Here is what you posted before.
This is what it shows when I try to boot to the fogserver:
CLIENT MAC ADDR: 00 22 64 BB 04 DF GUID: 0CD117C8 1FDC DD11 BBDA 64BB04DF0022
CLIENT IP: 10.1.8.59 MASK IP: 255.255.255.0 DHCP IP: 10.1.8.254
GATEWAY IP: 10.1.8.254
PXE-E32: TFTP open yimeout
TFTP…
And you also stated
well the fogserver ip is 10.1.8.1
I’m only seeing a single subnet net here. And all devices mentioned are on 10.1.8.0/24 subnet. The root of the issue I see so far is that the FOG server 10.1.8.1 is not being used for dhcp so any settings you make to FOG will not impact the booting process so far. But the client is reporting that 10.1.8.254 is being used for dhcp booting (which I’m still suspecting is a router). Reading a bit more into the what as not been said yet. Since you introduced the concept of a quarantine network, I get the feeling that 10.1.8.254 is a router interface that has a dhcp-relay setup on it that points to a master dhcp server some place else on another network.
I’m trying to help here but I’m not getting the big picture of how this is setup.
@KellyM said:
For Reference, we are running FOG 1.2.0, no SVN, I believe a UEFI image, (though our machines are set to boot using legacy BIOS, so I am not sure how FOG sees it) and our OS is Ubuntu 14.04 LTS hosting FOG.
UEFI vs Bios is a state of being. You either are or are not. On the Dells you CAN have UEFI enabled with the legacy roms turned on. In this case uefi emulates bios. For me its not clear either if fog sees a uefi system or an emulated bios device. There is a way to tell if you capture the initial bootp request from the client as its asks for an IP address. It will state the arch in object 60 or 93 (I believe). It will be 00000 for bios, 00006 for uefi 32 and 00007 for uefi x64. There are a few others but that is what I can remember.
If you are using the 1.2.0 stable then you may have the same issue as the OP, hang tight.
@Tom-Elliott It appears that the OP is using the 1.2.0 stable image on pretty new hardware (2014). It was my understanding that 1.2.0 stable had issues with uefi image deployment. It would capture the image no problem but it would not lay it down correctly on the disk. It was my understanding that it was fixed in the mid 4000 range of the Git trunk. Is that accurate? For me I would recommend the OP upgrade to the latest SVN trunk, with the understanding it is still beta and pre 1.3.0 release (i.e. there may be a few bugs in the system, but they will get stamped out pretty quick).
[edit] corrected a grammar error in my post [/edit]
@JTech Ok to ensure #3 works we need to verify the version number. Because the stable 1.2.0 does not support uefi images very well. But the SVN trunk (pre 1.3.0) has address uefi deployment issues, plus the pxe boot kernels may not support the 6540 because it is so new. But if you don’t know what SVN/Git is, I’ll assume you are running on the 1.2.0 stable release.
On the login page for FOG, if you look in the upper right corner of the browser page. There should be the word FOG with a cloud picture behind it. To the right of the word FOG there are 4 numbers. What is the numbers.
Sorry for intentionally being dense here. What is device 10.1.8.254 ?
Are you still getting the same exact error message as you posted below?
