I have been running Clonezilla for several years with few problems. Until now we never needed to PXE boot more than about 8 PCs at once. Now we do. I find that when more than about 10 - 15 come up at once (unsure exactly how many), the later ones will stall. They will get an IP address and a message saying that they are fetching initrd (I think), but nothing will happen until one of the other sessions completes. At that point the stalled machine will start up as normal.
It's acting like the TFTP server is imposing a maximum connection limit. Is this the case? Is there a way to raise the limit?
I'm sorry about the vague error messages. I will be back in front of the environment in a few days and can get more precise info, including screen shots, if desired.
Thanks - Pete
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Is there a way to raise the limit?" -> Not really.
You can debug it by adding the verbose option of tftp server, e.g., for Ubuntu, you can edit
/etc/default/tftpd-hpa
add -v to TFTP_OPTIONS, i.e. mkae it lie:
TFTP_OPTIONS="--secure -v -v -v "
Then restart the service by "service restart tftpd-hpa".
After that, check /var/log/syslog to see if you can find any clues why.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Steven, I just saw your reply. I've made the change and will test it out as soon as I can, hopefully soon.
It's also possible that it's an NFS connection limit issue. I don't remember now exactly where it stalls, during the tftp or NFS transfers. I was debugging another issue and the packet capture indicated that TFTP is only used to fetch a few files. pxelinux.0, menu.c32, libutil.c32, pxelinux.cfg/default, vmlinuz and initrd. That all takes about 30 seconds on our network. Everything after that is pulled via NFS. When I try the connection test again I'll run a packet capture on the server and check. I'll post the results here.
Thanks - Pete
Last edit: Peter Kuykendall 2017-02-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steven -
I have been running Clonezilla for several years with few problems. Until now we never needed to PXE boot more than about 8 PCs at once. Now we do. I find that when more than about 10 - 15 come up at once (unsure exactly how many), the later ones will stall. They will get an IP address and a message saying that they are fetching initrd (I think), but nothing will happen until one of the other sessions completes. At that point the stalled machine will start up as normal.
It's acting like the TFTP server is imposing a maximum connection limit. Is this the case? Is there a way to raise the limit?
I'm sorry about the vague error messages. I will be back in front of the environment in a few days and can get more precise info, including screen shots, if desired.
Thanks - Pete
"Is there a way to raise the limit?" -> Not really.
You can debug it by adding the verbose option of tftp server, e.g., for Ubuntu, you can edit
/etc/default/tftpd-hpa
add -v to TFTP_OPTIONS, i.e. mkae it lie:
TFTP_OPTIONS="--secure -v -v -v "
Then restart the service by "service restart tftpd-hpa".
After that, check /var/log/syslog to see if you can find any clues why.
Steven
Thanks Steven, I just saw your reply. I've made the change and will test it out as soon as I can, hopefully soon.
It's also possible that it's an NFS connection limit issue. I don't remember now exactly where it stalls, during the tftp or NFS transfers. I was debugging another issue and the packet capture indicated that TFTP is only used to fetch a few files. pxelinux.0, menu.c32, libutil.c32, pxelinux.cfg/default, vmlinuz and initrd. That all takes about 30 seconds on our network. Everything after that is pulled via NFS. When I try the connection test again I'll run a packet capture on the server and check. I'll post the results here.
Thanks - Pete
Last edit: Peter Kuykendall 2017-02-03
OK, please keep us posted.
Thanks.
Steven