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
