[syslinux] fixing debian's hd-media image

Sun Dec 2 20:55:00 PST 2018

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