(SNIP)> > 6.03-pre11 EFI64: fails - gets stuck in a loop downloading files - > > differs each boot > > 6.03-pre12 EFI64: fails - downloads /pxelinux.e64 & /ldlinux.e64 - > > then continually retries to download ldlinux.e64 > > 6.03-pre13 EFI64: boots OK TFTP & HTTP > > 6.03-pre14 EFI64: fails - downloads /pxelinux.e64 & /ldlinux.e64 - > > then continually retries to download ldlinux.e64 > > 6.03-pre15 EFI64: fails as per pre14 > > 6.03-pre16 EFI64: fails as per pre14 > > 6.03-pre17 EFI64: fails - downloads /pxelinux.e64 & /ldlinux.e64, also > > then tries to download /syslinux/ldlinux.e64, > > /boot/isolinux/ldlinux.e64, and /syslinux/ldlinux.e64 - then boot > > fails > > -------------------> Please pardon my ignorance; what is "pxelinux.{c32,e64}"?Apologies - I renamed syslinux.efi (for efi32) to pxelinux.e32, and syslinux.efi for efi64 to syslinux.e64...... to keep them all in the same folder. Please see my other detailed reply to this post (reply to Gene Cumm). I realise when I typed out my notes, I've put /pxelinux.c32 - I DID mean /pxelinux.e32 ...... well spotted (but only a typo in the notes!)> Are you testing pre-compiled official upstream binaries? Or are you compiling > you own binaries (and from which source)?They are from https://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.03/> I should guess you are also using (replacing) the c32/e32/e64 files each time, > according to the Syslinux bootloader version too, right? > (sorry to ask, but this is a too-common mistake, and very easy to miss / mess / > get mixed, specially when testing several versions.)Yes - all files replaced from the correct version with each test.> I wonder if some difference in debugging options when compiling (whether > your own binaries, or even the ones HPA made for official > pre-release) could be part of the reasons for the different resulting behaviors.I've not compiled them myself yet. Cheers Andrew
> They are from https://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.03/ > > > I should guess you are also using (replacing) the c32/e32/e64 files each time, > > according to the Syslinux bootloader version too, right? > > (sorry to ask, but this is a too-common mistake, and very easy to miss / mess / > > get mixed, specially when testing several versions.) > > Yes - all files replaced from the correct version with each test. > > > I wonder if some difference in debugging options when compiling (whether > > your own binaries, or even the ones HPA made for official > > pre-release) could be part of the reasons for the different resulting behaviors. > > I've not compiled them myself yet. > > Cheers > Andrew >Although you have not compiled them yourself, there is a chance that HPA used (intentionally or not) different (debug) settings to build different pre-release versions. I could think of another possibility; when building with different (additional debug) settings, some "extra" checks would be additionally used, making the boot process slightly slower (which could, in some potential case, trigger the PXELINUX timeout interval, thus rebooting). I don't know whether using a different file name extension for syslinux.efi (as you did) could also make the boot process slower. While changing the file name of UEFI boot loaders is allowed, I don't know whether there is any influence in the boot process (e.g. searching for expected files in additional paths, taking more time too). BTW, according to the script you mentioned in the other email (in this same email thread), you _might_ be missing some c32 files (e.g. libgpl.c32, libmenu.c32 - which are required for hdt.c32 - and possibly others). Regards, Ady.
> Although you have not compiled them yourself, there is a chance that > HPA used (intentionally or not) different (debug) settings to build > different pre-release versions. > > I could think of another possibility; when building with different > (additional debug) settings, some "extra" checks would be > additionally used, making the boot process slightly slower (which > could, in some potential case, trigger the PXELINUX timeout interval, > thus rebooting).the earlier versions keep retrying to download the ldlinux files... it's not a slow process, looks to me like something thinks it failed to download, so keeps retrying. the later release (pre17) also doesn't hit the reboot timeout or anything - it just fails with 'boot unsuccessful' once trying subfolders etc. only in some of the more recent pre- versions does it start looking through other subfolders on its own accord.> I don't know whether using a different file name extension for > syslinux.efi (as you did) could also make the boot process slower. > While changing the file name of UEFI boot loaders is allowed, I don't > know whether there is any influence in the boot process (e.g. > searching for expected files in additional paths, taking more time > too).up until now, renaming has not caused me any issues - the renamed syslinux.efi files seem to check the same folder for the relevant ldlinux file - so no delay there. all the remaining files are in a subfolder, defined using PATH - so it looks in the correct folder straight away. I did try using just one version (read as: BIOS \ EFI32 \ EFI64) at a time in the base folder with no renaming - and i got the same results.> BTW, according to the script you mentioned in the other email (in > this same email thread), you _might_ be missing some c32 files (e.g. > libgpl.c32, libmenu.c32 - which are required for hdt.c32 - and > possibly others).Cheers Ady - i'd not got round to setting up/testing hdt.c32, was leaving it a little longer before trying it. I've updated my script and will bear that in mind. Andrew