FOG runs on top of Ubuntu Server (or centos)

so yes you will need to install Ubuntu as a VM

Have you tried using kernel arguments like nomodeset?

That sounds fine. Let me know if any code needs to change in FOGController or FOGManagerController

You should have a look at the latest code i have submitted. I have made a lot of changes to how Tasks are generated.

$Host->startTask was written by microleaks, but never put into prodution. The old production code was in ‘management/includes/tasks.confirm.include.php’’

Task creation is now handled in Host.class.php. There are 3 functions for instant deployment, single run scheduled deployment and cron style deployment:

[url]https://freeghost.svn.sourceforge.net/svnroot/freeghost/trunk/packages/web/lib/fog/Host.class.php[/url]
[code]$Host->createImagePackage($taskTypeID, $taskName = ‘’, $shutdown = false, $debug = false, $deploySnapins = true, $isGroupTask = false)
$Host->createSingleRunScheduledPackage($taskTypeID, $taskName = ‘’, $scheduledDeployTime, $enableShutdown = false, $enableSnapins = false, $isGroupTask = false, $arg2 = null)
$Host->createCronScheduledPackage($taskTypeID, $taskName = ‘’, $minute = 1, $hour = 23, $dayOfMonth = ‘', $month = '’, $dayOfWeek = ‘*’, $enableShutdown = false, $enableSnapins = true, $isGroupTask = false, $arg2 = null)[code][/code]

There has been a new class to handle “TaskTypes” (aka download, upload, multicast, wipe, av, etc) and this class reads it’s information from the ‘TaskTypes’ table. You are able to specify custom kernel and kernel arguments per TaskType.

GUI code for Task creation is in HostManagementPage.class.php & GroupManagementPage.class.php
(functions deploy() & deploy_post() handle the calls to the Host functions.

[url]https://freeghost.svn.sourceforge.net/svnroot/freeghost/trunk/packages/web/lib/pages/HostManagementPage.class.php[/url]
[url]https://freeghost.svn.sourceforge.net/svnroot/freeghost/trunk/packages/web/lib/pages/GroupManagementPage.class.php[/url]

Hi.

I’m working with the OP at the same place so I can give you more information:

We have two separated networks which should be served by a single fog server.

I have 3 nics on the fog server

Subnet A (10.10.200.) Subnet B (10.11.200.) iSCSI Network

I have 2 DHCP Servers. Both have option 066 and 067 configured. DHCP Subnet A has FOG_IP_SUBNET_A and DHCP Subnet B has FOG_IP_SUBNET_B Fog works perfectly on Subnet A.

However, today we needed to deploy 84 Machines on subnet B and even though I had access to the webmanagement (through NIC B) and also to the PXEBOOT (as assigned through DHCP B), I couldn’t do neither registrations nor deploy the images. To solve the issue (working against Time), I changed all the configs in the management window and FOG started to operate exclusively on Subnet B. I managed to deploy all 84 Images without problems. Now I would like not to have to change manually everything each time I need to deploy an image in diferent Subnets.

On the old forum I found a topic dealing with this were the OP changed iptables’s configuration to forward requests to NIC A but I’m not sure if that was all he did to accomplish what we also want to do. I also have serious doubts about the new DHCP config that has to be made (should both continue to point to the correct interfaces or should I point DHCP B it to Fog’s Subnet A NIC)?

here what he did:

[code]
/usr/sbin/iptables -A FORWARD -i eth0 -d 192.168.1.15 -j ACCEPT
/usr/sbin/iptables -A FORWARD -s 192.168.1.15 -o eth0 -j ACCEPT
[/code]

I also have some doubts about the risks of forwarding packets like that in the Fog Server because our two subnets work like this:

---- -----Internet Gateway A ----- Subnet A ---------- FOG SERVER NIC A > (limited comunication possible here. Out of our reach and not suitable for Image transfer/deployment ---- -----Internet Gateway B ----- Subnet B ---------- FOG SERVER NIC B

So, basically, they arn’t allowed to comunicate inside our scope but Subnet A can comunicate to Subnet B on some protocols using the gateways (which is by design and won’t be changed as it is out of our reach).

Answering your question, our Switches are all HP Procurves 2650 (Layer 2) and a central HP6100 (which then connects to the gateways) interconnected with gigabit fibre but this seems irrelevant to the case since we need to treat the Subnets as isolated (being able to PXboot from Subnet B using NIC B and accessing the management on both NICs is rather peculiar and I can’t explain it unless both TFTPD and Apache are listening on both interfaces). The bottom problem remains… I can’t register hosts or deploy the image through Subnet B) when FOG is configured as primary on Subnet A. I can however PXBOOT and access the Web management interface

Multicasting is set on the switches or I wouldn’t be able to deploy the images on both Subnets (just not at the same time without changing Fogs configuration)

Thank you for any input

Best Regards

Tony

You are not able to boot and install Windows XP from the TFTP boot menu due to the way ramdisk and memdisk handle the system.

More info here - [url]http://www.syslinux.org/wiki/index.php/MEMDISK#Windows_NT.2F2000.2FXP.2F2003.2FVista.2F2008.2F7_.28NT_based.29[/url]

Seems like the Google Toolbar is causing issues with Internet Explorer. Disabling the toolbar has improved things.

Well, if it’s deploying RAW and you get a bootable image and want to use it… I guess I’d deploy it, verify the hidden 100mb partition was restored by Windows, sysprep it, then upload the image again as Single Partition/Single Drive, and it should be able to resize it as intended and save you a lot of space and deploy time.

Unless I’m missing something or not understanding something else, I think that might work.

If you wanted to be sure, I’d just start with a new image of a fresh Win7 install that had the 100mb partition and verify your fog setup is accepting the Single Partition/Single Drive upload before attempting anything else. It’ll save a lot of time down the road, in my opinion. Once you’ve verified that part is working as intended, it’ll be easier to find any other issues that might occur.

Thanks for the reply. We have chainloading implemented. The problem turned out to be a missing file or files that weren’t copied correctly during the setup phase. Re-copying the files fixed the issue. Thanks again.

You really should be using FOG 0.32 and sysprep’ing your images.

I would be using 1 image for all rooms, as long as they are from the same hardware set.
Simply enable / disable the ‘Hostname Changer’ service per Host.

In regards to the Hostname Changer not working:
[LIST=1]
[]Open or preferably ‘tail’: c:\fog.log
[]Look for: HostnameChanger
[/LIST]
Are there any errors reported? It may take a few minutes for errors to appear.

Adding a row in the images table is not hard. But, there is currently there is no way to determine if the image is empty or not. This will be addressed in coming versions.

In the future, please create your own thread for your questions.

DHCP reservation is acceptable, i personally prefer static IP’s for most servers.

Update: After following your suggestion, I got a step farther.

It was able to detect the hard disks in PXE. I got passed my error.

[S]But now there is another error,[/S]
[S]Error now says : *unable to move /images/dev/000c29769fc5 to images/2k3[/S]

This worked for me, the above issue was not encountered when I ran it on a real server. (Only the VM gave the error)

Thanks Bryce for the assistance… and thanks to everyone who helped FOG become the most awesome tool ever![S][/S]

[quote=“rixter, post: 474, member: 168”]Blackout, are you sure this isn’t an initrd issue? I was thinking I had some issue where I changed out my init file and it took care of something similar to this.[/quote]
No 🙂 Its just my best guess 😛

It could indeed be another issue.