[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#570273: debian-installer: netboot stops after loading pxelinux.cfg/default

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

Since you said nothing has been changed, I also tested
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.

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

Reply to: