Posts made by george1421

@mitzayapa said:

I only have the cable-router and the fog server that provide dhcp service.

IF these two dhcp servers are in the same broadcast domain (L2 network) you WILL have an issue. My recommendation is to disable the dhcp server in the FOG server. If your cable-router doesn’t support pxe booting (most don’t) then setup dnsmasq on your FOG server to fill in the missing bits.

Here is something I put together for centos 7, if you are running ubuntu this can still get you started. https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

I was able to supply dhcp pxe boot information on my home kit using a linksys WRT54 internet router using the stock firmware and a fog server with dnsmasq enabled.

In addition to MBR disks, ensure you are in BIOS mode not UEFI. The two mentioned version of FOG do not support UEFI very swell (0.3x ==no, 1.2.0 == some times)

I understand there may be a language issue here but this is what I see.

You have two subnets (I’m ignoring vlans since that fact is not important) which are 172.16.17. 0/24 and 172.16.16. 0/24. Your fog server is on the 172.16.17. 0/24 subnet. All devices within the 172.16.17. 0/24 subnet work perfectly with FOG.

The issue is your clients on the 172.16.16. 0/24 can not communicate with the fog server on the 172.16.17. 0/24 subnet. Your firewall is blocking the communications. You need to open a series of ports between your clients on 172.16.16. 0/24 and the fog server (more than just ping). To pxe boot you need to enable the tftp protocol and the nfs and ftp protocols between the subnets. Without this enabled your clients on the 172.16.16. 0/24 subnet will never be able to pick up the ipxe boot kernel or image any machine. While if you need the restrictions you can work out the exact rules needed. But, the easiest solution is to create a general rule on your firewall of:
source net 172.16.16. 0/24 to destination host 172.16.17.250 protocol any state allow
And then flip the rule to allow the FOG server to talk to the clients
source host 172.16.17.250 to destination net 172.16.16. 0/24 protocol any state allow

These rules will say all clients can talk to the fog server only across this firewall and the fog server can talk to the remote subnet only. This is allowed communications.

Unless I missed it, what device/network is hosting your DHCP server? You may have to setup the dhcp relay agent on your firewall/router to send the dhcp requests across your firewall

While I don’t have an answer for you on the multicasting parts of your question. If I may collect a little background information to help the others answer your question.

1. What OS are you using on the FOG server?
2. What version of FOG are you using. I will guess 1.2.0, but did you upgrade to the trunk version (i.e. pre 1.3.0)?

The answers provided may change based on these questions.

Please ensure your main ethernet adapter is called eth0. On some of the newer kernels they moved away from eth0 to be more network adapter specific ( like em0 )

Please start a new thread since your issue will get lost in this thread’s title.

But it sounds like you have two dhcp servers running in your environment.

If I understand your question, this one got me confused for a bit too.

(warning typing with one eye open) For debug mode go to the host and then for the host select tasks then advanced (its below the deploy and capture options). When you select advanced you will see a series of additional tasks you can assign to the target computer. Debug is one of them.

@Wayne-Workman You better marry that girl, or I’m going to offer her a job up north (in snowy Michigan) in my group.

I think there is something with the tasks pages. When I just sit on the tasks page the little popup 0 active tasks found is consuming about 8% cpu according to top. On my first test of this that 8% cpu task persisted even when I moved to another page. Then I was getting a session time out popup. Closing the browser and going back in still netted the session timeout. I had to actually log out for that session cookie to reset.

[Edit] After additional testing that 8% httpd process seems to be related to that popup message (i.e. tasks/session/loading/load failed) [/Edit]

I ended up having to go into the database and manually deleting that 46 year old task. While that solves my problem, I still think there is something wonky with the task scheduler. Either I keyed in the wrong / unexpected values for that cron scheduled task or something is confused in the code.

Wow the forum site crashed as I was submitting a follow up.

It does appear to be something related to the cron task scheduler. I found another task hanging about on the system I tried launch a cron style wol and then an active wol for this computer with no luck.

When I go into Task Management -> Scheduled task strange things happen. The http service jumps to 100% and stays there (along side the fogtaskscheduler. Eventually something shows up in the list (the wol task I created 3 weeks ago). It takes several minutes to show the pending/waiting task. After several minutes of waiting for the Scheduled Tasks pane to populate several new http processes are spawned. I think they are related to the pop up no tasks found that flashes (up at the top) when you are on the tasks menus. Eventually when that pending task shows that no tasks found changes to loading with a revolving arrow. That is when the real fun starts where a new httpd process is started every 2-3 seconds filling up top with httpd processes.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1883 apache    20   0  332m  20m 3820 R  7.7  1.1   0:22.71 httpd
 1884 apache    20   0  332m  20m 4004 R  7.7  1.1   0:15.61 httpd
 1885 apache    20   0  332m  20m 3828 R  7.7  1.1   3:01.27 httpd
 2220 apache    20   0  332m  20m 3552 R  7.7  1.1   0:09.17 httpd
 2227 apache    20   0  332m  20m 3552 R  7.7  1.1   0:07.52 httpd
 2234 apache    20   0  332m  20m 3552 R  7.7  1.1   0:06.09 httpd
 2252 apache    20   0  332m  20m 3552 R  7.7  1.1   0:02.77 httpd
 2274 apache    20   0  332m  20m 3552 R  7.7  1.1   0:00.63 httpd
 1878 apache    20   0  332m  20m 4012 R  7.4  1.1   0:27.58 httpd
 1881 apache    20   0  427m  20m 4028 R  7.4  1.1   0:14.06 httpd
 1882 apache    20   0  427m  20m 4044 R  7.4  1.1   0:18.21 httpd
 2236 apache    20   0  332m  20m 3552 R  7.4  1.1   0:05.30 httpd
 2238 apache    20   0  332m  20m 3552 R  7.4  1.1   0:04.86 httpd
 2245 apache    20   0  332m  20m 3552 R  7.4  1.1   0:03.75 httpd
 2259 apache    20   0  426m  19m 3816 R  7.4  1.0   0:00.34 httpd
 2263 apache    20   0  332m  20m 3552 R  7.4  1.1   0:01.86 httpd
 1879 apache    20   0  332m  20m 4136 R  7.1  1.1   0:31.02 httpd
 1880 apache    20   0  332m  20m 4004 R  7.1  1.1   0:16.85 httpd
 2216 apache    20   0  332m  20m 3552 R  7.1  1.1   0:10.62 httpd
 2218 apache    20   0  332m  20m 3552 R  7.1  1.1   0:09.63 httpd
 2225 apache    20   0  332m  20m 3552 R  7.1  1.1   0:07.96 httpd
 2229 apache    20   0  332m  20m 3552 R  7.1  1.1   0:06.54 httpd
 2243 apache    20   0  332m  20m 3552 R  7.1  1.1   0:04.18 httpd
 2250 apache    20   0  332m  20m 3552 R  7.1  1.1   0:03.19 httpd
 2254 apache    20   0  332m  20m 3552 R  7.1  1.1   0:02.28 httpd
 2268 apache    20   0  332m  20m 3552 R  7.1  1.1   0:01.42 httpd

Rebooting the fog server puts me back in the same condition. The other anomoliy I found is when eventually the page loads and it showed me I had a wakeup task scheduled, it has a start time of 46 years ago. Also noted in the fogtaskscheduler log with the task run time of 1969. (I do remember that year, and I’m pretty sure I didn’t launch the wol request then).

I just updated the dev box to 5864 and I noticed that the FOGTaskScheduler service consumes 100% cpu for 2 minutes then rests for 1-2 minutes then comes back for another 2 minutes. This is a continual cycle.

This is the content of the task scheduler log.

[01-05-16 7:37:05 pm] Interface Ready with IP Address: 192.168.1.88
[01-05-16 7:37:05 pm]  * Starting TaskScheduler Service
[01-05-16 7:37:05 pm]  * Checking for new items every 60 seconds
[01-05-16 7:37:05 pm]  * Starting service loop
[01-05-16 7:37:05 pm]  * 1 active task awaiting check-in.
[01-05-16 7:37:05 pm]  | Sending WOL Packet(s)
[01-05-16 7:37:05 pm]           - Host: MDTx86Golden WOL sent to all macs associated
[01-05-16 7:37:06 pm]  * 1 task found.
[01-05-16 7:40:23 pm]  * Task run time: Wed, 31 Dec 1969 19:00:00 -0500
[01-05-16 7:40:23 pm]  * Found a task that should run...
[01-05-16 7:40:23 pm]            - Is a host based task.
[01-05-16 7:40:23 pm]            - Task Started for host MDTx86Target!
[01-05-16 7:40:23 pm]            - Cron style - No cleaning!
[01-05-16 7:41:23 pm]  * 1 active task awaiting check-in.
[01-05-16 7:41:23 pm]  | Sending WOL Packet(s)
[01-05-16 7:41:23 pm]           - Host: MDTx86GOLD WOL sent to all macs associated
[01-05-16 7:41:24 pm]  * 1 task found.

To clarify a bit, I tried to launch the WOL task about 3 weeks ago to start up a downed computer and the task still is listed in the Active Tasks. Killing that active task did not change the CPU usage for the FOGTaskScheduler task. Now that I think about this a bit more, when I launched the installer for this version of the trunk it took about 20 seconds for any text to be displayed by the installer. I first thought something was wrong with the installer script, but it may have been this background task consuming 100% of the CPU. So its possible that this has been an issue since mid Dec when I last upgraded the dev box.

@Junkhacker Yeah, I’m with Wayne on this one. Do a sanity check with a second 5450. Just in case there is something wonky with this unit you can rule it out by compare and contrast.

As will all systems, make sure it is on the latest bios and be sure to reset the bios settings back to default first then make any system required changes.

I also found out through testing the target hard drive will have an impact on deployment times. Does the unit have a ssd or a rotating hard drive?

I’m sorry I missed this earlier today.

I see the version you are using so that’s good. Is this a new FOG install or something that had worked in the past and now its broken?

If you are getting to the FOG iPXE menu then the pxe booting process is working as expected, but it appears from the error it appears that its not getting that far.

So far from the error I can see its PXE booting and downloaded the undionly.kpxe file, because that is clearly visible in your attachment. Where it is failing is chaining to the http://<fog_server_ip>/fog/service/ipxe/boot.php file.

In regards to the target computer you are trying to boot, since you are telling the client to download the undionly.kpxe file your is your target computer configured for BIOS and not uefi/secure boot?

And finally what is the make and model of the target computer generating this error message?

@nshaw said:

@george1421

Can you explain the sys prep directions? I don’t think I’m 100% clear on that process. Do you simply run sysprep / OOBE /generalize / shut down? Once it shuts down upload in FOG and pxe boot on reboot?

That is the general idea. You take and build a single reference image that has all of the drivers and software you want in that build you do this in audit mode. Make any configuration changes you need to windows and the application then run sysprep. That older version may require a FOG utility called fogprep (which does some cleanup work then calls sysprep). That fogprep/sysprep will prepare the system for cloning and then power off. At this point if you powered it back on and let windows boot it will run the OOBE and reinstall windows on that reference computer (not what you want here). Once you run fogprep and it shuts down, you will create an upload task in FOG then pxe boot that reference computer to capture the contents of the reference computer’s hard drive. Once you have that captured image you can deploy it to the next target computer (I would leave the reference computer powered off at this time just in case you need to capture the image again). From there you can deploy to the remaining computers in your lot.

I do have to say from a licensing standpoint you need to ensure you are using a VLK key since the Windows OEM licenses do not come with imaging rights. There is nothing technically stopping you from cloning a OEM license, but you will have difficulty activating them.

@nshaw Ok the model number answers a few questions then. That system is old and doesn’t know anything about uefi, that came in starting at 790.

For the 760, you need to go into the bios and look for the nic settings. You need to turn on pxe support on that nic. (I have not personally done this with the 760 but it should be there, I have with the 780s and it is there. The options on the 780 for the nic are off, on, on with pxe).

In regards to the failed boot, yeah that reference image is botched and you will need to recreate it. Because you need to capture the image in the sysprep mode not after OOB runs (and is broken now). You can test upload on the broken image (I would do this until you are sure you can get these systems to upload at least once). Then recreate your reference image and then sysprep and capture that. Thinking about your broken image. Your system should have ran to completion and created a fully functional system. IN theory you should be able to create your reference image, sysprep, shutdown, reboot and then OOBE will run to redeploy the sysprep’d image. You should end up with a functional image even through it is on the same hardware and FOG wasn’t involved. Since you have a broken image, I’m wondering even if FOG worked you would still have problems.

@nshaw The easy answer first. No nothing needs to be downloaded from fog to upload.

OK thats good then you’ve used FOG to download images before and I assume that still works. That tells me you have pxe booting setup and you have the correct settings to get into the fog pxe boot menu.

On these 10 new devices, can you get to the pxe boot menu at all? If not how far are you getting?
Just for the sake of discussion, what make and model are these computers?
Since you are running 0.30, have you reset the bios (on these 10 new computers) to ensure you are in bios mode and not secure boot/uefi? (for reference any fog version before 1.2.0 doesn’t support uefi mode at all. And support for uefi in 1.2.0 is hit or miss. The trunk version does a lot better with uefi support).
Did you manually register the new computers with FOG or did you use the pxe menu to register the device with fog (if manual then we need to check the mac address to ensure that there wasn’t a miss-key)

@nshaw Please understand I’m not condemning here only stating that the newer version(s) (also free) has more features and are easier to support. The 0.30 build is old and some of the components can not be fixed if there is a discovered but.

Just so I can establish a baseline for the discussion.

Is this a new install / never been used / or are you new to FOG?
Have you ever pxe booted into the FOG menu before? (this will tell me if the infrastructure is setup to support pxe booting).

I guess the first question is why are you using version 0.30? That is a really old version of FOG. Is this a new install? If so I would recommend that you start with at least 1.2.0. The developers are working on 1.3.0 which has a lot of new enhancements. I would actually recommend the trunk build (pre1.3.0) but right now the installer has a few bugs that was discovered just before christmas that haven’t been addressed yet. So for the trunk build I would hold off a bit longer.

To your question. You would build the reference image and then sysprep it then shutdown.

From there you schedule a upload task in FOG. When you boot the reference image you need to ensure that it pxe boots into the fog menu, that is where the image will then be uploaded into fog. Since I personally haven’t worked with .30 in about 6 years I can’t give you step by step instructions if this part fails.

@Kiweegie No its not hard. If you get it wrong, after you upload the image it will not be able to move it to the /images folder and on the target computer’s screen you will see unable to login to fog account with password xxxxx that gave me the idea to search the gui for the right password and update the fog user in linux.

The best solution is for when the developers get back from holiday to fix the installer so it works right. But if you are in a tight spot and need it now this route will work.

Here is a bug for the normal node setup too. It says as you saw failed setting up storage. But if you run the installer a second time it will install OK.

If you go this route, you will have to go into the fog settings and get the linux account information for the fog user. You will need to setup the linux password for the fog user to match what is configured in the fog database. It sounds hard, but just get the settings from the default storage node pane and then do a passwd fog xxxxxxxx from the console as root. Where xxxxxxx is the password gleaned from the storage node pane.

The storage node also failed under centos 6.5 but at a different spot.

* What is the storage location for your images directory? (/images)  
* Setting up fog user............................................OK
* Stopping web service........................................Failed!