[quote=“Frank, post: 42124, member: 691”]
Uploading an image, progress bar does not show actual progress.
[/quote]
The progress bar on the web interface shows the progress of the current partition. It might seam like it’s “wrong” if you think it shows the overall progress.

[quote=“Frank, post: 42124, member: 691”]
When upload finishes, image is not moved from /images/dev to /images
[/quote]
Check the access rights of those directories on the FOG server. From time to time I do see this on our server too. But as I move and rename it everything is fine.

[quote=“Frank, post: 42124, member: 691”]
Even if you copy it to /images with the adequate name, when you try to download it you get the message “you must first upload an image…”
[/quote]
Access rights!?! Please take a look at the images on the web interface after moving it to ‘/images’. “Size on Server” ought to be non zero!!

I wonder if this is still an issue?? My colleague told me about some kind of issue with missing hosts (empty hosts page, although they’re all in the database) when he tried to upgrade to 300X today. I didn’t have the time to look into this, So I am wondering if this is still an issue in current SVN…

Feed this error into any search engine and you’ll get a multitude of explanations on how to fix this, e.g.:
[url]http://www.phpro.org/articles/Database-Connection-Failed-Mysqlnd-Cannot-Connect-To-MySQL.html[/url]

Yes I think Tom is right. You need to have a look at your network configuration. I’d suggest to have the config ‘/etc/network/interfaces’ like this:
[CODE]auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0[/CODE]
You don’t need the gateway statement if you are in an isolated network without connection to the internet. [B]Please make sure you have ‘eth0’ and ‘lo’ configured as some linux services really need that loopback interface!!![/B]
Reboot your machine and check your network settings:
[CODE]# ifconfig
eth0 Link encap:Ethernet Hardware Adresse 00:1f:16:0c:32:50
inet Adresse:192.168.1.1 Maske:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
…
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metrik:1
…[/CODE]

Maybe you can try to capture all traffic between server and client to see if kernel and init.xz are being transfered:
[CODE]# tcpdump -i eth0 host 192.168.1.11[/CODE]
You should see HTTP requests as well as TFTP requests.

I had a problem with a misspelled option in the ipxe menu. To find out what was wrong I needed to take a video because the error message came to the screen only for a split second. Pausing the video I was able to figure out what was wrong…

I guess you’re using resizeable image type, right? As Junkhacker said, please see if the disk has been initialized after FOG went through without imaging. Boot up the client in debug download session and run:
[CODE]# sfdisk -d /dev/sda
…

fogpartinfo --list-parts /dev/sda

…[/CODE]

See what it says before running FOG (start ‘fog’ as a command) and after it went through…

I’ve not heard about switches only passing files matching any sort of pattern (e.g. “*.0”) but you can still give it a try by renaming or linking ‘undionly.kpxe’ to ‘pxelinux.0’ (very common name).

But I have heard about layer 3 switches doing some kind of magic like not forwarding but only relaying DHCP offers…

[quote=“haste347, post: 41989, member: 28447”]
Chain INPUT (policy ACCEPT 714K packets, 82M bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 27794 packets, 4641K bytes)
pkts bytes target prot opt in out source destination[/quote]

No iptables rules loaded and default policies set to ACCEPT. I doubt that a local firewall could be the issue.

What’s happening when you start the hardware inventory task? Does the client boot up in PXE and then…? You should see this on the screen after the kernel loaded:
[CODE]* Using disk device…

• Starting host registration…[/CODE]
  Do you get this far?

[quote=“Just10, post: 41995, member: 28415”]after typing that… I realize the image is probably larger than 40gb. If our techs put 40gb drives in these machines - I have a bigger problem.[/quote]
So is this causing the problem in your case??

Maybe we have another weird issue with partprobe again. Please run another debug download session. Type ‘fog’ and hit Enter till you see ‘Mounting File System . . .’ then press Ctrl+C to get back to the console.
[CODE]# dd if=/images/d1.mbr of=/dev/sda
…

fogpartinfo --list-parts /dev/sda

…

ls -al /dev/sda*

…

partprobe /dev/sda

fogpartinfo --list-parts /dev/sda

…

ls -al /dev/sda*

…
hdparm -z /dev/sda

fogpartinfo --list-parts /dev/sda

…

ls -al /dev/sda*

…[/CODE]
Sounds weird but I had a disk where device files were “missing” after running partprobe…

[B]By the way, which version of FOG are you running, Jeff??[/B]

Is your TFTP server really running and listening on the FOG server?
[CODE]netstat -antup | grep “:69”
udp 0 0 0.0.0.0:69 0.0.0.0:* 10149/in.tftpd[/CODE]

If yes there probably is another firewall is involved. Any router/firewall/layer-3 switch between client and FOG server??? How are client and FOG server connected?

How many clients? Did you try different clients? Just two as a start…

Is unicast fast with each and every single client?

From my experience multicast just does NOT work if configured incorrectly but it wouldn’t be a bottleneck. Please correct me if someone has got a different voice on this.

Maybe this is of any help too: [url]http://fogproject.org/wiki/index.php?title=Troubleshooting_a_multicast[/url]

TFTP configuration is under /etc/default/tftp-hpa (maybe a little different on Ubuntu but should still be in that directory!):
[CODE]# /etc/default/tftpd-hpa

FOG Modified version

TFTP_USERNAME=“root”
TFTP_DIRECTORY=“/tftpboot”
TFTP_ADDRESS=“0.0.0.0:69”
TFTP_OPTIONS=“-s”[/CODE]
Maybe firewall rules prevent you from connecting via TFTP from the outside?! Please post the output of the following command run on the FOG server:
[CODE]iptables -L -n -v[/CODE]

How does your partition layout look like? Please run this command on one of your clients (e.g. bootup in debug mode):
[CODE]sfdisk -d /dev/sda[/CODE]
Which files do you have on your FOG server?
[CODE]ls -al /images/DellAllinOne8GBWIN764[/CODE]
What image type is configured? Single Disk Multiple Partitions?

Thanks for the update. That’s really weird and I still can’t get my head around what’s going on there. As I said, I’ve tried to reproduce the issue but I just can’t do it. Very special. Would be great if you keep us posted on new findings.

Usually a switch operates on OSI layer 2 and there should be no need for DHCP relaying if all hosts are on the same subnet. But there are a lot of so called layer-3 switches around these days and I don’t really know about all that special stuff they do!
Anyhow, great if you got it running now. Let us know about the details of you understand why because it could be helpful to someone else too at some point.

This is untested and probably not supported but you can give it a try. You’ll find that file in ‘/var/www/fog/service/ipxe’ (this is in version 1.2.0, hope it hasn’t changed).
[CODE]# cd /var/www/fog/service/ipxe

gunzip init.gz

mkdir original

mount -o loop init original[/CODE]

Now you can see and change the files in init.gz. But to increase the size you’d have to create a new one. So check the size of the old one first, create a new bigger one, mount that and copy all contents:
[CODE]# df -h
…
/dev/loop0 57M 49M 4.7M 92% var/www/fog/service/ipxe/original

dd if=/dev/zero of=new.img bs=1M count=100

mkdir new

mount -o loop new.img new

df -h

…

rsync -av original/ new/[/CODE]

[B]Make sure that you have the slashes right when running ‘rsync’ or you’ll end up with a broken directory structure inside the init-file.[/B]
[CODE]# unmount original

unmount new

mv init init_original

gzip init_original

mv new.img init

gzip init[/CODE]

Try booting your clients…

Any error messages when you try the other boot menu entries? We need more information on what exactly does not work to be able to help you.

Maybe the ISO files are not in place!? Or those ISO files might be corrupt… Could be anything, really. Please give us some more details.

To me this sounds like the new switch is not properly forwarding all DHCP options send by the DHCP server. Some foo magic?? Maybe check for some kind of ‘IP helper settings’. Best way to debug this would be to use a HUB to connect between switch and client. Conect another computer with that HUB to capture the DHCP traffic and compare the DHCP offer packets coming from 2425/A5120-EI.

If you don’t have a HUB handy you could also just connect the capture PC to the switch and request an address from the DHCP server. Again capture the DHCP traffic and compare the packets. Keep your eyes open for ‘next server’…

Which DHCP Server do you use? The one configured by FOG or a different one. Here is an interesting post on missing ‘next-server’ DHCP option: [url]http://comments.gmane.org/gmane.network.ipxe.devel/3529[/url]

And here is another one on wrong scope: [url]https://communities.vmware.com/message/2139349[/url]

Please provide some more information about your setup and which DHCP server is used (plus configuration…).