[quote=“Charles Warner, post: 4658, member: 1520”]Well, for whatever reason, I can’t seem to see the example attachment above, but I’m getting the same problem. If the NIC or chipset is not supported, how do we continue?

Charles[/quote]
Charles,
You will need to try different kernels to find out which ones will work for your specific systems. You can check the list here to see if someone has posted a solution for your specific machine. [url]http://www.fogproject.org/wiki/index.php/WorkingDevices[/url]
Or you can log into your FOG web GUI and click on the blue circle with the question mark in it (Other Information) and select Kernel Updates from the menu on the left hand side of the screen. This should open a page with a whole bunch of kernels and a download button for each of them. You didn’t list which version of FOG you are using so I am not sure what version kernel it is using, so I would suggest backing up the bzImage file located in the tftpboot/fog/kernel directory before trying new kernels.

The fog boot menu only uses the default bzImage kernel, therefore any new kernel must retain the name bzImage to be used during the registration process

Ok…
I found this in another thread by chad-bisd

“go to your Fog server web page, login, go to storage management icon, click All Storage Nodes on the left menu. Select the storage node you want to edit, which is probably DefaultMember, adjust the MaxClients value there to however low you want it.”

Here’s the thread…
[url]http://fogproject.org/forum/threads/changing-number-of-unicast-slots.906/[/url]

IST,
I had the same problem with all my Dell systems that had a ATI Card installed.

Check out this thread.
[url]http://fogproject.org/forum/threads/dell-optiplex-780-will-not-upload-image.874/[/url]

i should have the same .net installed on both the XP and 7 but they could be handling it in different ways. Stopping on the low memory computers after image is probaly the way I’ll hadle it.

In the /tftpboot/fog/kernel folder resides the default kernel, it is called bzImage, this is the kernel the fog boot menu uses as I think that is hard coded in fog. If you cannot get your computers to register you will need to replace the current bzImage kernel, which according to Google is kernel version 3.2.4, with a kernel that allows you to complete the registration process. In order for your new kernel to work for the registration process it will have to be named bzImage.
So you will need to replace the default kernel with the kernel that works.
My suggestion is to use the GUI interface and find the kernel you need and download and install from there. Its the quickest and easiest way for me to do it.

I was unaware of that. We have more imaging on tap. I will check that. Thanks!!

Fog will overwrite the MBR to setup the partition layout and then lay the data down on the disk. Should not be an issue to overwrite a previous install of another OS. I’m sure there are exceptions, but normally this will not be a problem.

[quote=“BryceZ, post: 4608, member: 2”]if you boot a host into debug mode you can run the command
[CODE]uname -a[/CODE]
which will spit back the kernel version along with other info.[/quote]

Worked perfectly. Thanks.

It probably turns out that the fog server configuration wasn’t completed.
Make sure that all of your IPs are correctly configured.
See here: [URL=‘http://www.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address’]http://www.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address
I know you never said that you were changing your IP addres, BUT this is a good place to make sure that all is configured. [/URL]
Enjoy!

Now if I could only get Fedora 17 to work…
I know I know - 14 is best, and I’m about to roll back…[URL=‘http://www.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address’] [/URL]

I had a weird issue registering hosts similar to this. It turns out the students had removed the belt from the dvd-rom drives and Fog would freeze for about 45 seconds. I guess it was trying to get the status of the device, but without being able to confirm if the drive was open or closed, it just sat there and spun the motor back and forth for a while.

I found ejecting the drive with a paper clip immediately caused Fog to continue to the normal registration.

Something else to consider is that the error you see has nothing to do with what is really causing registration to fail. Consider booting the debug mode see if the error you see is truly what’s wrong. There is a wiki guide to debugging somewhere.

Seems I found the culprit. I use an SSL cert for the web interface and use mod-rewrite to redirect all traffic to https://

This apparently is not something FOG’s web service can handle so I modified my rule set as follows:

RewriteEngine on RewriteCond %{SERVER_PORT} ^80$ RewriteCond %{REQUEST_URI} !^/fog/service [NC] RewriteRule ^(.*)$ [url]https://%{SERVER_NAME}$1[/url] [L,R] RewriteLog "/var/log/apache2/rewrite.log" RewriteLogLevel 2

For anyone else that wants to run their FOG web interface with SSL, I hope this helps. I’ll post anything else related to this if it comes up.

It looks like the InstallRite website is completely shut down. My problem with SFX is creating answer files to make the deployment unattended. I just wish it was user friendly.

[url]http://www.epsilonsquared.com/[/url]

I believe you can only schedule regular task per host right now. You can schedule a “run now” task to wipe the disk, and schedule a 1 time scheduled task to re-image the machine in a few hours. That gets you there, but not very elegantly.

If you are saavy, can you try making an addition to the Fog scripts in the init image to handle a disk wipe and re-image task and then modify the Fog menu to add that option, passing in all the parameters needed. Just keep a backup copy of the original files and your modified versions for when you want to upgrade Fog versions.

[quote=“Neil Mason, post: 1494, member: 545”]I’m getting exactly the same problems when imaging Lenovo E520 laptops. PC’s upload their image to the FOG server no problem, and when I tell the host group to deploy the image to the other PC’s, it works fine. However, when the PC’s re-boot, it’s stuck in the boot loop. If I escape the PXE client, the Windows 7 OS loads fine.

ANy ideas to why this might be happening? I’m really impressed with the capabilities of fug thus far, if I could just tweak the minor problems that I’m having, it would be awesome.

Thanks for any help you might be able to offer.

Neil Mason[/quote]

We have found that reverting back to the PXELinux.0 file that came with version .28 has resolved our boot loop issues.

Hey,

Thanks for the response. I bailed on the server for the time being. In some of the other work I’ve been doing I found that including other modules into the image is pretty easy. I just needed to run

/opt/fog/utils/Boot Image Editor/FogMountBootImage.sh

This should let me place the modules that I need (once I identify them) into the image so they are available when fog loads. I haven’t tried it yet but when I do I will come back and update this thread.

Thanks
Damian

Hi. i force a similar problem.
and i have to say, i am not an linux expert.
i use the fog server on a ubuntu machine and i modded the pxe menu to boot a hirensboot.

i can point on the boot.gz file which contains all dos programs, but when startig a test it asks to load a cd-rom driver.

today i found the isolinux.iso and cfg file. is the fog server able to list the isolinux.cfg file?

some help would be nice.

Have you checked the wiki for working or problematic devices?