Did you set a password for the “root” user of MySQL?
If you did, then you need to edit /opt/fog/service/etc/config.php and specify the password. This is for the FOGImageReplicator service to check its status and know if it needs to push images to other storage nodes.
Are you wanting to take an inventory every time the computer PXE boots?
You can download the latest Fog code using subversion and the instructions on the SourceForge webpage for Fog (freeghost).
I did this in VirtualBox setting up a Fog server and a few clients. The current code base is missing a few things and some things don’t work yet.
You might try just using the init image and kernel from svn and see if they work for what you need.
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.
A new storage node will contain the same images as your “main” server. It doesn’t really extend your storage space, but increases the amount of hosts you can deploy at a time.
There are a few ways to extend the amount of storage space available for Fog.
These are the ways I know about, but someone else could have more experience.
There are some customizations that the user community has made to Fog which allows you to specify which partitions to upload and deploy, but it is NOT built in to the base product.
I know there is a wiki article or a forum thread about how to do this, so look around.
While researching this I came across an article which talked of how memdisk booting large files can cause memory errors because of the nested memory method it uses. Rather than using memdisk for your kernel and the Windows 7 disk for the init file, you might look for other options such as booting grub4dos.
Can you tell me what graphics card you have or what chipset it is using on the graphics card?
The windows install is pretty big. I think tftp is a slow transfer protocol, only allowing 1 packet to be out at a time. You might try chainloading gpxe to use a faster protocol to download the windows install file.
Get the fog service installed on your images and you can skip the joining to the domain step (with some additional settings in Fog Web UI).
I would increase the queue until it starts affecting the imaging times of the machine by more than a few minutes. It’s really subjective whether you want to do 10 computers every 25 minutes, or 15 computers every 38 minutes.
With a good disk subsystem and raid controller, you can push the server to it’s limits.
For my setup, unicasting is actually faster than multicasting, and much more reliable.
reinstall and use advanced options to choose ext3 as the filesystem instead of ext4, or download and run the fog0.33 beta.
Just looked through the 0.32 code and I can’t figure out why the imageid is not accepted as an arg to the __construct (see [url]http://freeghost.svn.sourceforge.net/viewvc/freeghost/tags/0.32/packages/web/management/lib/Host.class.php?revision=877&view=markup[/url])
It may be a dependency to check if the imageid is valid before setting the value for the host.
I think this is fixed in 0.33 code (revision 877) by looking at [url]http://freeghost.svn.sourceforge.net/viewvc/freeghost/trunk/packages/web/management/includes/hosts.upload.include.php?revision=877&view=markup[/url]
I’m not sure what the process is for patching current and former versions of Fog for bug fixes. At some point we need to roll up a bunch of patches to each version and release a new revision or “service pack”, like Fog 0.32 SP1, but I have no experience in those kinds of things.
Maybe some of us familiar enough to do bug fixes can get write access to the svn repository and work on patches while Fog developers work on the next version.
check your /etc/mysql/my.cnf file, line for Binding Address =
It should be the real IP of the machine, not 127.0.0.1. If you change this, restart mysql service and try again. By default on Ubuntu 10.04, mysql cannot accept connections from outside hosts.
This may not solve everything, but it’ll get us moving towards the solution.
If the fog server is outside of the virtual environment, you have to bridge the card of the virtual machine so it is accessible/visible by computers other than your VM host.
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.
check out [url]https://wiki.ubuntu.com/Kernel/Firmware[/url] specifically the section on [B]Udev sends firmware to kernel[/B]
Please clarify for me where exactly your failure happens. Is it when loading the pxelinux.0 file, or when it tries to load the Fog menu, or when you try to register a client, or when you try to upload or deploy a client?
What chipset are you using (ATI Radeon ???)
Go ahead and setup your Fog server with DHCP and make sure the range is outside those used by your statics. You may have to adjust the switch settings to enable DHCP Relay or IP Helper so that DHCP broadcasts from the PXE client are routed to the Fog server.
Sometimes this setting is already in place by whomever configured the VLANs, but since you don’t have an existing DHCP server, it probably is not configured.
If worse comes to worse, you can setup a Fog server in each vlan to handle TFTP and DHCP, but have them synchronize all images with a master server.