On 01.07.2015 12:10, Gene Cumm wrote:> On Wed, Jul 1, 2015 at 4:35 AM, poma <pomidorabelisima at gmail.com> wrote: >> >> To remind you once again. >> ISOLINUX >= 6.00 built with GCC >= 5.0.0 causes a broken boot. >> This relates specifically to the use of the vesamenu.c32, >> menu.c32 works without problemos. > > isolinux-debug.bin is not for diagnosing issues with *menu.c32. Let's > start over since your problem statement has a bit of confusion. > > 1) You never said if you saw tests to get just the core (isolinux.bin > and ldlinux.c32) loaded. Did you try my simple config? > > > #syslinux.cfg-begin > DEFAULT linux > PROMPT 1 > > LABEL linux > LINUX vmlinuz > APPEND initrd=myinitrd.cgz my-options > #syslinux.cfg-end >PASSED> > 2) If that passes, the core is OK and let's look at loading simple > COM32s like ls.c32. Does ls.c32 work? >PASSED> 3) If that passes, reading the file system and loading linked > libraries are OK. Next, from a "boot: " prompt with the simple > config, execute "menu.c32" or "vesamenu.c32" >PASSED -and- PASSED Patch, pack and drive! syslinux-6.04-pre1
> On 01.07.2015 12:10, Gene Cumm wrote: > > On Wed, Jul 1, 2015 at 4:35 AM, poma <pomidorabelisima at gmail.com> wrote: > >> > >> To remind you once again. > >> ISOLINUX >= 6.00 built with GCC >= 5.0.0 causes a broken boot. > >> This relates specifically to the use of the vesamenu.c32, > >> menu.c32 works without problemos. > > > > isolinux-debug.bin is not for diagnosing issues with *menu.c32. Let's > > start over since your problem statement has a bit of confusion. > > > > 1) You never said if you saw tests to get just the core (isolinux.bin > > and ldlinux.c32) loaded. Did you try my simple config? > > > > > > #syslinux.cfg-begin > > DEFAULT linux > > PROMPT 1 > > > > LABEL linux > > LINUX vmlinuz > > APPEND initrd=myinitrd.cgz my-options > > #syslinux.cfg-end > > > > PASSED > > > > > 2) If that passes, the core is OK and let's look at loading simple > > COM32s like ls.c32. Does ls.c32 work? > > > > PASSED > > > 3) If that passes, reading the file system and loading linked > > libraries are OK. Next, from a "boot: " prompt with the simple > > config, execute "menu.c32" or "vesamenu.c32" > > > > PASSED -and- PASSED > > Patch, pack and drive! > syslinux-6.04-pre1 >This above statement can be (and is) confusing, just as other prior comments in this email thread can be misinterpreted too. In the official Syslinux code, there is no new patch, and there is no "syslinux-6.04-pre1" yet (and there are several reasons not to release such thing yet, IMHO, but I could understand the reasoning from those that would disagree with me). I am sure more than one of us are thankful for the tests, feedback, reports and suggested patches, but at this point I cannot be sure what exactly has been failing. There has been no %100-clear statement identifying which part of Syslinux was failing: _ isolinux.bin (alone)? _ isolinux-debug.bin (alone)? _ Is syslinux.sys failing (too)? _ Is the problem related to (or triggered by) any of the bootloader files of the Syslinux family? _ Is the problem related to (or triggered by) any of the core modules, i.e. "ldlinux.*"? _ Is the problem related to (or triggered by) any of the c32 modules (e.g. menu.c32, vesamenu.c32, any c32 in particular, all of them)? _ Is the problem limited to a certain firmware architecture? _ Were all the prior combinations tested (including build/host system, BIOS, EFI32, EFI64)? _ Is there a need to patch the Syslinux source code? And in such case, were all the combinations tested? If there is a need to patch the Syslinux source code, an explanation is needed too. I think that saying "it doesn't fail in my test system with such and such changes" is not enough in this case, especially when some prior patch has been mentioned as somewhat related (which is another thing that has not been completely clearly exposed). I do not have the intention to sound rude, so I hope the following comment is not misunderstood. This is the Syslinux Mailing List, and the official source code is not a (rpm) package from Fedora Rawhide while building some ISO image with an auxiliary tool/package. It may result the same for some users / testers, but this is not a general rule, nor the way to test Syslinux (otherwise, when some other user of some other specific distro reports with some problem or feedback, we might be tempted to use the distro's package and build system instead of using upstream official Syslinux source code). In short, I have not understood what *exactly* the origin of the problem was (other than being triggered when using gcc v.5+), and what *exactly* "solved" it (or seemed to) for one particular tester, under a specific environment with one specific test. TIA, Ady.> > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
On Wed, Jul 1, 2015 at 10:14 AM, poma <pomidorabelisima at gmail.com> wrote:> On 01.07.2015 12:10, Gene Cumm wrote: >> On Wed, Jul 1, 2015 at 4:35 AM, poma <pomidorabelisima at gmail.com> wrote: >>> >>> To remind you once again. >>> ISOLINUX >= 6.00 built with GCC >= 5.0.0 causes a broken boot. >>> This relates specifically to the use of the vesamenu.c32, >>> menu.c32 works without problemos. >> >> isolinux-debug.bin is not for diagnosing issues with *menu.c32. Let's >> start over since your problem statement has a bit of confusion. >> >> 1) You never said if you saw tests to get just the core (isolinux.bin >> and ldlinux.c32) loaded. Did you try my simple config? >> >> >> #syslinux.cfg-begin >> DEFAULT linux >> PROMPT 1 >> >> LABEL linux >> LINUX vmlinuz >> APPEND initrd=myinitrd.cgz my-options >> #syslinux.cfg-end >> > > PASSED > >> >> 2) If that passes, the core is OK and let's look at loading simple >> COM32s like ls.c32. Does ls.c32 work? >> > > PASSED > >> 3) If that passes, reading the file system and loading linked >> libraries are OK. Next, from a "boot: " prompt with the simple >> config, execute "menu.c32" or "vesamenu.c32" >> > > PASSED -and- PASSED > > Patch, pack and drive! > syslinux-6.04-pre11) Does this mean my simple config with menu.c32 and vesamenu.c32 passes? 2) Do you still have an issue with your previous config? If so, have you reviewed it to ensure it's syntax looks good? If you're still having issues, could you attach the config file (and any additional config files like those in INCLUDEs and MENU INCLUDEs)? -- -Gene
On 02.07.2015 01:28, Gene Cumm wrote:> On Wed, Jul 1, 2015 at 10:14 AM, poma <pomidorabelisima at gmail.com> wrote: >> On 01.07.2015 12:10, Gene Cumm wrote: >>> On Wed, Jul 1, 2015 at 4:35 AM, poma <pomidorabelisima at gmail.com> wrote: >>>> >>>> To remind you once again. >>>> ISOLINUX >= 6.00 built with GCC >= 5.0.0 causes a broken boot. >>>> This relates specifically to the use of the vesamenu.c32, >>>> menu.c32 works without problemos. >>> >>> isolinux-debug.bin is not for diagnosing issues with *menu.c32. Let's >>> start over since your problem statement has a bit of confusion. >>> >>> 1) You never said if you saw tests to get just the core (isolinux.bin >>> and ldlinux.c32) loaded. Did you try my simple config? >>> >>> >>> #syslinux.cfg-begin >>> DEFAULT linux >>> PROMPT 1 >>> >>> LABEL linux >>> LINUX vmlinuz >>> APPEND initrd=myinitrd.cgz my-options >>> #syslinux.cfg-end >>> >> >> PASSED >> >>> >>> 2) If that passes, the core is OK and let's look at loading simple >>> COM32s like ls.c32. Does ls.c32 work? >>> >> >> PASSED >> >>> 3) If that passes, reading the file system and loading linked >>> libraries are OK. Next, from a "boot: " prompt with the simple >>> config, execute "menu.c32" or "vesamenu.c32" >>> >> >> PASSED -and- PASSED >> >> Patch, pack and drive! >> syslinux-6.04-pre1 > > 1) Does this mean my simple config with menu.c32 and vesamenu.c32 passes? > > 2) Do you still have an issue with your previous config? If so, have > you reviewed it to ensure it's syntax looks good? If you're still > having issues, could you attach the config file (and any additional > config files like those in INCLUDEs and MENU INCLUDEs)? >"PASSED" means *it works* - this is a very standard term. You can find all relevant on the following link: http://goo.gl/Gm4ffO ISOLINUX so you can yourself further analyzed it. There is a bootable/isolinux-6.04 image: Rawhide-Live-Xfce-702-604-boot-only.iso, with the "boot-enable" patch - tantamount to: --- a/com32/menu/readconfig.c +++ b/com32/menu/readconfig.c @@ -299,7 +299,7 @@ char c; while ((c = *src++)) { - if (c <= ' ' || c == '\x7f') { + if (c <= ' ' && c == '\x7f') { ... And that's it. ;) I thank you for your participation.
On 01.07.2015 17:46, Ady via Syslinux wrote:> >> On 01.07.2015 12:10, Gene Cumm wrote: >>> On Wed, Jul 1, 2015 at 4:35 AM, poma <pomidorabelisima at gmail.com> wrote: >>>> >>>> To remind you once again. >>>> ISOLINUX >= 6.00 built with GCC >= 5.0.0 causes a broken boot. >>>> This relates specifically to the use of the vesamenu.c32, >>>> menu.c32 works without problemos. >>> >>> isolinux-debug.bin is not for diagnosing issues with *menu.c32. Let's >>> start over since your problem statement has a bit of confusion. >>> >>> 1) You never said if you saw tests to get just the core (isolinux.bin >>> and ldlinux.c32) loaded. Did you try my simple config? >>> >>> >>> #syslinux.cfg-begin >>> DEFAULT linux >>> PROMPT 1 >>> >>> LABEL linux >>> LINUX vmlinuz >>> APPEND initrd=myinitrd.cgz my-options >>> #syslinux.cfg-end >>> >> >> PASSED >> >>> >>> 2) If that passes, the core is OK and let's look at loading simple >>> COM32s like ls.c32. Does ls.c32 work? >>> >> >> PASSED >> >>> 3) If that passes, reading the file system and loading linked >>> libraries are OK. Next, from a "boot: " prompt with the simple >>> config, execute "menu.c32" or "vesamenu.c32" >>> >> >> PASSED -and- PASSED >> >> Patch, pack and drive! >> syslinux-6.04-pre1 >> > > This above statement can be (and is) confusing, just as other prior comments in > this email thread can be misinterpreted too. > > In the official Syslinux code, there is no new patch, and there is no > "syslinux-6.04-pre1" yet (and there are several reasons not to release such thing > yet, IMHO, but I could understand the reasoning from those that would disagree with > me). > > I am sure more than one of us are thankful for the tests, feedback, reports and > suggested patches, but at this point I cannot be sure what exactly has been > failing. > > There has been no %100-clear statement identifying which part of Syslinux was > failing: > > _ isolinux.bin (alone)? > _ isolinux-debug.bin (alone)? > _ Is syslinux.sys failing (too)? > _ Is the problem related to (or triggered by) any of the bootloader files of the > Syslinux family? > _ Is the problem related to (or triggered by) any of the core modules, i.e. > "ldlinux.*"? > _ Is the problem related to (or triggered by) any of the c32 modules (e.g. > menu.c32, vesamenu.c32, any c32 in particular, all of them)? > _ Is the problem limited to a certain firmware architecture? > _ Were all the prior combinations tested (including build/host system, BIOS, EFI32, > EFI64)? > _ Is there a need to patch the Syslinux source code? And in such case, were all the > combinations tested? > > > If there is a need to patch the Syslinux source code, an explanation is needed too. > I think that saying "it doesn't fail in my test system with such and such changes" > is not enough in this case, especially when some prior patch has been mentioned as > somewhat related (which is another thing that has not been completely clearly > exposed). > > I do not have the intention to sound rude, so I hope the following comment is not > misunderstood. This is the Syslinux Mailing List, and the official source code is > not a (rpm) package from Fedora Rawhide while building some ISO image with an > auxiliary tool/package. It may result the same for some users / testers, but this > is not a general rule, nor the way to test Syslinux (otherwise, when some other > user of some other specific distro reports with some problem or feedback, we might > be tempted to use the distro's package and build system instead of using upstream > official Syslinux source code). > > In short, I have not understood what *exactly* the origin of the problem was (other > than being triggered when using gcc v.5+), and what *exactly* "solved" it (or > seemed to) for one particular tester, under a specific environment with one > specific test. > > TIA, > Ady. >Are there any more questions, "Inspector Clouseau"? :) Perhaps this is actual "problem": 0001-Add-install-all-target-to-top-side-of-HAVE_FIRMWARE.patch 0001-lua-make-kernel-and-initrd-progress-output-match-in-.patch 0002-lua-add-the-IMAGE_TYPE-table-to-the-syslinux-module.patch 0003-lua-share-the-export-macro-CPP-only-change.patch 0004-lua-docs-do-not-reference-removed-example.patch 0005-lua-docs-add-new-bindings-to-syslinux.asc.patch 0006-lua-vesa-delete-stray-would-be-debug-output.patch 0007-lua-docs-bring-documentation-up-to-date.patch 0008-lua-docs-remove-overall-indentation-and-some-verbose.patch 0009-libansi.h-depends-on-stdbool.h-and-stdio.h.patch 0010-lua-docs-loadfile-is-not-TFTP-specific.patch 0011-lua-docs-remove-printf-from-loadfile-example.patch 0012-lua-docs-condense-the-PCI-example.patch 0013-lua-Remove-even-more-cruft-from-syslinux.c.patch 0014-lua-represent-syslinux-files-as-full-userdata.patch 0015-lua-garbage-collect-file-objects.patch 0016-lua-make-the-file-operations-methods.patch 0017-lua-unused-optional-arguments-can-go.patch 0018-lua-make-initramfs-structures-full-userdata-objects-.patch 0019-lua-do-not-leak-initramfs-data-chunks-on-garbage-col.patch 0020-lua-don-t-do-a-local-boot-when-asked-to-final_cleanu.patch 0021-lua-initramfs-enable-adding-nonempty-files.patch 0022-lua-docs-refresh-and-extend-the-documentation.patch 0023-lua-return-the-modified-object-from-the-initramfs-me.patch 0024-lua-move-the-automenu-test-from-the-boot_linux-to-th.patch 0025-lua-simplify-the-function-value-handling-in-the-auto.patch 0026-version-bump-to-6.04-2015.patch 0027-btrfs-Suffix-64b-macro.patch 0028-doc-syslinux.txt-SYSAPPEND-0x20000-FSUUID.patch 0029-doc-syslinux.txt-txt-syslinux.cfg.txt-Adjust-bit-val.patch 0030-libupload-fix-parallel-build-issue.patch 0031-gpllib-fix-parallel-building-issue.patch 0032-com32-parallel-deps.patch 0033-com32-change-llx-to-use-PRIx64.patch 0034-build-sort-sources-to-build-in-a-more-deterministic-.patch 0035-SYSAPPEND-Fix-space-stripping.patch 0036-com32-Use-z-size-specifier-for-printf-ing-size_t-var.patch 0037-txt-syslinux.cfg.txt-Fix-SYSAPPEND-FSUUID.patch 0038-efi-prevent-git-command-in-non-git-tree.patch 0039-efi-prevent-git-command-in-non-git-tree-2.patch 0040-check-gnu-efi.sh-print-the-output-of-build-gnu-efi.s.patch 0041-txt-syslinux.txt-updates.patch 0042-txt-syslinux.txt-once.patch 0043-load_linux-correct-a-type.patch 0044-diag-geodsp-mk-lba-img.pl-misdirects-a-status-messag.patch 0045-diag-geodsp-Update-README-with-a-sample.patch 0046-diag-geodsp-update.patch 0047-diag-geodsp-Makefile-lib-_f-alternate.patch 0048-core-diskboot.inc-spelling.patch 0049-diag-geodsp-Remove-geodsp1s_f.img.xz-image-from-targ.patch 0050-chain-partiter-call-notsane_gpt_hdr-per-header.patch 0051-chain-partiter-add-options-to-ignore-GPT-crc-checks.patch 0052-chain-year-update-in-commments-trivial.patch 0053-com32-lib-syslinux-load_linux.c-update-prot_mode_bas.patch 0054-fix-a-few-typos.patch 0055-add-missing-n-to-dprintf.patch 0056-Use-z-width-specifier-when-printing-size_t-variable.patch 0057-pxe-fix-truncation-warning.patch 0058-gpllib-fix-sizeof-char-misuse.patch 0059-hdt-fix-sizeof-char-misuse.patch 0060-hdt-fix-sizeof-char-misuse.patch 0061-hdt-fix-sizeof-char-misuse.patch 0062-com32-Makefile-additional-dependencies.patch 0063-com32-Makefile-resequence-regroup.patch 0064-ldlinux.c32-SERIAL-directive-Allow-octal-hex-on-port.patch 0065-efi-pxe-Amend-comments-to-clarify-BIOS.patch 0066-efi-pxe-Use-the-appropriate-3rd-packet.patch 0067-efi-pxe-save-MAC-after-parsing-last-packet.patch 0068-core-fs-pxe-dhcp_option-comment-spelling.patch 0069-core-pxe-extend-parse_dhcp-for-packet-type.patch 0070-core-pxe-Don-t-prevent-serverip-override.patch 0071-core-pxe-dhcp_option-Filter-options-based-on-pkt_typ.patch 0072-efi-pxe-Reuse-handle.patch 0073-efi-pxe.c-missing-return.patch 0074-efi-main.c-don-t-close-handle-early.patch 0075-Fix-space-stripping-menu-readconfig.patch What are you waiting? Patch, pack and drive! syslinux-6.04-pre1