Control: severity 750586 important Control: found 756275 20140802 Ron <ron@debian.org> (2014-07-28): > As discussed on #-boot, here's a minimal patch to fix pxeboot with the > current daily images. Thanks. > This patch possibly also means you can close #750586 and several of > the other bugs referenced there, but my secret decoder ring broke > trying to figure out what his real problem(s) were, so I've kept this > separate to that. I'm lowering the severity of #750586 since I feel important is enough. > > And this bug is unversioned, since it only effects the daily snapshots > after the syslinux update, and the last tagged release was before > that. We have a release with this bug now, so "found"ing it. > On a slight tangent to this: > > I do wonder a little if we ought to rearrange the netboot.tar tree a > bit in the light of this change, since we basically have 3 things there > with varying degrees of interdependence between both themselves and > alternative images that people might want to boot from the same tftpd. > > - pxelinux.0 (and its associated .c32 binaries) > > Since the commonly used way to boot multiple images is to share > this between all of them and then use a custom top level menu to > select the actual tree to boot from, but the .c32 binaries that > we embed in $arch/boot-screens aren't compatible with different > syslinux versions of pxelinux.0. > > So possibly we should pull all the .c32 files out of boot-screens > (and possibly out of $arch too, since they are now all 32-bit ELF > executables even for amd64), and put them in their own tree where > they can easily be shared and be from the same syslinux version. > > - the menu .cfg files > > Which should always be compatible with newer versions of vesamenu.c32 > and really only change when different options are added. They only > depend on a particular kernel and initrd to the extent of: > - the path they expect to find them at > - the options they append for the installer in the initrd. > > In theory, some of these at least could be arch independent, since > it's only the hardcoded paths to the kernel images that make them > not so, and the options they append which may make them release > dependent. > > So possibly these should be split between 'release' and 'arch' > dirs (unless there's some way to make $arch a runtime variable > in which case they may could all be just release dependent. > > - the kernel and initrd images > > Which are obviously arch dependent, but could be updated > independently of the menu files for point releases etc. > > Anyhow, the above is really a separate 'bug', if it's a bug at all, > but I figured I'd mention it here since it is relevant in the context > of the incompatible change to syslinux which this bug is about. I'll > leave it to you guys to decide whether it should be cloned as such, > taken to the list for Further Discussion, or /dev/null'd as SEP :) Thanks for all the details. Since I don't know much about all these things I'm tempted not to touch anything beyond unbreaking netboot.tar.gz; even more so since there seems to be an attached, tested patch. :) I could apply it blindly but it'd be nice if someone else would confirm it works fine. I've got other things cooking, but I might end up testing it myself it nobody steps up. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature