What gives; Latest kernel and latest HP Core i3 workstation?

[IMG]http://s193925491.onlinehome.us/pix/fog.jpg[/IMG]

So I have been experimenting with limiting the TFTP block size to 1024 but I don’t think it is working. The way I am testing is this: I am observing a normal PXE boot with WireShark and looking at the size.

What I did in an attempt to limit the block size was this:

Edit [FONT=Times New Roman]/etc/default/tftpd-hpa and include [/FONT][FONT=Times New Roman]“-B 1024” under the OPTIONS line so the entire tftpd-hpa file looks like this:[/FONT]

[CODE]# /etc/default/tftpd-hpa

FOG Modified version

TFTP_USERNAME=“root”
TFTP_DIRECTORY=“/tftpboot”
TFTP_ADDRESS=“0.0.0.0:69”
TFTP_OPTIONS=“-s -B 1024”
[/CODE]

What am I missing?

Aha that’s what I suspected; so then even if one decreases the block size of tftp consequently impacting performance that’s negligible since the big transfer goes via NFS and remains unaffected! Thanks for clarifying this,

I also had to troubleshoot the same exact issue with FOG over VPN-connected WAN. My observations were identical in that the tftp would work just fine when used from within Windows 7 tftp client or Ubuntu but would NOT work as part of the PXE tftp download process.

As Chad pointed out the issue is in fact with the block size; my remedy was to adjust the IPsec encapsulation only at the tunnel facing HQ where FOG lives. After the remedy was implemented tftp is slow in loading the boot image; however once the file system is mounted the actual payload - that’s the 15G partition image transfer is VERY fast (the sites are connected to the public Internet via 100Mbps to their respective ISPs) so the only downside is the PXE tftp transfer;

Given my observations I must question whether the payload image transfer is in fact using tftp? Why would then the PXE tftp behave so differently from when the large image is being copied onto the HD?

Just curious since I have encountered this ‘bug’ with the Ubuntu releases all the time:

Instead of restarting with:

[FONT=Consolas][CODE]/bin/sleep 30 && /etc/init.d/tftpd-hpa restart[/CODE][/FONT]

[FONT=Consolas]Isn’t there a way to delay the original start of the tftp daemon with a simple sleep () inserted somewhere in the Ubuntu start up script for all daemons?[/FONT]

The issue that fixed is stupid. In file:

/opt/fog/service/etc/config.php make sure you specify under

[CODE]define( “MYSQL_HOST”, “localhost” );
[/CODE]
NOT an IP address but rather localhost. If you specify IP even if it is the correct IP address the replication service will fail to connect to DB… Go figure

This error is consistent with the new Core i5 HP desktops. It seems that the kernel image can’t detect the Broadcom NIC built into the motherboard.

All is well with non-Core i5 desktops from HP; DELL and 100% of any laptop that I have ever managed to get my hands on. However this newest HP issue is defenitely a problem.

Any clues?

[IMG]http://ikipple.com/resources/IMG_0287.png[/IMG]