On Sun, Dec 2, 2018 at 12:32 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote:> > > > When booting in UEFI x64 mode in your next test, you should see a boot > > > menu. > > > > Nope: > > > > *** Press enter to boot the default label *** > > Failed to load libcom32.c32 > > Failed to load COM32 file SYSLINUX/EFI64/vesamenu.c32 > > boot: > > > > > I'd like to ask you to test all the entries in the menu and > > > report the results for each. If, instead, the boot menu does not show > > > up, we need to know the details / results too. > > > > > > A minor detail (that might be relevant for your report): we are > > > defining a TIMEOUT of 10.0 seconds. When you select "lslabel", the > > > result should show up on screen during those 10.0 seconds (unless you > > > press 'enter', or some other key, before that time), and then the boot > > > menu should show up again. The same goes for "pwdlabel". So, if you > > > want to take note of the results of each entry and you hadn't have > > > enough time, then, while in the boot prompt, simply press the "left > > > arrow" (or "cursor") key once and then the "right arrow" key once, or > > > change the TIMEOUT value, or select the same menu entry again from the > > > boot menu. IOW, the TIMEOUT value is relevant not only when the boot > > > menu is displayed on screen but also when the boot prompt is awaiting > > > some initial input. > > > > I #disabled the timeout so that it wouldn't keep cluttering the screen > > when I was trying to take notes. > > > > at the boot: prompt, hit tab, enter the 3 ... > > > > boot: > > lslabel pwdlabel mylabel > > boot: lslabel > > [dir] [dir] SYSLINUX LDLINUX.E64 > > [dir] . BOOTX64.EFI SYSLX64.CFG > > boot: pwdlabel > > /EFI/BOOT/ > > boot: mylabel > > (linux boots) > > > These are _not_ bad news. > > The two c32 modules that don't need additional module libraries are > working correctly (i.e. they execute with no errors, and the result is > what we expected). > > Since vesamenu.c32 requires additional c32 modules to work, there are 2 > methods to solve the problem. > > For a customized, personal use, the solution is simple. But since the > intention is to send a patch for Debian, we cannot take the "simple" > solution.yep.> > > Now, in spite of what you already attempted (that you wrote in another > email) regarding the PATH directive, we are going to edit > "target/EFI/BOOT/SYSLX64.CFG": > > ### EFI/BOOT/SYSLX64.CFG start ### > > # Note that the path starts with NO slash > # and ends with a slash > PATH SYSLINUX/EFI64/ > > UI SYSLINUX/EFI64/vesamenu.c32 > DEFAULT lslabel > PROMPT 1 > # TIMEOUT 100 > SAY *** Press enter to boot the default label *** > > LABEL lslabel > COM32 SYSLINUX/EFI64/ls.c32 > > LABEL pwdlabel > COM32 SYSLINUX/EFI64/pwd.c32 > > LABEL mylabel > LINUX /linux > INITRD /initrd.gz > > ### EFI/BOOT/SYSLX64.CFG end ### > > > Since we are troubleshooting, we want to delete anything that could > potentially cause some strange behavior (whether expected, or because > of some (un)known bug). And so, I'll ask you to delete (at least for > now): > > _ target/EFI/BOOT/SYSLINUX.CFGI don't think that exists? (see list below)> > _ target/EFI/BOOT/SYSLINUX/EFI64/ldlinux.e64rm $target/EFI/BOOT/SYSLINUX/EFI64/ldlinux.e64 rm -f $target/ldlinux.c32 rm -f $target/ldlinux.sys I just noticed those 2 files that were added by syslinux -i boot.img (right?)> Before performing the test (the same as I requested in my prior email), > please double check that all the syslinux-related files are originated > from the following binary packages: > > _ syslinux-common_6.04~git20171011.af7e95c3+dfsg1-5 > > _ syslinux-efi_6.04~git20171011.af7e95c3+dfsg1-5 > > > Since you have been mixing binaries from several different sources / > builds / versions in your prior attempts / scripts, it is very > important that you triple check that the binary files you are using now > (in your "target" device/image) are exactly those I just posted. These > packages are from current Debian "Testing" repo. >I'm pretty sure everything is coming from testing: juser at dc10b:~/temp$ apt-cache policy syslinux syslinux-efi syslinux-common |grep 500 *** 3:6.04~git20171011.af7e95c3+dfsg1-5 500 500 http://deb.debian.org/debian buster/main amd64 Packages *** 3:6.04~git20171011.af7e95c3+dfsg1-5 500 500 http://deb.debian.org/debian buster/main amd64 Packages *** 3:6.04~git20171011.af7e95c3+dfsg1-5 500 500 http://deb.debian.org/debian buster/main amd64 Packages Is there any way to check versions of what ends up on the image? I do see 6.04 here: + dd if=/dev/zero of=boot.img bs=100M count=1 1+0 records in 1+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 0.999141 s, 105 MB/s + /sbin/mkfs.msdos boot.img mkfs.fat 4.1 (2017-01-24) + syslinux -i boot.img + qemu-system-x86_64 -m 512 -drive file=disk.cow,index=0 -drive file=boot.img,index=1,format=raw,if=none,id=thumb -device ide-hd,drive=thumb,bootindex=1 http://imgr.sytes.net/a/qemu5.png> > BEWARE: > We are about to use the PATH directive. This PATH directive has > several issues, inconveniences, shortcomings, and bugs. Hence, the next > test _might_ "fail" to show the boot menu. According to (or depending > on) your next report, we might need to perform some minor adjustments. > IOW, if your next test fails, don't worry and report the results as > accurately as possible. >report: using this code: https://salsa.debian.org/debconf-video-team/ansible/blob/05480062710486be6b5f5501f560ce3552e87c99/usbinst/uefi/build_uefi.sh Undef symbol FAIL: memset everything else is the same as before: http://imgr.sytes.net/a/qemu4.png target ??? EFI ? ??? BOOT ? ??? BOOTX64.EFI ? ??? LDLINUX.E64 ? ??? SYSLINUX ? ? ??? EFI64 ? ? ??? cat.c32 ? ? ??? chain.c32 ? ? ??? cmd.c32 ? ? ??? cmenu.c32 ? ? ??? config.c32 ? ? ??? cptime.c32 ? ? ??? cpu.c32 ? ? ??? cpuid.c32 ? ? ??? cpuidtest.c32 ? ? ??? debug.c32 ? ? ??? dhcp.c32 ? ? ??? dir.c32 ? ? ??? dmi.c32 ? ? ??? dmitest.c32 ? ? ??? gfxboot.c32 ? ? ??? hdt.c32 ? ? ??? hexdump.c32 ? ? ??? host.c32 ? ? ??? ifcpu64.c32 ? ? ??? ifcpu.c32 ? ? ??? lfs.c32 ? ? ??? libcom32.c32 ? ? ??? libgpl.c32 ? ? ??? liblua.c32 ? ? ??? libmenu.c32 ? ? ??? libutil.c32 ? ? ??? linux.c32 ? ? ??? ls.c32 ? ? ??? lua.c32 ? ? ??? mboot.c32 ? ? ??? meminfo.c32 ? ? ??? menu.c32 ? ? ??? pci.c32 ? ? ??? pwd.c32 ? ? ??? reboot.c32 ? ? ??? rosh.c32 ? ? ??? sysdump.c32 ? ? ??? syslinux.c32 ? ? ??? vesa.c32 ? ? ??? vesamenu.c32 ? ? ??? vpdtest.c32 ? ? ??? whichsys.c32 ? ? ??? zzjson.c32 ? ??? SYSLX64.CFG ??? initrd.gz ??? linux 4 directories, 48 files + cat target/EFI/BOOT/SYSLX64.CFG ### EFI/BOOT/SYSLX64.CFG start ### # Note that the path starts with NO slash # and ends with a slash PATH SYSLINUX/EFI64/ UI SYSLINUX/EFI64/vesamenu.c32 DEFAULT lslabel PROMPT 1 # TIMEOUT 100 SAY *** Press enter to boot the default label *** LABEL lslabel COM32 SYSLINUX/EFI64/ls.c32 LABEL pwdlabel COM32 SYSLINUX/EFI64/pwd.c32 LABEL mylabel LINUX /linux INITRD /initrd.gz ### EFI/BOOT/SYSLX64.CFG end ###> Regards, > Ady. > > > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux-- Carl K
> > _ target/EFI/BOOT/SYSLINUX.CFG > > I don't think that exists? (see list below)In our "first test" (simple boot prompt), we created "target/EFI/BOOT/SYSLINUX.CFG". In our "second test" we _added_ "target/EFI/BOOT/SYSLINUX/EFI64/SYSLX64.CFG". Part of my intention was to test whether it actually reaches one cfg or the other. Although there are special circumstances in which the first one could still be useful, I don't want to leave it there while troubleshooting. Since you created a "new boot.img" (which you mentioned in some other email), then leftovers of our "first and second tests" are not there any longer. I still have a "picture in mind", so I wrote the step (to delete those 2 files) anyway. The reason for the second file, "target/EFI/BOOT/SYSLINUX/EFI64/ldlinux.e64", to still be there (in spite of using a "new boot.img") is because it is coming (again) from the "syslinux-common" package. As I mentioned before, that's the arrangement Debian has been using for years now. It makes no sense to have a "syslinux-efi" package with "syslinux.efi" files (efi32 + efi64) but without their corresponding ldlinux.e{32,64} core modules, and there is not much sense to have these core modules in the "syslinux-common" package instead. This is unfortunate, and a waste of time, and a source for multiple confusions, but it is out of my/our control. IMHO, it would be better (in comparison to the current situation) to have the core module files included in both packages (right there together with their corresponding "syslinux.efi" files) ; that way, older scripts won't be failing, but some new scripts / use cases can be more effectively crafted. In your script, if you copy the ldlinux.e64 file to the right place, and you copy the relevant "*.c32" (not "*.*") files to "target/EFI/BOOT/SYSLINUX/EFI64/*.*", then this file won't end up where it doesn't need to be (until proven needed).> rm $target/EFI/BOOT/SYSLINUX/EFI64/ldlinux.e64 > rm -f $target/ldlinux.c32 > rm -f $target/ldlinux.sys > > I just noticed those 2 files that were added by > syslinux -i boot.img > (right?)Yes, those 2 files came from your 'syslinux' command (in your other email). We don't want anything related to BIOS for now. Hopefully we'll get there at some point. If you can, please comment out the BIOS-related stuff in your script for now.> Is there any way to check versions of what ends up on the image?If I understand correctly, you can still get to the boot prompt; correct? And you can still see the results on screen when you execute some kind of "boot" command; correct? If that's the case, while you are at the boot prompt you can press "[ctrl]+[v]" to report the version. It should say something like: 6.04 (EFI; 20181018) If the reported date is not there or if it is a different date, or if there is anything different, please report that info back. You could also post the md5 checksums of your "BOOTX64.EFI", "LDLINUX.E64", "vesamenu.c32" and all the "lib*.c32" that are already in your target device/image.> I do see 6.04 here: > > + dd if=/dev/zero of=boot.img bs=100M count=1 > 1+0 records in > 1+0 records out > 104857600 bytes (105 MB, 100 MiB) copied, 0.999141 s, 105 MB/s > + /sbin/mkfs.msdos boot.img > mkfs.fat 4.1 (2017-01-24) > + syslinux -i boot.img > + qemu-system-x86_64 -m 512 -drive file=disk.cow,index=0 -drive > file=boot.img,index=1,format=raw,if=none,id=thumb -device > ide-hd,drive=thumb,bootindex=1 > > http://imgr.sytes.net/a/qemu5.pngAre we actually dealing with ipxe too in all these tests?> report: > using this code: > https://salsa.debian.org/debconf-video-team/ansible/blob/05480062710486be6b5f5501f560ce3552e87c99/usbinst/uefi/build_uefi.sh > > Undef symbol FAIL: memsetOur "third test" was about adding the PATH directive. For some reason, the binary files you are using seem to have some building problem or some kind of corruption. I wonder whether your other device in your qemu line "-drive file=disk.cow,index=0" could have any kind of influence in the resulting behavior. I also wonder whether your newly created boot.img (or rather its fs inside) has been somehow corrupted by any of the steps (say for instance, the 'syslinux' command). It might be relevant to note that now you have a new, different error message; hmm, just because you deleted one (in theory, unneeded) ldlinux.e64 file while did not change anything about the c32 files? Something is indeed fishy here.> everything else is the same as before: > http://imgr.sytes.net/a/qemu4.pngWhat happens if you just use a copy of the originally-downloaded "boot.img", instead of creating your own, and follow the steps I provided? Would such test be possible? Please also avoid for now the 'syslinux' command for BIOS files. Please note that a 100MB FAT fs is not the same as (read as "not exactly transferable to") an 8GB FAT fs. In fact, we should not be using "such a big FAT fs", certainly not for troubleshooting. FWIW, the reason I am requesting this is because we need to narrow down the source of the problem. Is it a problem when building Syslinux? Is it qemu or Seabios or TianoCore (and some kind of memory-handling)? Is it the creation/handling of the FAT fs in (any of the) boot.img? Is the 'syslinux' command causing a problem? Is it the other device in your qemu command line? Is it... Please report back. Whichever the result, my next emails might not be as frequent / immediate as you would like (I do have a life, or some kind of life, in spite of what members of this mailing list might think :p :), and I also have to think about the next steps / tests in order to reduce wasting our time). Regards, Ady.
On Sun, Dec 2, 2018 at 9:29 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote:> > > > > _ target/EFI/BOOT/SYSLINUX.CFG > > > > I don't think that exists? (see list below) > > > In our "first test" (simple boot prompt), we created > "target/EFI/BOOT/SYSLINUX.CFG". In our "second test" we _added_ > "target/EFI/BOOT/SYSLINUX/EFI64/SYSLX64.CFG". Part of my intention was > to test whether it actually reaches one cfg or the other. Although > there are special circumstances in which the first one could still be > useful, I don't want to leave it there while troubleshooting.Ah, took out the first cfg. sounds like that is ok, other than making things a little confusing.> > Since you created a "new boot.img" (which you mentioned in some other > email), then leftovers of our "first and second tests" are not there > any longer. I still have a "picture in mind", so I wrote the step (to > delete those 2 files) anyway.Oh right, uefi (or just efi? whats the difference?) is all files booted from the fat fs, no boot loader stuff written to special places on the disk. I knew that, but habit made me think I still needed... ok, all that removed. Now it is just dd, mkfs and copy in the files we need. One less thing to worry about keeping versions consistent.> > The reason for the second file, > "target/EFI/BOOT/SYSLINUX/EFI64/ldlinux.e64", to still be there (in > spite of using a "new boot.img") is because it is coming (again) from > the "syslinux-common" package. As I mentioned before, that's the > arrangement Debian has been using for years now. It makes no sense to > have a "syslinux-efi" package with "syslinux.efi" files (efi32 + efi64) > but without their corresponding ldlinux.e{32,64} core modules, and > there is not much sense to have these core modules in the > "syslinux-common" package instead. This is unfortunate, and a waste of > time, and a source for multiple confusions, but it is out of my/our > control. IMHO, it would be better (in comparison to the current > situation) to have the core module files included in both packages > (right there together with their corresponding "syslinux.efi" files) ; > that way, older scripts won't be failing, but some new scripts / use > cases can be more effectively crafted.I was thinking it was odd. glad you agree.> > In your script, if you copy the ldlinux.e64 file to the right place, > and you copy the relevant "*.c32" (not "*.*") files to > "target/EFI/BOOT/SYSLINUX/EFI64/*.*", then this file won't end up where > it doesn't need to be (until proven needed).got it: cp /usr/lib/syslinux/modules/efi64/*.c32 $target/EFI/BOOT/SYSLINUX/EFI64> > > > rm $target/EFI/BOOT/SYSLINUX/EFI64/ldlinux.e64 > > rm -f $target/ldlinux.c32 > > rm -f $target/ldlinux.sys > > > > I just noticed those 2 files that were added by > > syslinux -i boot.img > > (right?) > > > Yes, those 2 files came from your 'syslinux' command (in your other > email). We don't want anything related to BIOS for now. Hopefully we'll > get there at some point. If you can, please comment out the > BIOS-related stuff in your script for now.removed all that.> > > > Is there any way to check versions of what ends up on the image? > > > If I understand correctly, you can still get to the boot prompt; > correct? And you can still see the results on screen when you execute > some kind of "boot" command; correct? If that's the case, while you are > at the boot prompt you can press "[ctrl]+[v]" to report the version. It > should say something like: > > 6.04 (EFI; 20181018)date is: 20181013 (13 not 18)> > If the reported date is not there or if it is a different date, or if > there is anything different, please report that info back. > > You could also post the md5 checksums of your "BOOTX64.EFI", > "LDLINUX.E64", "vesamenu.c32" and all the "lib*.c32" that are already > in your target device/image. > > > > I do see 6.04 here: > > > > + dd if=/dev/zero of=boot.img bs=100M count=1 > > 1+0 records in > > 1+0 records out > > 104857600 bytes (105 MB, 100 MiB) copied, 0.999141 s, 105 MB/s > > + /sbin/mkfs.msdos boot.img > > mkfs.fat 4.1 (2017-01-24) > > + syslinux -i boot.img > > + qemu-system-x86_64 -m 512 -drive file=disk.cow,index=0 -drive > > file=boot.img,index=1,format=raw,if=none,id=thumb -device > > ide-hd,drive=thumb,bootindex=1 > > > > http://imgr.sytes.net/a/qemu5.png > > > Are we actually dealing with ipxe too in all these tests? >Hmm? we are dealing with whatever QEMU uses for a boot manager.> > > report: > > using this code: > > https://salsa.debian.org/debconf-video-team/ansible/blob/05480062710486be6b5f5501f560ce3552e87c99/usbinst/uefi/build_uefi.sh > > > > Undef symbol FAIL: memset > > > Our "third test" was about adding the PATH directive. For some reason, > the binary files you are using seem to have some building problem or > some kind of corruption. > > I wonder whether your other device in your qemu line "-drive > file=disk.cow,index=0" could have any kind of influence in the > resulting behavior. I also wonder whether your newly created boot.img > (or rather its fs inside) has been somehow corrupted by any of the > steps (say for instance, the 'syslinux' command). > > It might be relevant to note that now you have a new, different error > message; hmm, just because you deleted one (in theory, unneeded) > ldlinux.e64 file while did not change anything about the c32 files? > Something is indeed fishy here. > > > > everything else is the same as before: > > http://imgr.sytes.net/a/qemu4.png > > > What happens if you just use a copy of the originally-downloaded > "boot.img", instead of creating your own, and follow the steps I > provided? Would such test be possible?Same error, (not surprising)> Please also avoid for now the > 'syslinux' command for BIOS files. > > Please note that a 100MB FAT fs is not the same as (read as "not > exactly transferable to") an 8GB FAT fs. In fact, we should not be > using "such a big FAT fs", certainly not for troubleshooting. > > FWIW, the reason I am requesting this is because we need to narrow down > the source of the problem. Is it a problem when building Syslinux? Is > it qemu or Seabios or TianoCore (and some kind of memory-handling)? Is > it the creation/handling of the FAT fs in (any of the) boot.img? Is the > 'syslinux' command causing a problem? Is it the other device in your > qemu command line? Is it...I think the debian package contains broken binaries. I'll chase down the mainter Maintainer: Debian CD Group <debian-cd at lists.debian.org> Swell. I have a few friends, I'll find someone :p I came to this conclusion by swapped out the files from the debian package with syslinux-6.04-pre1.tar.gz and get a nice menu. -cp /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi $target/EFI/BOOT/BOOTX64.EFI -cp /usr/lib/syslinux/modules/efi64/ldlinux.e64 $target/EFI/BOOT/LDLINUX.E64 -cp /usr/lib/syslinux/modules/efi64/* $target/EFI/BOOT/SYSLINUX/EFI64 +# wget -N https://mirrors.edge.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.04/syslinux-6.04-pre1.tar.gz +# tar -xvf syslinux-6.04-pre1.tar.gz +cp syslinux-6.04-pre1/efi64/efi/syslinux.efi $target/EFI/BOOT/BOOTX64.EFI +cp syslinux-6.04-pre1/efi64/com32/elflink/ldlinux/ldlinux.e64 $target/EFI/BOOT/LDLINUX.E64 +cp syslinux-6.04-pre1/efi64/com32/modules/*.c32 $target/EFI/BOOT/SYSLINUX/EFI64 +cp syslinux-6.04-pre1/efi64/com32/lib/*.c32 $target/EFI/BOOT/SYSLINUX/EFI64 +cp syslinux-6.04-pre1/efi64/com32/libutil/*.c32 $target/EFI/BOOT/SYSLINUX/EFI64 +cp syslinux-6.04-pre1/efi64/com32/menu/*.c32 $target/EFI/BOOT/SYSLINUX/EFI64 http://imgr.sytes.net/a/qemu6.png> > > Please report back. Whichever the result, my next emails might not be > as frequent / immediate as you would like (I do have a life, or some > kind of life, in spite of what members of this mailing list might think > :p :), and I also have to think about the next steps / tests in order > to reduce wasting our time). >No problem, I very much appreciate all the help you have given so far. I'll keep you posted with what I find in debian packing land.> Regards, > Ady. > > > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux-- Carl K