Posts made by BryceZ

Do those machines have problems with the “localboot 0” option?

Hmmm, the only time I’ve seen this happen was when a machine didn’t have a bootable OS on the first drive, which caused the system to restart the boot process and continue looping. I’m going to guess that these workstations and server are able to boot if you cancel PXE booting, right?

If I’m following this correctly you’ve added a second DHCP server to your network (definitely not a good thing). The first options that come to mind are:
[LIST]
[]keep the FOG server on an isolated network and only connect your computers to that network for imaging
[]disable the DHCP server on the FOG server and change the DHCP options on your main DHCP server to point to your FOG server
[/LIST]

As far as I understand it, it’s one PXE server per DHCP scope. So whichever server is listed in the DHCP options for any given scope is the one who gets serve PXE for that scope.

If it’s continually booting into FOG as if it has a task, meaning not just the FOG boot menu, then there is probably still an old boot file for that machine sitting on the server. Make sure any tasks for it on the server are killed, then go to /tftpboot/pxelinux.cfg/ on the server and look for the file that matches the MAC address of the host you’re having problems with. Delete that file. That will take care of any lingering tasks.

If you’re just going to the FOG boot menu and then after the timeout it’s telling you invalid OS then it looks like your MBR is messed up and I’d suggest reimaging with the correct image and OS id.

I’m just guessing off the top of my head here, but I think it’s probably a limitation of the FOG boot image (custom buildroot linux); which I’m pretty sure is only running a 32bit kernel, so it wouldn’t be able to detect more than 4GB.

I did some firewall configs a while back and posted them [URL=‘http://fogproject.org/forum/threads/firewall-config.27/#post-75’]here[/URL]. They’re far from perfect, but they might help point you in the right direction.

There was at one time a member of the FOG community that wrote a location patch to do something like that.

When you set up a normal FOG installation and you create an image definition it gets tied to a Storage Group. You can set up multiple Storage Groups and multiple Storage Nodes as members of Storage Groups. When you upload an image it writes to the primary Node of the Group, and when you multicast it pushes from the primary Node of the Group; apart from that it’s all about load balancing. I don’t know the logic off the top of my head, but I think FOG just loads up one Node with deployments until its full and then checks the Group for the next Node.

Without using the location patch, you can set FOG up to do what you want, but it gets a little ugly… Using one master Storage Group you add your remote Node to it, and create your master image pointing to the master Group, this way FOGSync will replicate the image between the master Node and the remote Node. Then you set up a remote Group and a second Node definition that matches the first remote Node except it uses the remote Group instead of the master Group. Then you set up a second image definition that matches the first image except it uses the remote Group. So now when you set up a host at the remote location you assign it to the remote image and it will only pull from the remote Group, and because the remote Node is in both Groups the image is just a copy of the image you first created on the master Group. Not the easiest setup, but it works.

ssx4life, can you think of a good reason for not supporting Windows 8?

Let me try an analogy here… SCCM is like a cargo van while FOG is a sports car. FOG does one thing really fast (imaging), while SCCM is bulkier but has more to it (remote control, software inventory, etc). One aspect to compare would be software deployment; SCCM is a lot more sophisticated in it’s ability to schedule and deploy software than what FOG has to offer via Snapins; So if software deployment plays a large role in determining which system to use then you really need to be sure that the simple options FOG offers in this area can handle what you’re trying to accomplish. A comprehensive comparison of the two systems would be heavily weighted by what your environment looks like and what your needs are. You might even find it best to run them both, though this can get messy.

At this point FOG doesn’t have any support for Linux beyond imaging.

FOG doesn’t care which distro you use, as long as the filesystem is ext2 or ext3.

FOG uses [URL=‘http://www.partimage.org/’]Partimage[/URL] for the actual image creation/deployment, which creates an image of the drive at the sector level, meaning there is no “filesystem” that can be modified. There was [URL=‘http://www.partimage.org/forums/viewtopic.php?t=309’]talk in the Partimage forums[/URL] a while back about trying to write a block device driver that would allow you to mount your Partimage image files and modify them, but Partimage files are compressed internally (as in Partimage compresses the stream of sectors while writing the image file), so you would also have to decompress the image file before you could even mount it, at which point you’re basically deploying the image. So the only real option is to deploy the image to a computer, make whatever changes and then upload the image again.

You [I]can [/I](assuming certain network configurations) have the remote office PXE boot off of your main FOG server, but unless this remote office is across the street, and you’re running at least 100Mb between the buildings, I wouldn’t suggest it. It’ll give you fairly poor performance.

[url]http://www.fogproject.org/wiki/index.php/Multiple_TFTP_servers[/url] is probably the best advice without knowing a whole lot more about your environment. This way you’re still managing things from the main FOG server, but with the benefit of having all the heavy network access localized.

As long as you configure your Storage Groups and Images correctly (meaning the remote office storage node is in a different storage group, and your images for the remote office use that storage group), in theory it’ll work like a charm.

Not that I’d recommend it, as it’s pretty outdated, but there is a VM appliance for FOG 0.27 ([url]http://sourceforge.net/projects/freeghost/files/FOG_VM/fog_vm_0.27/FOGVM_0.27.zip/download[/url]).

Which version of Ubuntu have you tried? There have been some issues with 12.XX, but most people seem to be able to install with 10.XX just fine.

If there is an official tarball of 0.33 then it’s news to me. The command I use to pull down 0.33 from SVN is:
[CODE]svn co https://freeghost.svn.sourceforge.net/svnroot/freeghost/trunk /opt/freeghost[/CODE]
If you don’t add “/trunk” to the end of the URL it will pull down the entire history of FOG, which is probably over 1GB.

There is not currently an official upgrade path for 0.33 as it’s still in beta. If you want to test it out I’d suggest setting up a VM or test server as it’s really not ready for production.

Once you have a server setup (Ubuntu or whichever distro you choose), you’ll need to make sure that subversion (svn) is installed. Then just run the following command to pull down the current version of 0.33…
[CODE]svn co https://freeghost.svn.sourceforge.net/svnroot/freeghost/trunk /opt/freeghost[/CODE]
and run through the installer as root…
[CODE]cd /opt/freeghost/bin
./installfog.sh[/CODE]

If you have any feedback you’d like to provide, please use the [URL=‘http://fogproject.org/forum/threads/bugs-in-fog-0-33.631/’]Bugs in FOG 0.33[/URL] thread.

Although it’s not officially supported, there is the [URL=‘http://www.fogproject.org/wiki/index.php/Bypass_Host_Registration’]bypass host registration[/URL] method. Otherwise, yes, you will need to register each host before imaging.

Correct. It seems to have no problem with a system that has been sysprepped.

I haven’t seen anyone doing this yet, but I think you’ll probably want to look into [URL=‘http://ipxe.org’]iPXE[/URL].