Package: live-boot
Version: 2.0.15-1
Tags: patch

Hello,

When I try to boot the Debian Live gnome-desktop flavor (6.0.7 netboot),
with the fetch=tftp://... boot parameter, the transfer of the squashfs
image stops after about 640 MB.  The boot process also stops at that point,
with the following display:

     /private/tftpboot/fi   0% |                                |     0   -
stalled -

However, booting does succeed with the standard flavor (6.0.6 netboot),
with the same boot parameters, ending at a shell prompt.

This is the whole list of kernel parameters:
debian-live/i386/vmlinuz-2.6.32-5-686
initrd=debian-live/i386/initrd.img-2.6.32-5-686 boot=live config
fetch=tftp://192.168.1.1/private/tftpboot/filesystem.squashfs  quiet

The archive file is:
http://live.debian.net/cdimage/release/6.0.7/i386/net/debian-live-6.0.7-i386-gnome-desktop-net.tar.gz

The dhcp/tftp servers are bootpd and tftpd in Mac OS X 10.5.8.

The amount of data reached before the transfer stops is about 640 MB.  This
could be limited by the block size times the number of blocks (10240
bytes/block * 65535 blocks = about 640 MB), so a fix might be to increase
the block size, as in the following patch:


---8<---
--- a/scripts/live
+++ b/scripts/live
@@ -784,8 +784,8 @@
                                 ip="$(dirname $url | sed -e 's|tftp://||g'
-e 's|/.*$||g')"
                                 rfile="$(echo $url | sed -e
"s|tftp://$ip||g")"
                                 lfile="$(basename $url)"
-                                log_begin_msg "Trying tftp -g -b 10240 -r
$rfile -l ${dest}/$lfile $ip"
-                                tftp -g -b 10240 -r $rfile -l
${dest}/$lfile $ip
+                                log_begin_msg "Trying tftp -g -b 65464 -r
$rfile -l ${dest}/$lfile $ip"
+                                tftp -g -b 65464 -r $rfile -l
${dest}/$lfile $ip
                             ;;

                             *)
---8<---



65464 bytes/block would be the maximum allowed block size, according to the
tftp(1) manpage.


Thank you,
Edwin

Reply via email to