I think we’ve moved the troubleshooting to the thread over in the Technical Help forums and abandoned this one in the Developer forums.

the only passwords encrypted with FogCrypt are those you setup for Active Directory integration. I think the rest of the passwords are random strings.

Also, there is a fog user for the WebUI and a fog user in the OS used for a couple of things including TFTP I think. Make sure you are looking/change the correct one.

I don’t think it’s a something with the fog server. This may be a problem with the PXE boot rom of the motherboard/nic. Try booting using gPXE boot disk/flash drive and see if you get the same error.

You have to have a machine (virtual or otherwise) already loaded up with Ubuntu, take that image, then deploy that image to another machine (virtual or otherwise). You can’t easily use Fog to push the Ubuntu installer. Also, if you are going to image Linux, you can only have primary partitions of type ext2 or ext3. Fog does not currently support ext4 filesystem, which is the default for Ubuntu. When you install Ubuntu, specify the advanced options during partition and formatting to use only ext2 or ext3 for your non Swap partitions.

In vmware, I think you have to tweak the network adapter settings to make it so the two virtual machines can talk to each other. In VirtualBox, you have to make them both part of the same named network. I do not know the specifics for vmWare.

Yep 3.3.3 is the only one i can download [url]http://www.filedropper.com/bzimage34[/url] doesnt work at all now so googling alas didnt help =/

Anyone got it to hand they can send to me? emails [EMAIL]rakarnsunju@hotmail.com[/EMAIL]

Cheers

Ask your administrator about turning on portfast for all the ports so there no delay between them being connected and being active. See if that helps.

I’m not sure why your dhcp daemon is not autostarting. Did you try adding it to the default runlevel or making sure the startup script is getting call? dmesg or /var/log/syslog might have some clues.

If my fog server is inside virtualbox along with the test clients, it works fine for me. I have not yet tried to register a virtualbox guest from a fog server that is outside the host. I don’t know how that works.

[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.