Posts made by george1421

To acquire / steal a post from Sebastian.

“Could you please run a debug session on this device (WebGUI -> Host -> Basic tasks -> Debug) and run lsblk from the command line of the target computer? What do you get?”

We were also focused on the fog version (important to know). What device are you trying to capture (make and model). Does this have a traditional hard drive, ssd, or m.2 SSD drive?

OK now that you are at the latest release the devs can start to work on your issue.

@nbuursma no worries here.

Just change into the directory where you already ran the svn program and it downloaded the files to.

SO assuming if you ran this command to initially download the svn trunk.
svn co https://svn.code.sf.net/p/freeghost/code/trunk /opt/fog_trunk

To upgrade to the latest release you need to do this

cd /opt/fog_trunk
svn up
cd /opt/fog_trunk/bin
./installfog.sh

Then just follow the installer script again. It should pick up your previous settings so you don’t need to answer them again. Once the installer is complete then refresh the fog management page and the number in the cloud should be updated. Just be aware that the git and svn numbers will be different so don’t worry about that what you need is the cloud number.

marking solved.

@nbuursma Well since you are already on a trunk version what did you do to upgrade from 1.2.0 stable? Did you use svn or git?

If you use svn, just change into the trunk directory [FogDirectory] and key in svn up then run the installer again in the …/bin folder.

No worries on being a noob. We all were at one time or another. Just hang in there we’ll get this worked out.

@nbuursma said:

@george1421 … soo…5927?

As Sebastian said, its best if you have problems to upgrade the latest trunk release. The trunk releases are really dynamic as the bugs are squashed. Your version can get stale in a matter of hours. But the more things people run into the better the quality of 1.3.0 stable will be when its released.

Well, I guess I did a cruddy job of explaining what I need. (I’ve been working on this for a while so I left the why out and went right into the how).

I’m working on a fog.postinstall script. I have a situation where i can not use / install the fog service on a target computer for regulatory reasons. To properly set the system host name, product key, ou and a few other variables correctly in the unattend.xml file I need access to them in the post install bash environment.

As a second use case I’m deploying a linux image and I would also like to set a few system parameters post deployment like system name, and a few location specific settings based on the location and deployment node where the image came from. If these variables already exist in the system, is there a way I can find out what they are called without having to reverse engineer the answer?

I’ve also reviewed some of the other scripts in the inits where these settings are derived through one method or another. The idea here is to create a consistent set of post install bash variables that can be use of all post deployment scripts. I was trying to come up with a process that would be easy to implement without much to any recoding required in the inits.

@nbuursma OK, we see you are running 1.2.0. Have you / did you upgrade to the pre 1.3.0 trunk version or did you only install the 1.2.0 base image? The reason why its important is to that the pre 1.3.0 has had many upgrades in the partition table and imaging. If you did upgrade to a trunk version then on the management page for FOG there is a cloud in the upper left corner of the screen. On that cloud there will be a 4 digit number, Tom will need to know that number.

Hi ZINGARO1972 can you provide a little more information here?

What version of FOG are you using?
Are you using a trunk version, if so what number is in the cloud on the management page?
What is the target computer you are trying to deploy to?

I ran into a situation where I need to have access to some of the host, image, location specific information during post deployment script execution. I know what and where things need to be done, but my hacking attempts have failed miserably because I don’t understand the fog data structure and php well enough.

From my testing this is what I can outline.

1. Create a php page that takes the target computer’s MAC address and return a properly formated bash script page that sets the internal fog database value to a bash variable. This could be an actual script that is executed or a list that is parsed and exported to bash environment variables.
2. The output of that php page will be saved to /tmp
3. This would be an example command that needs to be injected into the fog.download script
   wget -q -O /tmp/hinfo.txt "http://${web}service/hostinfo.php?mac=$mac" &>/dev/null
4. In the fog.download script the property info call could be injected here:

if [ -f "/images/postdownloadscripts/fog.postdownload" ]; then
    wget -q -O /tmp/hinfo.txt "http://${web}service/hostinfo.php?mac=$mac" &>/dev/null
    # I still need to work out how to import the hinfo.txt file into bash variables
    # if /tmp/hinfo.txt is a bash script will have to do a chmod to make it executable
    postdownpath="/images/postdownloadscripts/";
    . ${postdownpath}fog.postdownload;
fi

5. The hostinfo.php would export the following FOG variables.
   Image
   ->Name
   ->Operating System
   ->Image Path
   Storage Node
   ->Name
   Hosts
   ->Name
   ->Product key
   ->Location
   ->Domain name
   ->OU
6. Once these are exported to bash variables then they would be available to any subsequent scripts called by fog.postdownload script. I can pick up the rest of the host details from dmidecode so pulling inventory data is not necessary but may be beneficial.

@kenneth.sisco Make sure that your network switches have igmp forwarding or snooping enabled. If you have vlans in your network the igmp settings are typically set on a per vlan basis. The igmp settings allows the switch ports to subscribe to the multicast channel. The multicast stream will only be sent to ports and switches that subscribe to the multicast request. This keeps multicast traffic off switches where there are no subscribers.

@Hanz I would ensure that .Net is at a consistent level for all of your computer fleet before updating the fog client. There are many reasons to take a cookie cutter approach to system images, the primary is “Fix it for one, fix it for all” when trying to repair bugs in systems. This way if you have one system different than the rest you can compare what is different to debug. From the error above it appears that you have .net 4.0 installed on this computer .

Just for reference the above version of .Net [v4.030319] is from 2011, which may explain why the fog client is having a problem on this computer. Somewhere I remember that .Net 4.5 is required by the fog client (@jbob comments?).

@Hanz Do you have the same version and patch number of .Net deployed on all computers? Are you managing this?

In my case, I’m loading the fog client as part of the imaging process. In this imaging process I install .Net into the reference image. That way I know for sure what release is deployed on the client. Then update .Net using WSUS.

If you are going to push out the fog client via GPO (there are better methods, but that is for a different thread) you might want to push out a consistent and known .net version as a prerequisite before updating the client.

@Wayne-Workman If I understand the OP’s post there were two actions that were needed.

1. Since there is a firewall between the two subnets, 2 rules needed to be crafted to allow communication between the devices on the subnet where the fog server was not.
2. On the subnet where the fog server was not he had to update the dhcp to include the next server and boot file settings. On this one I gather (guess) that each subnet has its own dhcp server.

Good job getting this all to work. While its not hard to get it setup across multiple segments there are a few bits that need to be in place.

Marking this issue solved.

@elishasmantle said:

Is it possible, If I have all the images created and stored on a server to have it find a specific image to use for imaging that particular system?

I have written scripts that take advantage of the fog postinstall function that will use the OS utility dmidecode to pick up the model number of the target system and then deploy (push) the correct drivers to a known folder on the target computer. For this to work correctly you need to update your reference image before you sysprep to have windows look in this known folder (c:\Drivers) before it looks at the inf folder for the drivers. I have one image that supports 15 different models using this method (i.e. they are all Dell computers).

The only other caveat I have to say is you need to ensure that you have all required F6 boot drivers install on your reference image before you sysprep it. These drivers are required to boot the system, so there is no chance to pick them up from the disk since the drivers are required to connect to the disk.

here is what I use to pick up the Dell model number

machine=`dmidecode -s system-product-name  | tr -cd '\60-\176'`;

And here is what I use to pick up the Intel NUC and Lenovo model numbers

machine=`dmidecode -s baseboard-product-name`;

@templink This may be a place to start: https://forums.fogproject.org/topic/6348/wrong-ip-on-pxe-boot/9

But I though there was a variable in that file and not hard coded, so I may be a bit confused on this. I’ll have to power on my dev box and see if there is a static value in there.

@templink said:

OK self-resolved.
I modified /tftpboot/default.ipxe and restarted tftpd-hpa service
it’s working now

While its working I wonder how many pains it will give you the next time you upgrade your FOG server. There is a setting inside the FOG management console you need to update. Its in the FOG settings section that has the wrong IP address.

I’m a bit confused on your current setup. Your FOG server IS 192.168.1.1? Where does 192.168.1.207 come into play? It looks like your target computer thinks the fog server is there.