@Wayne-Workman said:

This thread has given me the idea to create a migration article. We already have an article for changing the IP address of a FOG Server (in the works). In my opinion, that should just be a sub-section. There should be another section in the same article that talks about moving images and other data over to another server.

The one thing you have to be aware of when you migrate, you have to have the same version of FOG on both sides of the migration. For example if you try to migrate from 1.2.0 stable to 1.2.0 stable, you are pretty assured that the data will migrate without issue. But if you try to migrate from 0.32 to 1.2.0 the migration will fail without question. The same holds true if you try to migrate from 1.2.0 stable to 1.2.0 trunk 5676. (understand this is only used to prove a point). The database has changed quite a bit from 1.2.0 to any one of the trunk builds.

In the case of the OP, I think we need to look into why the database is not exporting and importing as expected. Something is not right here. At the very least we can use the process outlined by Arrowhead-IT to migrate the data. But I have a strong belief that this should be done from within the GUI to keep people out of the underlying OS whenever possible.

This is very, very strange everything should come across except for the physical media. I guess we need to check the apache error log. If you were on rhel it would be /var/log/httpd/error_log. Try the data import and then right away tail the error log and see if the import threw a silent error.

@JDnoble18 said:

@jmeyer What do you mean by remaking images on GUI? Doesn’t import/export take care of this? I’ve already got the images copied over from the old server to the new one, do you suggest deleting the images folder and starting over?

OK, just a second here. You did the export using the FOG configuration right. It should have downloaded a config file (fog_backup.sql) right? Of so open that with notepad++ and look at it. You will see database drops and creates, but there should also be insert into lines. This is placing your data back into the new FOG server. The images and snapin files are different but you should be able to copy the database no problem.

… Just thinking. I wonder if you need to restart the fog service so that it sees the updated data? I’m not sure how much fog caches in memory.

One thing we found is that the default compression for image capture and deploy on the older versions of FOG is level 9 (high compression) Under 1.2.0 (trunk build) is 6 (faster decompression but larger image size on FOG disk).

I did tweak the fog boot menu for fog 1.2.0. My tweak added the pxe menu entry but selecting the quick image just causes the pxe menu to reboot. So no joy for my hacking skills.

2-3 GB/s is not bad, I think I’m getting in the 3GB/s (maybe 4GB/s) for a virtualized server. So what you have today is not bad.

From a performance wise there is not a lot you can do, since the fog server it self is not that busy during OS deployment. It is just moving data between the disk array and the network adapter. Having multiple spindles (disks) on your FOG storage array will help to speed up the disk part of the operation. Using SSD drives for the image and snapin storage would be better, if you wanted to use spinning disk for the OS. The client is doing the heavy processing by decompressing the target image as it is put onto disk. Having a fast disk subsystem and a fast network (LAG group if you will be imaging more than one at a time) .

BUT if you will image more than one machine at a time and they are all the same OS you can use multicasting and upgrade 25 machines at once, only consuming the network bandwidth of deploying 1 unicast image. Moving to 1.2.0 opens new doors for you.

OK rereading your OP multiple times, the first thing you need to get settled is the database export / import. You need to get the settings and passwords into your new system. Without the database the rest of the bits are pointless.

If you are running fog 1.2.0 or a trunk release then there is a built in function to export the configuration from within the gui and then import into your new server. There is no need to use the spiceworks method. That is for the 0.3.x and older release.

GO into the Fog Configuration and select the Configuration Save option that will download the fog_backup.sql to your computer, then go to the new server and upload the settings.

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.