Clonezilla 1.2 doesn’t boot from TFTP on FreeBSD

I’ve been banging my head against my desk since I couldn’t get clonezilla to boot anymore after migrating my tftpserver from CentOS to FreeBSD (9.0-RELEASE). Everything seems to boot fine until it tries to fetch the root filesystem. Below is what is seen on the console during the boot process:

IP-Config: eth0 complete (dhcp from 10.1.1.9)
 address: 10.1.1.55   broadcast: 10.1.1.255   netmask: 255.255.255.0
 gateway: 10.1.1.1    dns0     : 10.1.1.9     dns1   : 0.0.0.0
 domain : home.steamr.com
 rootserver: 10.1.1.9 rootpath:
 filename  : /pxelinux.0
Creating /etc/resolv.conf
Begin: Trying tftp -g -b 10240 -r /images/clonezilla/live/filesystem.squashfs -l /images/clonezilla/live/filesystem.squashfs 10.1.1.9 ... ^M /images/clonezilla/l   0% |
tftp: timeout

 .''`.
: :'  :   BOOT FAILED!
`. `'`
  `-      This Debian Live image failed to boot.

Please file a bug against the 'live-boot' package or email the Debian
Live mailing list at <debian-live@lists.debian.org>, m aking sure to note
the exact version, name and distribution of the image you were attempting to boot.

< snip >

BusyBox v1.20.1 (Debian 1:1.20.0-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
(initramfs) _

The tftpboot pxelinux.cfg/default configuration file contains:

label 3
        menu label ^3. Clonezilla Live CD (x86)
        kernel images/clonezilla/live/vmlinuz
        append initrd=images/clonezilla/live/initrd.img boot=live config noswap nolocales edd=on nomodeset ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_keymap="" ocs_live_batch="no" ocs_lang="" vga=788 nosplash noprompt fetch=tftp://10.1.1.9/images/clonezilla/live/filesystem.squashfs

Obviously, tftp works. This is evident by the fact that clonezilla managed to boot and the fact that I was greeted by the pxe boot menu. Furthermore, if I typed in `tftp -g -r /images/clonezilla/live/filesystem.squashfs 10.1.1.9`, I am able to retrieve the filesystem.squashfs file without issue.

Checking the logs on the FreeBSD machine, I see the following:

Oct  3 04:42:34 nas tftpd[38727]: send_packet: Message too long
Oct  3 04:42:34 nas tftpd[38727]: Cannot send DATA packet #1, trying again
Oct  3 04:42:34 nas tftpd[38727]: DATA block 1, attempt 0 failed (Error 40: Message too long)
Oct  3 04:42:35 nas tftpd[38727]: DATA block 1, attempt 1 failed (Error 40: Message too long)
Oct  3 04:42:37 nas tftpd[38727]: DATA block 1, attempt 2 failed (Error 40: Message too long)
Oct  3 04:42:38 nas tftpd[38783]: DATA block 1, attempt 4 failed (Error 40: Message too long)
Oct  3 04:42:41 nas tftpd[38727]: DATA block 1, attempt 3 failed (Error 40: Message too long)

So, obviously, the transfer block size is causing some sort of issue. I spent easily over an hour trying to get it to work using different parameters and different tftpd servers to avail.

My solution is to just use nfs. It’s easier to just use NFS and save yourself the trouble of trying to get it to work. Change the configuration to match the following:

/etc/exports

/tftpboot/images/clonezilla  -network 10.1.1 -mask 255.255.255.0    # or whatever network address you're on. I'm on 10.1.1.0/24

/tftpboot/pxelinux.cfg/default

label 3
        menu label ^3. Clonezilla Live CD (x86)
        kernel images/clonezilla/live/vmlinuz
        append initrd=images/clonezilla/live/initrd.img boot=live live-config noswap <strong>union=aufs netboot=nfs nfsroot=10.1.1.9:/tftpboot/images/clonezilla</strong> ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_keymap="" ocs_live_batch="no" ocs_lang="" vga=788

Then, either start nfs or reload it:

 kill -HUP `cat /var/run/mountd.pid `

Then, try booting clonezilla. If everything’s good, you should be able to boot into it.

2 thoughts on “Clonezilla 1.2 doesn’t boot from TFTP on FreeBSD

  1. Hi Leo,
    I just had exactly the same problem but was not willing to change part of the boot process to NFS 😉 The tftp command issued by clonezilla uses a maximum packet size of 10240 bytes – obviously too much for most networks no matter whether you use standard 1500 bytes or jumbo frames with 9000 bytes in your network. The standard tftpd-hpa config doesn’t specify a max packet size, so it’s using probably the maximum value of 65464. Anyway you should change the tftp server configuration to your MTU minus 32 bytes – e.g. –blocksize 1468. With that the tftp connection does not stall.
    Regards, Torsten

Leave a Reply

Your email address will not be published.