Netboot TFTP client is given -b 64540, which is too big, causing failures
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Menu
▾
▴
#282 Netboot TFTP client is given -b 64540, which is too big, causing failures
When you netboot Clonezilla, and don't have a tftpopts variable in your boot parameters, it's given -b 64540 (or some almost 64k number). A relatively new PC I just tried it on fails on that.
The offending script is /bin/boot/9990-mount-http or something.
I fixed it by adding -b10000 as tftpopts, but the default shouldn't be such a big block size.
Thanks. That number is assigned in live-boot package. Of course it would be better to have a boot parameter to change that.
However, we never encounter any issue about this number. Just curious, which TFTP server do you run?
Steven
We use tftpd-hpa 5.2+20150808-1ubuntu3, installed in Ubuntu 17.04. We use it as part of our LTSP (Linux Terminal Server Project).
Thanks. That version should work fine I believe, since we tested that on Ubuntu 17.04.
How did you find the issue is on that number? Because you are the 1st one reporting this issue, and one reason I guess is maybe there is hardware issue there? Like the quality of the cable, or maybe the Linux kernel does not support your network card well. Could you please try to PXE boot different version of Clonezilla live? Like 2.5.3-8 or 20171010-artful:
http://clonezilla.org/downloads.php
They come with newer Linux kernel so the result might be different.
Steven
I booted the netboot, and then it got stalled at 0% downloading filesystem.squashfs, every time I tried. Then I just typed it in the initramfs environment, 'tftp -g -r name host' or something and it downloaded, albeit very slow. So I started grepping around in the scripts and saw that when there are no opts given, it adds that large block size. And indeed, when I tried that on the command line, it didn't download anything either.
I was already biased a bit in that direction, because some googling about tftp stall said that tftp is really bad at large files, and people mentioned the -b option. That, and since it never obtained any byte with the large block size, I don't think it's the cable.
The PC is a few years old, so I doub't newer kernels will make a difference. I'll try to do some tests, but I'm not sure when I'll get to it.
BTW, to get around it, I tried the HTTP fetch method, but that also didn't work. I got weird errors about mount points, something about /live or something? I didn't save them. Nothing in the error message was about HTTP though.
Oh, yes, you can use http service for your client to get the squashfs file. It's more stable. In the "lite server" mode of Clonezilla live, we do use http service instead of tftp service for that:
http://clonezilla.org/show-live-doc-content.php?topic=clonezilla-live/doc/11_lite_server
You can see in the file:
/tftpboot/nbi_img/pxelinux.cfg/default
There is something like:
fetch=http://192.168.120.3/Clonezilla-live-filesystem.squashfs
To isolate this issue, could you please give "lite server" mode of Clonezilla live a try? i.e., run it as the server, and boot your clients with PXE to see if any difference.
Steven
Hmm, that seems kind of involved. I'd have to shut down dnsmasq (DHCP) on our router, for one. There are several networks served by that router, so I don't really want to do that.
I could maye disconnect the PC in question and connect it only to a PC hosting Clonzilla Lite Server, but it's still some work.
I just ran into this same problem. After much head banging, this is what I figured out.
If I manually issue the TFTP command on the client, using "-b 19278" for the buffer size, it would work, but "-b 19279" would not. I think this number has more to do with NIC buffer/driver space than anything else. A different machine with a different NIC may be a different value. Our 64 bit machines digest and use the -b 65454 value without a problem.
The simple solution is to set the maximum buffer space the TFTP Server will negotiate. I appended "--blocksize=1468" to the /etc/default/tftpd-hpa TFTP_OPTIONS variable on the TFTP Server and restarted tftpd-hpa. Now our clonezilla downloads "filesystem.squashfs" using TFTP without a problem.
Great. Thanks for sharing that.
For larger file, actually it's better to run ftp or http as the server, then assign something like
fetch=http://172.17.0.1/path/to/Clonezilla-live-filesystem.squashfs
instead of:
fetch=tftp://172.17.0.1/Clonezilla-live-filesystem.squashfs
Steven
Too bad I didn't save the error, but as I said here, the http method failed. Unfortunately I'm not in a position to test it again right now. Just, FYI.