On Tue, Aug 12, 2014 at 02:00:12PM +0200, Cyril Brulebois wrote: > Hi Kim, > > and thanks for your detailed bug report. > > Kim R. T. Hansen <k...@rthansen.dk> (2014-08-12): > > Package: debian-installer > > Version: > > Severity: normal > > Tags: d-i > > > > Dear Maintainer, > > > > * What led up to the situation? > > > > I want to install Debian/testing on a new computer. > > > > * What exactly did you do (or not do) that was effective (or > > ineffective)? > > > > I upgraded the PXE installer for testing using di-netboot-assistant, > > then I tried to install with it. > > > > * What was the outcome of this action? > > > > I expected the installer to run. > > > > * What outcome did you expect instead? > > > > The installer failed with the error "vesamenu.c32 is not a COM32R image" > > (written from memory). > > > > > > When I compare the vesamenu.c32 files in the testing and daily > > installers with the same files from stable and some Ubuntu version there > > are some differences: > > > > * The working files have a size about 150kB and are "COM executable" > > * The problematic files have a size of 26kB and are "ELF 32-bit LSB shared > > object" > > > > This is an example of a good file: > > http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20140316/images/netboot/debian-installer/amd64/boot-screens/vesamenu.c32 > > > > This is a bad file: > > http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20140802/images/netboot/debian-installer/amd64/boot-screens/vesamenu.c32 > > The fact you're using di-netboot-assistant is interesting, maybe it > would have needed an update for the syslinux 6 transition? > > The code can be viewed online here: > > http://anonscm.debian.org/cgit/d-i/netboot-assistant.git/tree/di-netboot-assistant#n236 > > It seems there's some *.c32-specific handling, and there's even a > mention of a (probably previous) transition for menu related files.
I'm not that familiar with the netboot-assistant (read: I didn't even know it existed before reading this :) but from what I gather from its docs it helps automate something I was doing more manually. If the tree that it currently creates is still something like what is shown here: https://wiki.debian.org/DebianInstaller/NetbootAssistant, then yeah, this is basically the problem I mused about in #756275, in the 'slight tangent' about rearranging the tree to move pxelinux.0 and the .c32 files out of the 'release specific' part of it where it could be shared by multiple release images. The problem that Kim describes sounds like pxelinx.0 (<< 5) was run, but then it tried to load .c32 files from a d-i image tree using the syslinux (>= 5) version, and they indeed aren't compatible. I have successfully mixed the newer pxelinux.0 and .c32 versions (from the daily images and with the patch from #756275 applied) with the menu and kernel images from the last released wheezy d-i, and I believe that should also work with earlier images (or those from any compatible derivative distros) too, though I haven't tested those myself. Basically you need to pick the pxelinux.0 and .c32 files from just *one* release (any should do, at least until the menu files depend on some later feature, or some older feature gets dropped, but the latest version you have available is probably the safest to pick), and use those for all of the various menu/kernel release trees you want to make available. Reshuffling the remaining things in the release tree and making a new top level menu of your own as needed. Making that easier to do was what my 'slight tangent' was about. Possibly this means we should actually split the netboot.tar into two separate images now, a netboot-pxe.tar (with pxelinux.0 and the .c32) and a netboot-$release.tar with the menu and kernel/initrd files for the given release. And have those unpack into non-overlapping trees. Then people who want to do this will download just one netboot-pxe tarball, and however many -$release versions they want to support. > I think we would have had more reports if PXE was broken in the general > case so I suspect this might be a regression only in the d-i netboot > assistant case. In the general case, the current released wheezy netboot images are ok when used as a self-contained tree. The daily images, and the new release you are preparing from those, will be broken until the patch from #756275 is applied (for a slightly different reason - that fixes the paths where the ELF .c32 files are expected to be found, which is a new constraint for syslinux >= 5), so you might hear more reports of that soon :) But that can be fairly easily 'hand hacked' by users just moving some files around after installation until the patch is in. It sounds like netboot assistant will need a separate fix to that, to arrange its tree in a way that doesn't try to mix the syslinux files from different releases. Whoever finds time to work on that, might find that much easier to do if they first tease apart the -pxe and -release trees as above in the netboot images themselves. That probably won't be me, at least not for the next couple of months, I'm still swamped for the foreseeable future right now, but I'm happy to stay in the CC for any review or discussion of how that might work best now. If netboot assistant also did the (somewhat tedious to do) job of verifying the signatures on the netboot images it fetches, then it might actually be a better way to do what I'm currently doing 'by hand' :) Cheers, Ron -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812191357.gm6...@hex.shelbyville.oz
