I can confirm the bug with PXE boot. I have a script ran daily in a cron job that mirrors several Debian/Ubuntu netboot directories, sorts them in a "dists" directory by distro/release/arch, modifies paths in the .cfg files to match my tree, and symlinks a couple of files from one of those distros (I chose Debian stable) in my PXE directory to provide the actual PXE boot, with a custom menu to choose between distros (if I'm not mistaken, it's a fairly common use case).
The PXE boot used to work by symlinking pxelinux.0 at the PXE root, boot-screens/vesamenu.c32, and creating a modified copy of pxelinux.cfg/default (again to have the paths match my tree). After Jessie became stable, the PXE boot stopped working with this "failed to load ldlinux.c32" error. Adding "path boot-screens/" to pxelinux.cfg/default and symlinking ldlinux.c32 (amongst other .c32 files) in said boot-screens directory wasn't enough to make it work; I had to additionally symlink ldlinux.c32 at the root of my tree to be able to successfully boot from PXE. I'm no coder so I can't look in the source code and be more precise, but pxelinux.0 behaves as if it ignores this new "path" statement (in pxelinux.cfg/default) regarding ldlinux.c32; but it's still correctly interpreted for other c32 files, since pxelinux is able to find them in the boot-screens directory. Important note : mirroring the Jessie netboot directory to the root of my PXE server (without any modification) didn't work either, since it doesn't have ldlinux.c32 at its root; but netboot.tar.gz has it, so they don't match - I'm not sure it can be considered as a regression (since the netboot directory used to be a working PXE tree regardless of the tarball contents) but I think it may explain why some people report it's now working and others don't. Hope it helps. Regards, -- Raphaël Halimi
signature.asc
Description: OpenPGP digital signature
