Bug#750586: Bug#756275: debian-installer: [PATCH] Fix lib location and search path for syslinux = 5
Control: tag 756275 pending Ron r...@debian.org (2014-09-22): On Sun, Sep 21, 2014 at 03:51:52PM -0700, Chris Kuehl wrote: On Sun, Sep 21, 2014 at 01:57:55PM +0200, Cyril Brulebois wrote: Looks like I could just blindly apply both patches, squashing them and crediting both of you then? Yup, I think that would do it. I can do additional sanity testing of the daily build after the patches are applied, but already did pretty extensive testing on the netboot image yesterday with the patches applied. Yeah, that works for me too. I wasn't in a hurry to push this until someone had actually tested the patch either (and I got buried again and didn't get to that myself), but I know that what it was _intended_ to do really works, so if it's been tested now, getting it into the dailies for wider testing seems like a good plan. So Matt Taggart reported this on IRC and this reminded me I had it on my todo list. Pushed to master. Thanks again! Mraw, KiBi. signature.asc Description: Digital signature
Processed: Re: Bug#750586: Bug#756275: debian-installer: [PATCH] Fix lib location and search path for syslinux = 5
Processing control commands: tag 756275 pending Bug #756275 [debian-installer] debian-installer: [PATCH] Fix lib location and search path for syslinux = 5 Ignoring request to alter tags of bug #756275 to the same tags previously set -- 756275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756275 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b756275.141177229113898.transcr...@bugs.debian.org
Processed: Re: Bug#750586: Bug#756275: debian-installer: [PATCH] Fix lib location and search path for syslinux = 5
Processing control commands: tag 756275 pending Bug #756275 [debian-installer] debian-installer: [PATCH] Fix lib location and search path for syslinux = 5 Added tag(s) pending. -- 750586: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750586 756275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756275 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b750586.141177229113889.transcr...@bugs.debian.org
Bug#750586: Bug#756275: debian-installer: [PATCH] Fix lib location and search path for syslinux = 5
On Sat, Sep 20, 2014 at 02:28:24PM -0700, Chris Kuehl wrote: Hi all, Thanks for your work on this -- we're also experiencing this bug in both jessie and sid daily netboot images in our PXE boot environment. On Thu, Aug 07, 2014 at 01:46:06PM +0200, Cyril Brulebois wrote: 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. I might be building the image wrong, No, it looks like you did everything right afaics :) That was a blind and untested patch, working backward from what I'd hand-hacked in place to get it working for me, at the end of a long day, and the first time I'd ever even looked at this code ... It looks like I read $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR) wrong in the surrounding code and assumed BOOT_SCREEN_DIR only had the /boot-screens part in it. Or at least that's the only thing I can think I must have done, since now that you've pointed, and I'm looking at it again, your version of that link definitely looks like the right one to me. Indeed amd64/netboot.cfg has: BOOT_SCREEN_DIR = $(NETBOOT_PATH)/boot-screens/ Only the ia64 version appears to define or use it how I used it there. Thanks for actually testing this and sending a fixed patch! Cheers, Ron but after applying Ron's patch, I get a symlink like the following in my netboot tarball: ldlinux.c32 - debian-installer/amd64/debian-installer/amd64/boot-screens//ldlinux.c32 Note that ``d-i/$arch'' is duplicated, and there is an extra slash before ``ldlinux.c32''. During my build, the relevant vars were: NETBOOT_PATH=debian-installer/amd64 BOOT_SCREEN_DIR=debian-installer/amd64/boot-screens/ I've attached a small patch (intended to be applied after Ron's) which fixes the target path of the symlink on my sid build. With these two patches applied, the sid netboot image boots and installs successfully in our environment. I'd be more than happy to help test any additional work on this issue. Thanks! Chris From 89f74fdc2893a68d2baba8d13cff4846d92840e8 Mon Sep 17 00:00:00 2001 From: Chris Kuehl cku...@ocf.berkeley.edu Date: Sat, 20 Sep 2014 21:00:11 + Subject: [PATCH] Fix ldlinux.c32 symlink path The existing symlink creates a target path like: debian-installer/amd64/debian-installer/amd64/boot-screens//ldlinux.c32 (note the duplicate of d-i/amd64/ and the double slash after boot-screens) --- build/config/x86.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build/config/x86.cfg b/build/config/x86.cfg index 07f99b8..0bcd2a9 100644 --- a/build/config/x86.cfg +++ b/build/config/x86.cfg @@ -393,7 +393,7 @@ arch_netboot_dir: x86_syslinux ln -sf $(NETBOOT_PATH)/pxelinux.0 $(TEMP_NETBOOT_DIR)/pxelinux.0 # This link is required because pxelinux only looks in the tftp root # for this library (it does a PATH search for any others). - ln -sf $(NETBOOT_PATH)/$(BOOT_SCREEN_DIR)/ldlinux.c32 $(TEMP_NETBOOT_DIR)/ldlinux.c32 + ln -sf $(BOOT_SCREEN_DIR)ldlinux.c32 $(TEMP_NETBOOT_DIR)/ldlinux.c32 set -e; \ $(foreach file,$(wildcard $(TEMP_BOOT_SCREENS)/*.txt), \ -- 2.1.0 -- 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/20140921081100.gc32...@hex.shelbyville.oz
Bug#750586: Bug#756275: debian-installer: [PATCH] Fix lib location and search path for syslinux = 5
Ron r...@debian.org (2014-09-21): On Sat, Sep 20, 2014 at 02:28:24PM -0700, Chris Kuehl wrote: Thanks for your work on this -- we're also experiencing this bug in both jessie and sid daily netboot images in our PXE boot environment. On Thu, Aug 07, 2014 at 01:46:06PM +0200, Cyril Brulebois wrote: 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. I might be building the image wrong, No, it looks like you did everything right afaics :) That was a blind and untested patch, working backward from what I'd hand-hacked in place to get it working for me, at the end of a long day, and the first time I'd ever even looked at this code ... It looks like I read $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR) wrong in the surrounding code and assumed BOOT_SCREEN_DIR only had the /boot-screens part in it. Or at least that's the only thing I can think I must have done, since now that you've pointed, and I'm looking at it again, your version of that link definitely looks like the right one to me. Indeed amd64/netboot.cfg has: BOOT_SCREEN_DIR = $(NETBOOT_PATH)/boot-screens/ Only the ia64 version appears to define or use it how I used it there. Thanks for actually testing this and sending a fixed patch! Looks like I could just blindly apply both patches, squashing them and crediting both of you then? It was low-priority (especially since untested) and I wasn't too keen on spending time on it, but if we have success reports, merging looks like a good idea. Mraw, KiBi. signature.asc Description: Digital signature
Bug#750586: Bug#756275: debian-installer: [PATCH] Fix lib location and search path for syslinux = 5
On Sun, Sep 21, 2014 at 01:57:55PM +0200, Cyril Brulebois wrote: Looks like I could just blindly apply both patches, squashing them and crediting both of you then? Yup, I think that would do it. I can do additional sanity testing of the daily build after the patches are applied, but already did pretty extensive testing on the netboot image yesterday with the patches applied. Thanks! Chris -- 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/20140921225152.ga28...@ocf.berkeley.edu
Bug#750586: Bug#756275: debian-installer: [PATCH] Fix lib location and search path for syslinux = 5
On Sun, Sep 21, 2014 at 03:51:52PM -0700, Chris Kuehl wrote: On Sun, Sep 21, 2014 at 01:57:55PM +0200, Cyril Brulebois wrote: Looks like I could just blindly apply both patches, squashing them and crediting both of you then? Yup, I think that would do it. I can do additional sanity testing of the daily build after the patches are applied, but already did pretty extensive testing on the netboot image yesterday with the patches applied. Yeah, that works for me too. I wasn't in a hurry to push this until someone had actually tested the patch either (and I got buried again and didn't get to that myself), but I know that what it was _intended_ to do really works, so if it's been tested now, getting it into the dailies for wider testing seems like a good plan. 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/20140922015553.gd32...@hex.shelbyville.oz
Bug#750586: Bug#756275: debian-installer: [PATCH] Fix lib location and search path for syslinux = 5
Hi all, Thanks for your work on this -- we're also experiencing this bug in both jessie and sid daily netboot images in our PXE boot environment. On Thu, Aug 07, 2014 at 01:46:06PM +0200, Cyril Brulebois wrote: 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. I might be building the image wrong, but after applying Ron's patch, I get a symlink like the following in my netboot tarball: ldlinux.c32 - debian-installer/amd64/debian-installer/amd64/boot-screens//ldlinux.c32 Note that ``d-i/$arch'' is duplicated, and there is an extra slash before ``ldlinux.c32''. During my build, the relevant vars were: NETBOOT_PATH=debian-installer/amd64 BOOT_SCREEN_DIR=debian-installer/amd64/boot-screens/ I've attached a small patch (intended to be applied after Ron's) which fixes the target path of the symlink on my sid build. With these two patches applied, the sid netboot image boots and installs successfully in our environment. I'd be more than happy to help test any additional work on this issue. Thanks! Chris From 89f74fdc2893a68d2baba8d13cff4846d92840e8 Mon Sep 17 00:00:00 2001 From: Chris Kuehl cku...@ocf.berkeley.edu Date: Sat, 20 Sep 2014 21:00:11 + Subject: [PATCH] Fix ldlinux.c32 symlink path The existing symlink creates a target path like: debian-installer/amd64/debian-installer/amd64/boot-screens//ldlinux.c32 (note the duplicate of d-i/amd64/ and the double slash after boot-screens) --- build/config/x86.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build/config/x86.cfg b/build/config/x86.cfg index 07f99b8..0bcd2a9 100644 --- a/build/config/x86.cfg +++ b/build/config/x86.cfg @@ -393,7 +393,7 @@ arch_netboot_dir: x86_syslinux ln -sf $(NETBOOT_PATH)/pxelinux.0 $(TEMP_NETBOOT_DIR)/pxelinux.0 # This link is required because pxelinux only looks in the tftp root # for this library (it does a PATH search for any others). - ln -sf $(NETBOOT_PATH)/$(BOOT_SCREEN_DIR)/ldlinux.c32 $(TEMP_NETBOOT_DIR)/ldlinux.c32 + ln -sf $(BOOT_SCREEN_DIR)ldlinux.c32 $(TEMP_NETBOOT_DIR)/ldlinux.c32 set -e; \ $(foreach file,$(wildcard $(TEMP_BOOT_SCREENS)/*.txt), \ -- 2.1.0
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 r...@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 founding 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. signature.asc Description: Digital signature
