Thanks for the reply. The suggestion that you suggest do have a little bit
effect, but do not solve the problem. The kernel image do download to the
client more than before, but still did not load the whole kernel.
Previously before the changes to the in.tftpd argument as per you suggestion,
the client only manage to download through tftp until data block 9, after
the changes, it manages to download through data block 23, and after that
the server will do arp to the network asking where is the client. ( I attached
etherreal capture file with this email. - this one after the changes to the tftpd option )
I try other argument for tftpd -r, still giving me the same problem as before. Only
the -r blksize that download more that the other option.
The thing that baffle me is which part is the problem, coz this happen to the compaq
pc, but not to the other pc. Even though we using the boot floppy and the internal
compaq nic, still it the same problem, trying to use the older ltsp / etherboot version
also giving me the same problem. Which part giving the problem ? the compaq pc ?
dhcp ? or the tftp ?
Thanks for any reply and suggestion. Thanks to other who has giving his / her suggestion
to this problem.
Rgds
Din
p/s there is only one other thing that I haven't try yet.
use the bootable 3com nic that we got from disklessworkstation.
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]">Din,
I've seen a problem in the past, where the kernel starts to
download, and then it stops.
In my case, adding '-r blksize' to the tftpd command line
solved the problem.
Without the '-r blksize', the tftp client and the tftp server
will try to negotiate a blocksize of somewhere around 1500
bytes. This can cause problems, especially if your MTU
isn't set at 1500.
Anyway, adding the '-r blksize' to the server_args line
of /etc/xinetd.d/tftp will cause the tftpd to reject the block
size negotiation, falling back to the old standard 512 byte
blocks.
With the short blocksize, there will be 3 times as many blocks,
but it happens so quickly, it doesn't make that much of a
difference.
Anyway, give it a try, don't forget to restart xinetd, and
report back what the results are.
Jim McQuillan
[EMAIL PROTECTED]
On Fri, 7 Jun 2002, Izauddin Mohd Isa wrote:Hi guys,
This may not be a ltsp problem, but I thought maybe someone might have
across
this problem already.
We are setting up a thin client lab using ltsp 3.0 running on redhat
7.3. Setting up the
ltsp on the server is no problem, but the client cannot boot from the sever.
The client is a Compaq Deskpro SB Evo D380m. It came with a built-in intel
eepro 100 nic. ( the pc have pxe in it ). Since we want to use the
etherboot boot
rom, we install another 3com 3c905B with the 5.0.6 etherboot boot rom in
the
client.
the problem is the boot rom is working well and can detect the 3c905B nic,
search for the DHCP server, connected and get an ip address, after
getting the
ip address and located the kernel file, starting to download the kernel
and it
hang. It hang at the kernel download section ( at the ........ after the
(NBI) .
Running ethereal at the server show that the client see m to lost the ip
address
that it get from the DHCP server, because after the doing tftp to the
client until
data block 9 it stop tftp and doing arp asking where is the client ip
address.
When we try to use a boot floppy, by taking out 3c905B nic it give the same
problem as above. We put another pc ( Dell ) and boot it using the 3c905B or
a boot floppy, it can boot the kernel and ltsp fine.
Anybody have encounter this ? any solution ?
Thanks
Regards
Din
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.openprojects.net
