Posts made by george1421

Be aware that you need the files in /opt/fog too. There are the snapins that need to be moved.

But with your current error it sounds like you don’t have the correct files exported for NFS.

from your new server linux console you want to run the following command

showmount -e <ip_address_fog_server>

That should give you something like this:

Export list for <ip_address_fog_server>:
/images/dev *
/images     *

If it does not then you need to update your exports file.

vi /etc/exports

and add in:

/images *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1,)
/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2,)

Lets take a step back here.

You are doing a p2v migration. What hypervisor are you using? If you are using vmware there is a much easier path, unless you are doing an OS upgrade at the same time.

What was so great about the hack that ended up into the fork of FOG was you had these macro variable you could use to construct your computer name.

PrimaryUser
Other Tag #1
Other Tag #2
System Manufacturer
System Product
System Version
System Serial Number
System Type
BIOS Vendor
BIOS Version
BIOS Date
Motherboard Manufacturer
Motherboard Product Name
Motherboard Version
Motherboard Serial Number
Motherboard Asset Tag
CPU Manufacturer
CPU Version                         
CPU Normal Speed
CPU Max Speed
Memory
Hard Disk Model
Hard Disk Firmware
Hard Disk Serial Number
Chassis Manufacturer
Chassis Version
Chassis Serial
Chassis Asset

These macro variables could be combined with literals and the * to give you a unique machine calculable name. For example in the FOG_QUICKREG_SYS_NAME you could enter something like this. (the syntax is not exact but you’ll get the point)

FOG_QUICKREG_SYS_NAME = “USNYC”{System Type}{System Serial Number}-*

The auto name would be something like USNYCDesktopXXXXXXXXX-01

At the time this function was added to the fog fork there wasn’t storage nodes/groups/locations but I would be great (still wishing here) to add those macro names too.

@jmeyer Your naming would be possible too, just put your room number into the other tag #1 or 2 field. While the devs are not geeked about this feature, I am.

@mitzayapa said:

Ps: what can i make to speed up my deployment speed (more ram ? raid 0 ? 2 nics?)

That is kind of hard to say, since I don’t know your setup or your environment bottlenecks. What is your transfer rate between the server to the client during depolyment (sorry its been many years since I used 0.3x I don’t remember what is avaialble).

Dual or bonded nics will not help if you have only 2 actors in the conversation (i.e. server and 1 target computer) since the bonded nics do not multiplex the data across all links in the bond (actually called a LAG or LAGG). Once a link is selected the conversation between the server and the target will continue to use the selected link during the entire conversation.
If you think about your network as a road way, you have a set speed on the road way. Adding more lanes (nics) only allows you to carry more cars (data) but at the same roadway speed.

The other thing I’ve seen is a slow disk subsystem on the FOG server impact overall speed of the imaging. This is only a guess, but if you are using 0.3.x of FOG that means your server is probably over 5 years old and probably using SCSI u160 or u320 disks. These subsystems had transfer rates in the 40-60MB/s range (about half of GbE ethernet). So even if you have a fast ethernet, you are limited to how fast the fog server can send data stored on its local disk. If you are using a server with a single sata disk, I would expect about the same transfer rates for a single deployment and if you were deploying 2 or more systems using unicast probably I might expect about 10 to 20 MB/s transfer rates.

So if you want to go fast deployment for multiple targets using unicast. Setup a bonded or LAG interface. Use a sata raid controller with 2 or more SSD drives configured with a stripped (raid-0) array, and have great and frequent backups.

I can confirm for sure that the o780 works flawlessly with FOG with dhcp served by MS DHCP server.

While this is probably injecting noise into this thread. We will typically create our reference image on a VM with 1 vCPU and 40GB hard drive. With fog we will use a single disk non resizeable (only because 1.2.0 didn’t work to good with resizeable disks in our environment.) but anyway, in the setupcomplete.cmd file we would run a script to expand the logical disk to the size of the physical disk. It worked well. In this setup we capture the image without the drivers for the final target computer so the image comes in at about 5GB on disk for a thin Win 7 image and about 15GB for a fat win7 image with office and other apps. Then just after the images are laid down on the target computer we use the fog post install scripts to inject the right driver pack from the fog server to the target computer. This saves us about 15GB in space on the target computer that we don’t have to upload (once) and download for each OSD. Also as new hardware is released we just need to update the drivers on the fog server, there is no reason to recapture the image.

Not to over emphasize PDQ Deploy here, but once you get it setup and create the first package (i.e. create a folder in the packages directory, drop in your MSI and if your install requires more steps create and test a cmd file to execute the multiple steps (only required for the free version) plus any additional files and save your package, then pick deploy select the computers out of an AD OU and hit deploy. You can’t do this with a script (well not as easy). You have a install trail with PDQ and can reissue jobs to failed systems all with the free version. The paid for version can do quite a bit more, no scripting required.

This error PXE-E51 is telling me that the client can not contact a dhcp server (period). This can be because its not plugged into the network, or there is something wrong with an upstream connection, or the network port is bad on the mobo. You are not even getting to the kernel part you are stuck at getting an IP address.

I have see traditional spanning tree on a port cause something similar to this. All ports should be configured for fast spanning tree protocol or (I think) RSTP.

If you have a little time the following is well worth the effort to setup. Download and install PDQ Deploy (free). The free version will work for most needs. But I do have to say the paid for features are well worth the small cost.

But setup PDQ Deploy (you will need an admin account for each machine to do this BTW) but create a new package with the old MSI, the new MSI and a batch file. In that batch file run the uninstaller to remove the old client and then call the new msi.

The batch file would do something like this:

@Echo off
msiexec /x “oldclient.msi”
msiexec /i “newclient.msi”

and that’s it. For the package you will include all files and then for your deployment you can select all computers in an OU or add them one by one. Either way. When you execute the job you will get a list of successful completions and a list of failed units. You can address the issue with the failed units and reapply the package to just the failed systems. This way you know for sure what clients got upgraded and which ones you need to visit.

@Sebastian-Roth said:

Then run dmesg | grep -i eth and lspci (full output of Ethernet controller so we might see if it is really using tg3). Thanks!

I’m sure a few commands hard coded into a menu selection like this would be handy to have, especially if they were in the FOG advanced menu so a user could just run them upon request of a a dev.

First of all I have to say, well done!! This fix worked so well back in the day.

The thought was if the machine name is machine calculable as in our case, why not allow it in 2.0? I can do this today with my script (which I don’t use because I loose FOG functionality). But if the registration process would prepopulate that field based on a formula then all would be right with the world.

Truthfully what we do today is a bit manual but it works. We key in the site OU, D, P, T, or what ever then use a barcode scanner to read the asset tag from the back/bottom of the dells. It does work, but it also the posibility for error and does make extra work.

I understand what you are staying about just importing from a database, but then we have to collect the machine information key/scan it into a database, export and then upload info FOG. This seems like too much work for something that can be done is milliseconds on a computer, and not leave room for the IT tech to make a mistake.

Well that’s one win for the day. Good going…

@jmeyer ok then your updater probably knows how to find the internet (thinking that you missed telling apt-get do not use proxy).

I wonder if there is an install log somewhere that will give us a clue to what its missing. I do remember that there was an issue a few weeks ago about a php module not being found. But I don’t call how we found that it was missing.

@jmeyer Ok so then lets try something simiple.

apt-get install wget

I know that wget is installed, I want to see that the installer tells you it is already there.

Ok just so we are clear.

What OS are you using for your FOG server?
What SVN are you trying to install?
What version are you trying to upgrade from?

@Tom-Elliott Looking back over this thread I have a question for Tom, actually a confirmation is all I need. Does image deployment use NFS to move the file from the server to the client?

@stowtwe You have done tests with ftp and iptraf which received expected results. Did you do those tests between the FOG server and the same network jack where these target devices are connected?

Lastly, we haven’t considered that both the OP and Tom is right. Lets assume that for some reason the target computers are only functioning in 100Mb/s mode instead of GbE. This would make both people correct. With an unmanged switch it would be difficult to tell, maybe from the lights on the front of the switch.

Something else to consider is just change out the switch to a different model to see if there is something in the switch going wrong.

[Edit] I see that Tom was thinking along the same lines as it could possibly be the nic too. it just took me a bit for my last post [/Edit]

Ok from what I understand your fog server is behind a proxy server, right?

If that is the case you need to set (export) the environment variables to define your proxy server. Also you will need to update the settings in /etc/wgetrc (if you forget this you will not get the kernels and inits).

As I see you are using svn then you probably have the proxy servers set in /etc/subversion/servers

Here is what I have exported in /etc/bashrc

export http_proxy=http://<proxy_server_ip>:<proxy_server_port>
export https_proxy=http://<proxy_server_ip>:<proxy_server_port>
export ftp_proxy=http://<proxy_server_ip>:<proxy_server_port>
export no_proxy=<fog_server_ip>

You didn’t happen to mention what OS you are using here for rhel based (rpm/yum) you need to update /etc/yum.conf with your proxy server setting too.

While I’m not the sharpest tool in the shed, but wouldn’t this imply that the OP has the right settings for dhcp?

When I try to pxe boot, I am getting the message “Could not start download: Operation not supported (http://ipxe.org/3c092003)”

If the OP is getting a warning message that indicates “ipxe.org”, it would seem that the ipxe boot file [udnionly.kpxe] made it to the target computer, since the PXE boot loader doesn’t know anything about ipxe? and ipxe is generating the error.

OP are you getting any bits of the boot menu? Maybe a screen (mobile phone) shot of the boot screen might give an indication of the root of the error. The error basically says you tried to use a protocol that isn’t supported by this ipx kernel. This is not something that is in the OPs control.

@Sebastian-Roth (I meant to check this before I left the office today, so I’ll have to ask)

If we boot into the debug console, can we get a list of 'in memory" drivers, and/or are the drivers built into the kernel or are they loaded at boot time “modular” drivers. If they are modular drivers we should be able to navigate to the network drivers directory and see the tg3 driver.

I know back in the day when I was building the 2.4.x series kernels for that embedded device company, they had the tg3 network drivers in their build. SO those drivers have been around for a while.

Since this thread wandered a bit, I’m not sure if we really know the root cause here. I understand upgrading to the latest trunk, and then changing the boot menu and changing it back resolved the issue. But its not clear where the issue was introduced.

I guess we will have to just keep this in mind as/if others come across the same problem.

Thank you for reporting back on a solution.