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.

@stowtwe said:

@Wayne-Workman
@george1421

I have an image with compression at 0 or 1 (I can’t recall what it was for sure), and an image with compression at 3, but both have about the same speeds. I have also tried compression 9 just to try the other side of things, and unsurprisingly, things were much slower.

Just to be clear here, an image with compression of 0 or 1 gave the same transfer speeds as a 3 or 9? I just want to make sure we are not chasing the wrong assumption.

In short there are two ways to go about it.

1. If using LVM you can either add a new virtual hard drive to the vm and then attach it to the LVM device, then expand the file system to the size of the new LVM device.

2. Create a new virtual disk large enough to hold the entire content of the /images folder + what ever new space you need, copy all of the existing files in /images to the new disk and then mount the new virtual disk over the /images folder.

If you go for the first option there is still a risk of filling up the boot partition, which is not a good thing for linux. The second option puts all of the big files on its own (virtual) disk. Filling up this disk will not crash the OS since the root partition is on the original vmdk file.

I would hope with FOG 2.0 comes out there are recommendations to have a root partition and a data partition. Just a reminder the snapins are also stored on the root partition.

Can you give us a better idea of your environment?

1. What version of fog are you using? (i.e. 1.2.0 stable, or a trunk version, if trunk then what is the number in the cloud on the login page.
2. What host OS are you using.

Are you seeing the ipxe FOG menu at all? I’m a bit confused since you mentioned invalid password and tftp together. Tftp doesn’t use passwords, thats why its trivial. If you are not getting the ipxe boot menu then what is the PXE error message?

OK on my clean build of 1.2.0 the compression settings are 9

On my production instance that is on 1.2.0 trunk 5070 the compression is 6

On my dev instance that is on 1.2.0 trunk 5676 the compression is 6 (must be default) because I know I haven’t tweaked this system.

Changing this now shouldn’t have an impact since the image that is captured already will be compressed at the higher value. Something I don’t know is where does the decompression happen, I’m suspecting the client computer. If that’s the case the slower (cpu wise) the computer is the slower the transfer rate will be.

@Wayne-Workman mea culpa, I stand corrected

@stowtwe I’m not sure the trunk version will help you with this one.

Looking at your max clients, I’m surprised that it is two. On the default install of 1.2.0 from yesterday this value is 10.

@Wayne-Workman in version 1.2.0 there isn’t a compression setting from what I can see in 1.2.0 stable. So what ever the default value is, is what it is.

@stowtwe Thank you for the details. I see that you are using the 1.2.0 stable version and not a trunk (pre1.3.0) version. Is that correct?

We may need to get one of the devs to verify, but image deployment (partclone) should use nfs to move files to the target computers. Your testing with iperf and ftp show that the computer is capable of transferring at wire speeds (I would expect 50MB-80MB would be your cap because of internal computer restrictions. The 125MB/s is a theoretical max for GbE network).

So I wonder if there are inefficiencies for NFS on your version of debian. (sorry rhel person here) Isn’t wheezy a bit old?

@Quazz said:

There is a new setting called bitrate for storage nodes in trunk version of FOG that may be missing a zero (I do not mean replication bandwidth)

First the simple answer. The bitrate is only for moving files/images between the master node and a storage node. Not between the fog server and the target computers.

@jmeyer said:

I found something else.
In the MSI détails, I don’t have the right version displayed.
It’s write : {16B0BCD7-423F-49A9-B757-E457D7312A33}

I agree it would be great to have the version number on the MSI. I was just trying to figure out what version of the MSI I had in my MDT deployment. The version number would be handy to have instead of a GUID string.

Well I guess I need to amend the request to only support machine based automated naming convention.

The old 0.29 hack method allowed me to enter system variable names in the auto naming edit box to allow me to construct the machine calculated name. You can see the allowed variable names in the one link I posted.

@Arrowhead-IT I started putting together a how to last week so @Wayne-Workman can create a wiki page. Let me get a link to that document.

Here is the outline. Both methods work. I wrote the document from a brain dump, so the instructions may have a few kinks but it does work.

https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog

@Andrew-Single If your fog servers are behind a proxy server let me know there are a few steps you need to do to have a successful upgrade to the SVN trunk.

@Arrowhead-IT Hey, just wanted to let you know this is all great information. The more details the devs have the better solution they can come up with. Its impossible to have every bit of hardware in the test lab that exists in the wild. So it is key to get support from the user community to help build a better mousetrap.

@Tom-Elliott Is that info posted somewhere for historical/debugging reference in a non-volatile location?