Posts made by george1421

Allow more flexibility in host naming more than static text + number increment.

For example we have a host naming convention like this

SSSTXXXXXXX

Where
SSS = Storage location (3 characters that match computer site OU)
T = Workstation type (D == Desktop, P==Portable/Laptop, T==Tablet)
XXXXXXX = Computer asset tag/serial number

Somewhere I had a hack for FOG 0.32 that allowed me to create this naming structure (but that was circa 2007). I tried to apply the same logic to FOG 1.0 and failed.

As an interim solution I can set the hostname in the unattend.xml file using postinstall scripts, but then I loose out on many of the functions of FOG 1.x. One being that the machine names remain the mac address not the actual asset tag, because FOG is not aware that I’m setting the host name outside of FOG.

Ideally I’d like to be able to set the hostname dynamically (programatically) through the registration process and not have to key the proper name into the system. I will still need to be able to edit the host name in the registration process if we build systems at site A but have the target computers delivered to sales office B.

Add the field names to the export hosts csv file. Add logic to ignore first row on import assuming the first row is the field names.

This is to allow the IT technician to see the expected input information based on the column (field) names. Right now it is not clear what fields (columns) are supported and the expected order for the data to be imported correctly.

Expected workflow: Export hosts to csv spreadsheet (blank or populated), fill in new data in correct column order, and then import the csv.

@Wayne-Workman For some reason I thought it was a copy and delete function that’s why you need 2x free space. But in the OPs case I think something else is going on. I know on one of the early trunk builds FOG was capturing my reference image and then rebooted instead of shut down, but in the OPs case it doesn’t appear that the task was marked complete so on the next reboot it continues to try to capture the image.

@arainero I’m wondering if you could do this as a test.

Upload your image again, but when the system should shutdown or restart, unplug the computer during the bios POST. What I’m interested in seeing is if the task completes AND if the upload is just missing the shutdown command at the end of the image capture. It appears that you tried to capture an image from another machine. What size of image were you trying to capture.

@Wayne-Workman May be you can answer this. It was my understanding that you need to have 2 times the free space of the image you are trying to capture in your /images directory. If the OP has 1.7TB free space and trying to capture a 1.1 TB image, that breaks the rules as I understand them. Is my understanding correct?

I realize there may be a language understanding issue here, but could you explain this statement

i cant register every host to take a image.

Does that mean:

1. You physically can’t register the machines (i.e. fog 1.2.0 is broken)
2. You do not want to register the machines in that volume on a per day basis because it is too labor intensive

Version 1.2.0 is really different than 0.32, its more of a fork of the original FOG project. The newer version of FOG gives IT support much more control over the client than 0.32 ever supported. That additional control does come with some requirements I do have to say. To answer your question, is there a way to make 1.2.0 work like 0.32 does? The short answer is no, but you can get close.

In the FOG PXE boot menu there is an option called Quick image. This is similar to a load and go for deployment. You only need to supply a user ID and password (to avoid unintentional image deployment) and then select the image you want to deploy. This will install the image without needing to register the system with FOG. But by doing it this way you are missing out on a lot of function in the new FOG.

@fredlwal You will need to help us understand a bit more about your network. How is the network (distant) different than the network in the building you are?

Is there a router or firewall that isolates your building network from the rest of the network?

I’m not seeing this issue with my dev server. Can you associate that above error message with a specific action or page?

Also what does top show as the process with the most CPU consumed?

@Tom-Elliott said:

@george1421 It always assumes 32 bit in the browser unless you pass, as part of the url, arch=x86_64

My mistake then, I assumed that it was the other way around. I was trying to draw a connection to this abnormal behavior and the limited insight I had into the OPs environment.

Lets think about this for a minute.

We have an issue with the console, now we have an issue with host registration. Both of these actions require the target device to do something.

I noted the boot.php output and its calling for the 32 bit kernels and inits. That in it self is not strange, but it makes me wonder what is the make and model of computer we are trying to register. I also noted that the DNS reference points to itself (very strange telling a target computer to use itself as a DNS lookup target dns=127.0.0.1). I’m not saying there isn’t something wrong with FOG here, but we ARE talking about 1.2.0 stable and not a trunk release (pre 1.3.0). I would expect 1.2.0 to react in a predictable manner.

@arainero said:

Also, I had a side question. I noticed a new option called “Replicate”, is there any documentation about what it does?

While I can’t answer your question about the image capture, the question about the replicator I can. That option is used to enable / disable replicating newly captured images to other nodes in the storage group. You would use this if you had a quality control or validation process where you wouldn’t want to send an image to the storage notes until it has been verified/approved. Without this option the replicator will send all newly captured images immediately to all nodes in the storage group.

This will sound a bit strange. But from a browser, try to access this page.

http://<fog_server_ip>/fog/service/ipxe/boot.php

That should cause FOG to create the ipxe boot menu. You should see something like that starts like this:

#!ipxe
set fog-ip 192.168.1.88
et fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 && colour --rgb 0x00567a 2 && colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 && cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://192.168.1.88/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0xff0000 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is NOT registered!
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.quickimage Quick Image
item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)

@Mark-Buteyn What is your internet connection speed (up and down)?

(Just trying to draw a connection here) Do you have known intermittent internet access issues? I’m pretty sure they are still using wget to pickup the kernels and inits. I wonder if we added a longer wait time for wget that would resolve (or at least mask) the issue.

Are you still having an issue downloading the kernels with the latest trunk version?

@JTech Any update on this?

@Psycholiquid Any update on this issue?

For the reference image build out, I have our setup configured to build the reference image completely using a single set of task sequences. That task sequence lays down the image (on the reference image) runs the windows udpates, installs office, vc runtime libs, and all of the other applications then runs a final windows update. Without the windows updates I can build the reference image in about 20 minutes. With the windows updates it takes about 14 hours (no problem I just start before I go home). Then once that is done I sysprep the image and capture with FOG.

Now I didn’t mention the drivers. In our case when we setup the reference image, we tell windows to look in the c:\drivers folder for any drivers. Then during OSD (OS Deployment) after FOG lays the image down on the target machine we run a fog postinstall script that picks up the model of computer and then copies the right drivers onto the target computer (c:\drivers). That saves us from having 15GB of drivers (12 Dell models worth) inside our captured image. Our golden image is about 15GB in size using this process. Also we can add new models without having to recapture the reference image. We do rebuild the reference image once a quarter to pick up the latest windows updates and to include updated add on applications (i.e. flashplayer, java, etc.) when required. But with a fully automated reference image build there is no heavy lifting to rebuild the reference image.

It would be interesting to know what if anything is posted to the /opt/fog/log/taskscheduler.log when one of these scheduled events are missed. If its not in there, one might think one of the logs would say what just happened. This is very strange that “nothing” happens.

You might want to check to see if the fog task scheduler service is running. I might be able to understand if the scheduler is not running. The web gui looks at the database where the scheduled task is run. It calculates when it should run and displays that to the user. So the time line is correct from the users perspective. Its just the task never kicks off on the back end. This is all speculation, but it sounds logical.

Bravo, well done. It sounds like you have a grate setup. It sounds like you hit the right combination of networking gear and configuration. I’m a bit surprised that your golden image is 35GB in size. But if you can get that all installed in 25 minutes you have the perfect setup.

Once you main push is over, it would be interesting (take a snapshot first) for you to upgrade to the latest trunk version to see if your performance is comparable. There has been a number of tweaks in the last weeks. Since you have solid baseline it would be interesting to know a side by side comparison.

Either way well done.

I consider this issue resolved. Thank you!!