[syslinux] fixing debian's hd-media image

[Ady Ady]

> > _ 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.png
 
 
Are 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: 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? 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.