On Thu, Feb 18, 2010 at 01:18:01AM +0100, Frans Pop wrote: > So we need to find out why it works so differently for you. I don't think > it's a D-I issue as nothing has changed, and I'd like to rule out that > it's not a local configuration issue before reassigning to syslinux. > > I'd really like to see the log from the tftp daemon with verbose option > enabled. All right, here we go. I attached 3 tftpd logs: p5q.fail boot with P5Q-EM and fresh squeeze netboot.tar.gz p5q.ok boot with P5Q-EM and vesamenu.c32 commented out cuv4x.fail boot with CUV4X-EA and fresh squeeze netboot.tar.gz # md5sum /srv/tftp/pxelinux.0 /srv/tftp/pxelinux.cfg/default /srv/tftp/debian-installer/i386/boot-screens/vesamenu.c32 5154a8b498f13dad5a556951ab769c3c /srv/tftp/pxelinux.0 1cd0d0cbe3ac8d0f695ac2903c8666a5 /srv/tftp/pxelinux.cfg/default 1fe1ac1555cf28b17d8c90e36c92c39a /srv/tftp/debian-installer/i386/boot-screens/vesamenu.c32 The pxelinux.0 md5 equals to syslinux 2:3.83+dfsg-3 pxelinux.0 md5. The vesamenu.c32 md5 equals to debian-testing-i386-netinst.iso vesamenu.c32 md5. Just to be sure my tftp server cannot serve anything different: # find / -name pxelinux.0 -print -o -name vesamenu.c32 -print /srv/tftp/debian-installer/i386/pxelinux.0 /srv/tftp/debian-installer/i386/boot-screens/vesamenu.c32 /srv/tftp/pxelinux.0 Since you said nothing has been changed, I also tested http://ftp.de.debian.org/debian/dists/lenny/main/installer-i386/current/images/netboot/netboot.tar.gz Same behaviour - freeze after loading vesamenu.c32. So, to some extent, I can confirm that nothing has been changed :) Of course, pxelinux.0, pxelinux.cfg/default and vesamenu.c32 have different md5sums. regards Mario -- The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol. -- Larry Wall
Attachment:
signature.asc
Description: Digital signature