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

Bug#750586: Bug#756275: debian-installer: [PATCH] Fix lib location and search path for syslinux >= 5

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.


> 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.


Attachment: signature.asc
Description: Digital signature

Reply to: