Syslinux - Nov 2018 - fixing debian's hd-media image

On Thu, Nov 15, 2018 at 1:10 PM Ady Ady via Syslinux <syslinux at
zytor.com> wrote:
>
> Here are some comments and questions for you.
>
Thanks.

I've have my scripts to a better state, including installing/using
qemu to uefi and legacy boot the usb stick for testing.

It mostly works for me, but the "wget a tarball of binaries" step
isn't going to sit well with the debian folk, so I'm not done yet.  I
may be close enough that they will know how to do it properly.

> > I want to eufi boot this image:
> >
http://cdn-fastly.deb.debian.org/debian/dists/testing/main/installer-amd64/current/images/hd-media/boot.img.gz
>
>
> I am going to assume that by "boot this image" you don't mean
something
> like memdisk or equivalent, but rather that you want to transfer that
> image using "dd" to your (USB) device and boot the resulting
device in
> UEFI mode. Is this assumption correct?
correct.

>
>
> >
> > there is a bug against it:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913523
>
>
> Although this is the Syslinux Mailing List and not Debian's in
> particular...
syslinux list because I am trying to UEFI boot syslinux.
> I would say that the above bug report is slightly
> confusing. AFAIK, the files under "hd-media" are aimed at a
specific
> scenario (i.e. starting the _installation_ of the OS from a filesystem
> volume that is already part of the HDD).
correct, kinda.  it boots a linux kernel, and runs the installer.
Unless it is a UEFI only box, and then it doesn't boot, which is a
problem.
> I could be wrong but, where
> does it say that the boot.img(.gz) mentioned in that report is aimed at
> (or that it supports) booting Debian (itself) from USB?
It's implied.  or desired, so we could call it a feature request.
>
> Moreover, where is the official info claiming that the boot.img(.gz)
> file can support booting in UEFI mode? (FWIW, ATM it doesn't, unless
> you add "some things").
correct - I was confused that a UEFI box booted it using compatibility mode.
>
> Additionally, the boot.img(.gz) file is not supposed to have a
> partition table. Not having a partition table is not a bug for that
> image (the image is a (potentially bootable) filesystem volume). I
> could be wrong but, AFAIU, the image is not aimed at being written to
> the HDD as a complete, partitioned HDD. You could write a device with
> it, but it would then be a (super)floppy-like device. Whether such
> device effectively serves its purpose of launching the installer (for
> Debian), that's another matter.
all correct.
>
> Now, perhaps an important detail to be aware of: the UEFI specs indeed
> support booting a filesystem volume in UEFI mode. Just think of it as a
> (super)floppy (i.e. no partition table, no MBR, _no GPT_).
I was wondering about that.   I'll stop trying to figure out how to do
that, so thank you,
>
>
>
> >
> > I'd like to fix the resulting usb stick for my use, and also fix
it in
> > a way that can be used to fix the upstream bug.
>
>
> You are using the term "fix" twice here, and I have to admit
that, to
> me, it is not at all clear what exactly you mean.
I would like a quick workaround so I can boot the box I am in
possession of (which I have now achieved)
and also something that can be contributed to the debian project.  (I'm
close)
>
> What exactly is wrong in the resulting USB stick?
It is built by me floundering around, call it prof of concept.
I'm a little bothered that syslinux.efi isn't in the debian package,
and should I use the ldlinux.e64 from the tarbal or package?
>
> What is "upstream" to you in this context? Debian? D-I? The
Syslinux
> Project? Other?
Debian.

I think add some lines around here:

https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/x86.cfg#L113-115

mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/vesamenu.c32
::vesamenu.c32; \
mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libcom32.c32
::libcom32.c32; \
mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libutil.c32
::libutil.c32 ; \
>
>
> >
> > I'm trying to follow the guids
> > https://www.syslinux.org/wiki/index.php?title=Install#UEFI
> > and a ml post - here is what I have so far:
> >
> >
https://salsa.debian.org/carlfk-guest/ansible/blob/uefiusb/usbinst/uefi/fix_hdmedia.sh
> > (likely quite a bit of unneeded copies)
> >
> > it boots, (good)
> > Initial menu has no LABEL enries!
>
>
> I have to say that your cfg file(s) are not very clear to me (at the
> time I was reading your script, which by now has been changed).
The scripts got a whole lot simpler, now basicly:

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/
cp /usr/lib/syslinux/modules/efi64/* $target/EFI/syslinux
> Could
> you please post here the resulting directory tree, the list of file
> names in each directory and the complete resulting content of all the
> cfg files, without pointing us to a script?
carl at twist:/media/carl/Debian Inst$ tree -d
??? EFI
    ??? BOOT
    ??? syslinux

carl at twist:/media/carl/Debian Inst$ tree
??? adgtk.cfg
??? adspkgtk.cfg
??? adtxt.cfg
??? disk.lbl
??? EFI
?   ??? BOOT
?   ?   ??? BOOTX64.EFI
?   ?   ??? ldlinux.e64
?   ??? syslinux
?       ??? cat.c32
?       ??? chain.c32
?       ??? cmd.c32
?       ??? cmenu.c32
?       ??? config.c32
?       ??? cptime.c32
?       ??? cpu.c32
?       ??? cpuid.c32
?       ??? cpuidtest.c32
?       ??? debug.c32
?       ??? dhcp.c32
?       ??? disk.c32
?       ??? dmi.c32
?       ??? dmitest.c32
?       ??? elf.c32
?       ??? ethersel.c32
?       ??? gfxboot.c32
?       ??? gpxecmd.c32
?       ??? hdt.c32
?       ??? hexdump.c32
?       ??? host.c32
?       ??? ifcpu64.c32
?       ??? ifcpu.c32
?       ??? ifmemdsk.c32
?       ??? ifplop.c32
?       ??? kbdmap.c32
?       ??? kontron_wdt.c32
?       ??? ldlinux.e64
?       ??? 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
?       ??? pcitest.c32
?       ??? pmload.c32
?       ??? poweroff.c32
?       ??? prdhcp.c32
?       ??? pwd.c32
?       ??? pxechn.c32
?       ??? reboot.c32
?       ??? rosh.c32
?       ??? sanboot.c32
?       ??? sdi.c32
?       ??? sysdump.c32
?       ??? syslinux.c32
?       ??? vesa.c32
?       ??? vesainfo.c32
?       ??? vesamenu.c32
?       ??? vpdtest.c32
?       ??? whichsys.c32
?       ??? zzjson.c32
??? exithelp.cfg
??? f10.txt
??? f1.txt
??? f2.txt
??? f3.txt
??? f4.txt
??? f5.txt
??? f6.txt
??? f7.txt
??? f8.txt
??? f9.txt
??? g2ldr
??? g2ldr.mbr
??? gtk.cfg
??? initrdg.gz
??? initrd.gz
??? ldlinux.c32
??? ldlinux.sys
??? libcom32.c32
??? libutil.c32
??? linux
??? menu.cfg
??? NvVars
??? prompt.cfg
??? rqgtk.cfg
??? rqspkgtk.cfg
??? rqtxt.cfg
??? setup.exe
??? spkgtk.cfg
??? splash.png
??? stdmenu.cfg
??? syslinux.cfg
??? txt.cfg
??? vesamenu.c32
??? win32-loader.ini

carl at twist:/media/carl/Debian Inst$ cat syslinux.cfg
# simple syslinux.cfg
DEFAULT linux
LABEL linux
KERNEL linux
INITRD initrd.gz
>
> BTW, Debian "Testing" ATM has the most up-to-date binaries of
Syslinux,
> even newer (and better) than the official 6.04-pre1 of kernel.org.
>
>
> > boot:
> > linux boot linux, but no initrd, but i'm sure once I get the .cfg
> > files worked out that will fall into place.
> >
>
> Best 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

> On Thu, Nov 15, 2018 at 1:10 PM Ady Ady via Syslinux <syslinux at
zytor.com> wrote:
> >
> > Here are some comments and questions for you.
> >
> 
> Thanks.
> 
> I've have my scripts to a better state, including installing/using
> qemu to uefi and legacy boot the usb stick for testing.
> 
> It mostly works for me, but the "wget a tarball of binaries" step
> isn't going to sit well with the debian folk, so I'm not done yet. 
I
> may be close enough that they will know how to do it properly.
 
 
As I mentioned before, the current "Testing" repo in Debian has the 
most updated binaries of any Linux distro, and even newer (and better) 
than official upstream 6.04-pre1.

The current "syslinux.efi" files for Debian (both, for efi32 and for 
efi64) can be downloaded from the "syslinux-efi" package.

For the "Testing" repo, the mirrors (and links) can be seen at:
 https://packages.debian.org/testing/all/syslinux-efi/download 

The Syslinux-related files in Debian's packages are scattered through 
several binary packages. Unfortunately, the specific way in which these 
files are arranged makes not much sense. So, in order to get 
"ldlinux.e64" (and/or "ldlinux.e32", and/or
"ldlinux.c32), you need to
also get another ("big") binary package from Debian,
"syslinux-common":

 https://packages.debian.org/testing/all/syslinux-common/download 

> 
> 
> > > I want to eufi boot this image:
> > >
http://cdn-fastly.deb.debian.org/debian/dists/testing/main/installer-amd64/current/images/hd-media/boot.img.gz
> >
> >
> > I am going to assume that by "boot this image" you don't
mean something
> > like memdisk or equivalent, but rather that you want to transfer that
> > image using "dd" to your (USB) device and boot the resulting
device in
> > UEFI mode. Is this assumption correct?
> 
> correct.
> 
> 
> >
> >
> > >
> > > there is a bug against it:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913523
> >
> >
> > Although this is the Syslinux Mailing List and not Debian's in
> > particular...
> 
> syslinux list because I am trying to UEFI boot syslinux.
 
 
OK. So, at least for now, we are not talking about any kind of fix nor 
bug report about Syslinux itself. Now things are getting clearer.

> 
> > I would say that the above bug report is slightly
> > confusing. AFAIK, the files under "hd-media" are aimed at a
specific
> > scenario (i.e. starting the _installation_ of the OS from a filesystem
> > volume that is already part of the HDD).
> 
> correct, kinda.  it boots a linux kernel, and runs the installer.
> Unless it is a UEFI only box, and then it doesn't boot, which is a
> problem.
 
 
Since the "hd-image" boot.img file was never prepared for UEFI booting
(whereas the kernel and intird files within it might, perhaps, already 
support such case), then we are not talking about a traditional "bug" 
but rather a feature request, for Debian (D-I, not for Syslinux). Now 
we are rising the level of clarity. Good :).

> 
> > I could be wrong but, where
> > does it say that the boot.img(.gz) mentioned in that report is aimed
at
> > (or that it supports) booting Debian (itself) from USB?
> 
> It's implied.  or desired, so we could call it a feature request.
 
 
Feature request for Debian (D-I). Agreed.

> 
> >
> > Moreover, where is the official info claiming that the boot.img(.gz)
> > file can support booting in UEFI mode? (FWIW, ATM it doesn't,
unless
> > you add "some things").
> 
> correct - I was confused that a UEFI box booted it using compatibility
mode.
 
 
CSM is like BIOS, so, sure, it should be bootable in such case (unless 
the "BIOS" is buggy, in which case YMMV).

> 
> >
> > Additionally, the boot.img(.gz) file is not supposed to have a
> > partition table. Not having a partition table is not a bug for that
> > image (the image is a (potentially bootable) filesystem volume). I
> > could be wrong but, AFAIU, the image is not aimed at being written to
> > the HDD as a complete, partitioned HDD. You could write a device with
> > it, but it would then be a (super)floppy-like device. Whether such
> > device effectively serves its purpose of launching the installer (for
> > Debian), that's another matter.
> 
> all correct.
 
 
The reason I mentioned that using a fs directly, for UEFI booting, is 
supposed to be supported, is because I have read the comments in the 
bug report (for Debian) you mentioned before. Whoever takes care (or 
plainly reads) that bug report might (wrongly) think that a GPT should 
be added to boot.img; it should _not_ be. Let me rephrase it: it shall 
not be added.

The boot.img needs a UEFI-compatible bootloader within it, using the 
"default" file names (e.g. "/EFI/BOOT/BOOTX64.EFI") for the
feature
request to be resolved.

> 
> >
> > Now, perhaps an important detail to be aware of: the UEFI specs indeed
> > support booting a filesystem volume in UEFI mode. Just think of it as
a
> > (super)floppy (i.e. no partition table, no MBR, _no GPT_).
> 
> I was wondering about that.   I'll stop trying to figure out how to do
> that, so thank you,
> 
> >
> >
> >
> > >
> > > I'd like to fix the resulting usb stick for my use, and also
fix it in
> > > a way that can be used to fix the upstream bug.
> >
> >
> > You are using the term "fix" twice here, and I have to admit
that, to
> > me, it is not at all clear what exactly you mean.
> 
> I would like a quick workaround so I can boot the box I am in
> possession of (which I have now achieved)
> and also something that can be contributed to the debian project.  (I'm
close)
> 
> >
> > What exactly is wrong in the resulting USB stick?
> 
> It is built by me floundering around, call it prof of concept.
> I'm a little bothered that syslinux.efi isn't in the debian
package,
> and should I use the ldlinux.e64 from the tarbal or package?
 
 
See my reply above, in this same email, about both files and where to 
get them.

Also, as mentioned more than once in the wiki, Syslinux files should 
come from the exact same package / build / version; mixing files from 
different packages / builds / versions should be avoided.

In theory, you could use one set of Syslinux files (one version) for 
BIOS and another (version) for UEFI. I wouldn't recommend it.

> 
> >
> > What is "upstream" to you in this context? Debian? D-I? The
Syslinux
> > Project? Other?
> 
> Debian.
> 
> I think add some lines around here:
> 
>
https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/x86.cfg#L113-115
> 
> mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/vesamenu.c32
> ::vesamenu.c32; \
> mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libcom32.c32
> ::libcom32.c32; \
> mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libutil.c32
> ::libutil.c32 ; \
 
 
I'm confused. Why exactly those (BIOS) files are supposed to be related 
to your feature request? Could you please explain (what exactly is 
triggering this thought)?

> 
> >
> >
> > >
> > > I'm trying to follow the guids
> > > https://www.syslinux.org/wiki/index.php?title=Install#UEFI
> > > and a ml post - here is what I have so far:
> > >
> > >
https://salsa.debian.org/carlfk-guest/ansible/blob/uefiusb/usbinst/uefi/fix_hdmedia.sh
> > > (likely quite a bit of unneeded copies)
> > >
> > > it boots, (good)
> > > Initial menu has no LABEL enries!
> >
> >
> > I have to say that your cfg file(s) are not very clear to me (at the
> > time I was reading your script, which by now has been changed).
> 
> The scripts got a whole lot simpler, now basicly:
> 
> 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/
> cp /usr/lib/syslinux/modules/efi64/* $target/EFI/syslinux
 
 
That last "cp" should, in theory, be optional (it could still be 
useful, but not essential). But, if you are adding all the c32 modules 
for efi64 (at this point, who knows why, and adding such amount of 
bytes, but OK, let's see where this goes), I am wondering why would you 
need to put them in another directory. Why not using 
"$target/EFI/BOOT/" as in your prior "cp" commands? Of
course, we could
think of eventually using a common set of cfg files (for BIOS and UEFI) 
in boot.img, and that would require the additional c32 files for 
efi(32/64) and some additional tweaks.

Also, ATM I would again suggest using the current Debian's
"Testing"
binaries.

> 
> > Could
> > you please post here the resulting directory tree, the list of file
> > names in each directory and the complete resulting content of all the
> > cfg files, without pointing us to a script?
> 
> carl at twist:/media/carl/Debian Inst$ tree -d
> ??? EFI
>     ??? BOOT
>     ??? syslinux
> 
> carl at twist:/media/carl/Debian Inst$ tree
> ??? adgtk.cfg
> ??? adspkgtk.cfg
> ??? adtxt.cfg
> ??? disk.lbl
> ??? EFI
> ?   ??? BOOT
> ?   ?   ??? BOOTX64.EFI
> ?   ?   ??? ldlinux.e64
> ?   ??? syslinux
> ?       ??? cat.c32
> ?       ??? chain.c32
> ?       ??? cmd.c32
> ?       ??? cmenu.c32
> ?       ??? config.c32
> ?       ??? cptime.c32
> ?       ??? cpu.c32
> ?       ??? cpuid.c32
> ?       ??? cpuidtest.c32
> ?       ??? debug.c32
> ?       ??? dhcp.c32
> ?       ??? disk.c32
> ?       ??? dmi.c32
> ?       ??? dmitest.c32
> ?       ??? elf.c32
> ?       ??? ethersel.c32
> ?       ??? gfxboot.c32
> ?       ??? gpxecmd.c32
> ?       ??? hdt.c32
> ?       ??? hexdump.c32
> ?       ??? host.c32
> ?       ??? ifcpu64.c32
> ?       ??? ifcpu.c32
> ?       ??? ifmemdsk.c32
> ?       ??? ifplop.c32
> ?       ??? kbdmap.c32
> ?       ??? kontron_wdt.c32
> ?       ??? ldlinux.e64
> ?       ??? 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
> ?       ??? pcitest.c32
> ?       ??? pmload.c32
> ?       ??? poweroff.c32
> ?       ??? prdhcp.c32
> ?       ??? pwd.c32
> ?       ??? pxechn.c32
> ?       ??? reboot.c32
> ?       ??? rosh.c32
> ?       ??? sanboot.c32
> ?       ??? sdi.c32
> ?       ??? sysdump.c32
> ?       ??? syslinux.c32
> ?       ??? vesa.c32
> ?       ??? vesainfo.c32
> ?       ??? vesamenu.c32
> ?       ??? vpdtest.c32
> ?       ??? whichsys.c32
> ?       ??? zzjson.c32
> ??? exithelp.cfg
> ??? f10.txt
> ??? f1.txt
> ??? f2.txt
> ??? f3.txt
> ??? f4.txt
> ??? f5.txt
> ??? f6.txt
> ??? f7.txt
> ??? f8.txt
> ??? f9.txt
> ??? g2ldr
> ??? g2ldr.mbr
> ??? gtk.cfg
> ??? initrdg.gz
> ??? initrd.gz
> ??? ldlinux.c32
> ??? ldlinux.sys
> ??? libcom32.c32
> ??? libutil.c32
> ??? linux
> ??? menu.cfg
> ??? NvVars
> ??? prompt.cfg
> ??? rqgtk.cfg
> ??? rqspkgtk.cfg
> ??? rqtxt.cfg
> ??? setup.exe
> ??? spkgtk.cfg
> ??? splash.png
> ??? stdmenu.cfg
> ??? syslinux.cfg
> ??? txt.cfg
> ??? vesamenu.c32
> ??? win32-loader.ini
> 
> carl at twist:/media/carl/Debian Inst$ cat syslinux.cfg
> # simple syslinux.cfg
> DEFAULT linux
> LABEL linux
> KERNEL linux
> INITRD initrd.gz
 
 
Thank you for posting the info.

I would suggest (at least for now):

DEFAULT linux
PROMPT 1
LABEL linux
LINUX /linux
INITRD /initrd.gz

The "PROMPT 1" is in preparation for potential troubleshooting.

In my suggestion, I also changed (for now) the paths to be absolute 
(note the initial "/" for the kernel and initrd files).

Please note the change from "KERNEL" to "LINUX".

IOW, if the boot fails, the user would receive a suggestion to change 
from "KERNEL" to "LINUX" and test again (because it
_sometimes_ can
help, when the size of kernel/initrd files is really "big"), so
let's
avoid such step and change it already.

Also, since you mentioned some kind of "menu" before, please note that
my proposed "EFI/BOOT/syslinux.cfg" file would not present any boot 
menu (ATM).

Please also note that this is not "/syslinux.cfg" (already in 
boot.img).

Let's see whether there is any kind of improvement now (e.g. different 
messages, or to which boot step we can arrive with these changes, 
etc.).

Best Regards,
Ady.

On Sat, Nov 17, 2018 at 1:54 AM Ady Ady via Syslinux <syslinux at
zytor.com> wrote:
>
>
> > On Thu, Nov 15, 2018 at 1:10 PM Ady Ady via Syslinux <syslinux at
zytor.com> wrote:
> > >
> > > Here are some comments and questions for you.
> > >
> >
> > Thanks.
> >
> > I've have my scripts to a better state, including installing/using
> > qemu to uefi and legacy boot the usb stick for testing.
> >
> > It mostly works for me, but the "wget a tarball of binaries"
step
> > isn't going to sit well with the debian folk, so I'm not done
yet.  I
> > may be close enough that they will know how to do it properly.
>
>
> As I mentioned before, the current "Testing" repo in Debian has
the
> most updated binaries of any Linux distro, and even newer (and better)
> than official upstream 6.04-pre1.
>
> The current "syslinux.efi" files for Debian (both, for efi32 and
for
> efi64) can be downloaded from the "syslinux-efi" package.
>
> For the "Testing" repo, the mirrors (and links) can be seen at:
>  https://packages.debian.org/testing/all/syslinux-efi/download
>
> The Syslinux-related files in Debian's packages are scattered through
> several binary packages. Unfortunately, the specific way in which these
> files are arranged makes not much sense. So, in order to get
> "ldlinux.e64" (and/or "ldlinux.e32", and/or
"ldlinux.c32), you need to
> also get another ("big") binary package from Debian,
"syslinux-common":
>
>  https://packages.debian.org/testing/all/syslinux-common/download
>
>
> >
> >
> > > > I want to eufi boot this image:
> > > >
http://cdn-fastly.deb.debian.org/debian/dists/testing/main/installer-amd64/current/images/hd-media/boot.img.gz
> > >
> > >
> > > I am going to assume that by "boot this image" you
don't mean something
> > > like memdisk or equivalent, but rather that you want to transfer
that
> > > image using "dd" to your (USB) device and boot the
resulting device in
> > > UEFI mode. Is this assumption correct?
> >
> > correct.
> >
> >
> > >
> > >
> > > >
> > > > there is a bug against it:
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913523
> > >
> > >
> > > Although this is the Syslinux Mailing List and not Debian's
in
> > > particular...
> >
> > syslinux list because I am trying to UEFI boot syslinux.
>
>
> OK. So, at least for now, we are not talking about any kind of fix nor
> bug report about Syslinux itself. Now things are getting clearer.
>
>
> >
> > > I would say that the above bug report is slightly
> > > confusing. AFAIK, the files under "hd-media" are aimed
at a specific
> > > scenario (i.e. starting the _installation_ of the OS from a
filesystem
> > > volume that is already part of the HDD).
> >
> > correct, kinda.  it boots a linux kernel, and runs the installer.
> > Unless it is a UEFI only box, and then it doesn't boot, which is a
> > problem.
>
>
> Since the "hd-image" boot.img file was never prepared for UEFI
booting
> (whereas the kernel and intird files within it might, perhaps, already
> support such case), then we are not talking about a traditional
"bug"
> but rather a feature request, for Debian (D-I, not for Syslinux). Now
> we are rising the level of clarity. Good :).
>
>
> >
> > > I could be wrong but, where
> > > does it say that the boot.img(.gz) mentioned in that report is
aimed at
> > > (or that it supports) booting Debian (itself) from USB?
> >
> > It's implied.  or desired, so we could call it a feature request.
>
>
> Feature request for Debian (D-I). Agreed.
>
>
> >
> > >
> > > Moreover, where is the official info claiming that the
boot.img(.gz)
> > > file can support booting in UEFI mode? (FWIW, ATM it doesn't,
unless
> > > you add "some things").
> >
> > correct - I was confused that a UEFI box booted it using compatibility
mode.
>
>
> CSM is like BIOS, so, sure, it should be bootable in such case (unless
> the "BIOS" is buggy, in which case YMMV).
>
>
> >
> > >
> > > Additionally, the boot.img(.gz) file is not supposed to have a
> > > partition table. Not having a partition table is not a bug for
that
> > > image (the image is a (potentially bootable) filesystem volume).
I
> > > could be wrong but, AFAIU, the image is not aimed at being
written to
> > > the HDD as a complete, partitioned HDD. You could write a device
with
> > > it, but it would then be a (super)floppy-like device. Whether
such
> > > device effectively serves its purpose of launching the installer
(for
> > > Debian), that's another matter.
> >
> > all correct.
>
>
> The reason I mentioned that using a fs directly, for UEFI booting, is
> supposed to be supported, is because I have read the comments in the
> bug report (for Debian) you mentioned before. Whoever takes care (or
> plainly reads) that bug report might (wrongly) think that a GPT should
> be added to boot.img; it should _not_ be. Let me rephrase it: it shall
> not be added.
>
> The boot.img needs a UEFI-compatible bootloader within it, using the
> "default" file names (e.g. "/EFI/BOOT/BOOTX64.EFI") for
the feature
> request to be resolved.
>
>
> >
> > >
> > > Now, perhaps an important detail to be aware of: the UEFI specs
indeed
> > > support booting a filesystem volume in UEFI mode. Just think of
it as a
> > > (super)floppy (i.e. no partition table, no MBR, _no GPT_).
> >
> > I was wondering about that.   I'll stop trying to figure out how
to do
> > that, so thank you,
> >
> > >
> > >
> > >
> > > >
> > > > I'd like to fix the resulting usb stick for my use, and
also fix it in
> > > > a way that can be used to fix the upstream bug.
> > >
> > >
> > > You are using the term "fix" twice here, and I have to
admit that, to
> > > me, it is not at all clear what exactly you mean.
> >
> > I would like a quick workaround so I can boot the box I am in
> > possession of (which I have now achieved)
> > and also something that can be contributed to the debian project. 
(I'm close)
> >
> > >
> > > What exactly is wrong in the resulting USB stick?
> >
> > It is built by me floundering around, call it prof of concept.
> > I'm a little bothered that syslinux.efi isn't in the debian
package,
> > and should I use the ldlinux.e64 from the tarbal or package?
>
>
> See my reply above, in this same email, about both files and where to
> get them.
>
> Also, as mentioned more than once in the wiki, Syslinux files should
> come from the exact same package / build / version; mixing files from
> different packages / builds / versions should be avoided.
>
> In theory, you could use one set of Syslinux files (one version) for
> BIOS and another (version) for UEFI. I wouldn't recommend it.
>
>
> >
> > >
> > > What is "upstream" to you in this context? Debian? D-I?
The Syslinux
> > > Project? Other?
> >
> > Debian.
> >
> > I think add some lines around here:
> >
> >
https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/x86.cfg#L113-115
> >
> > mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/vesamenu.c32
> > ::vesamenu.c32; \
> > mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libcom32.c32
> > ::libcom32.c32; \
> > mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libutil.c32
> > ::libutil.c32 ; \
>
>
> I'm confused. Why exactly those (BIOS) files are supposed to be related
> to your feature request? Could you please explain (what exactly is
> triggering this thought)?
This is the existing code to build hd-media/boot.img,

It is where I think some lines need to be added to support uefi.

>
>
> >
> > >
> > >
> > > >
> > > > I'm trying to follow the guids
> > > > https://www.syslinux.org/wiki/index.php?title=Install#UEFI
> > > > and a ml post - here is what I have so far:
> > > >
> > > >
https://salsa.debian.org/carlfk-guest/ansible/blob/uefiusb/usbinst/uefi/fix_hdmedia.sh
> > > > (likely quite a bit of unneeded copies)
> > > >
> > > > it boots, (good)
> > > > Initial menu has no LABEL enries!
> > >
> > >
> > > I have to say that your cfg file(s) are not very clear to me (at
the
> > > time I was reading your script, which by now has been changed).
> >
> > The scripts got a whole lot simpler, now basicly:
> >
> > 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/
> > cp /usr/lib/syslinux/modules/efi64/* $target/EFI/syslinux
>
>
> That last "cp" should, in theory, be optional (it could still be
> useful, but not essential). But, if you are adding all the c32 modules
> for efi64 (at this point, who knows why, and adding such amount of
> bytes, but OK, let's see where this goes), I am wondering why would you
> need to put them in another directory. Why not using
> "$target/EFI/BOOT/" as in your prior "cp" commands? Of
course, we could
> think of eventually using a common set of cfg files (for BIOS and UEFI)
> in boot.img, and that would require the additional c32 files for
> efi(32/64) and some additional tweaks.
I'm not sure where I got the idea to put the c32 modules under a syslinx/
dir.

>
> Also, ATM I would again suggest using the current Debian's
"Testing"
> binaries.
now that I see the syslinux-efi package I can apt get everything
needed, which will make it easier to keep everything in sync.


>
>
> >
> > > Could
> > > you please post here the resulting directory tree, the list of
file
> > > names in each directory and the complete resulting content of all
the
> > > cfg files, without pointing us to a script?
> >
> > carl at twist:/media/carl/Debian Inst$ tree -d
> > ??? EFI
> >     ??? BOOT
> >     ??? syslinux
> >
> > carl at twist:/media/carl/Debian Inst$ tree
> > ??? adgtk.cfg
> > ??? adspkgtk.cfg
> > ??? adtxt.cfg
> > ??? disk.lbl
> > ??? EFI
> > ?   ??? BOOT
> > ?   ?   ??? BOOTX64.EFI
> > ?   ?   ??? ldlinux.e64
> > ?   ??? syslinux
> > ?       ??? cat.c32
> > ?       ??? chain.c32
> > ?       ??? cmd.c32
> > ?       ??? cmenu.c32
> > ?       ??? config.c32
> > ?       ??? cptime.c32
> > ?       ??? cpu.c32
> > ?       ??? cpuid.c32
> > ?       ??? cpuidtest.c32
> > ?       ??? debug.c32
> > ?       ??? dhcp.c32
> > ?       ??? disk.c32
> > ?       ??? dmi.c32
> > ?       ??? dmitest.c32
> > ?       ??? elf.c32
> > ?       ??? ethersel.c32
> > ?       ??? gfxboot.c32
> > ?       ??? gpxecmd.c32
> > ?       ??? hdt.c32
> > ?       ??? hexdump.c32
> > ?       ??? host.c32
> > ?       ??? ifcpu64.c32
> > ?       ??? ifcpu.c32
> > ?       ??? ifmemdsk.c32
> > ?       ??? ifplop.c32
> > ?       ??? kbdmap.c32
> > ?       ??? kontron_wdt.c32
> > ?       ??? ldlinux.e64
> > ?       ??? 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
> > ?       ??? pcitest.c32
> > ?       ??? pmload.c32
> > ?       ??? poweroff.c32
> > ?       ??? prdhcp.c32
> > ?       ??? pwd.c32
> > ?       ??? pxechn.c32
> > ?       ??? reboot.c32
> > ?       ??? rosh.c32
> > ?       ??? sanboot.c32
> > ?       ??? sdi.c32
> > ?       ??? sysdump.c32
> > ?       ??? syslinux.c32
> > ?       ??? vesa.c32
> > ?       ??? vesainfo.c32
> > ?       ??? vesamenu.c32
> > ?       ??? vpdtest.c32
> > ?       ??? whichsys.c32
> > ?       ??? zzjson.c32
> > ??? exithelp.cfg
> > ??? f10.txt
> > ??? f1.txt
> > ??? f2.txt
> > ??? f3.txt
> > ??? f4.txt
> > ??? f5.txt
> > ??? f6.txt
> > ??? f7.txt
> > ??? f8.txt
> > ??? f9.txt
> > ??? g2ldr
> > ??? g2ldr.mbr
> > ??? gtk.cfg
> > ??? initrdg.gz
> > ??? initrd.gz
> > ??? ldlinux.c32
> > ??? ldlinux.sys
> > ??? libcom32.c32
> > ??? libutil.c32
> > ??? linux
> > ??? menu.cfg
> > ??? NvVars
> > ??? prompt.cfg
> > ??? rqgtk.cfg
> > ??? rqspkgtk.cfg
> > ??? rqtxt.cfg
> > ??? setup.exe
> > ??? spkgtk.cfg
> > ??? splash.png
> > ??? stdmenu.cfg
> > ??? syslinux.cfg
> > ??? txt.cfg
> > ??? vesamenu.c32
> > ??? win32-loader.ini
> >
> > carl at twist:/media/carl/Debian Inst$ cat syslinux.cfg
> > # simple syslinux.cfg
> > DEFAULT linux
> > LABEL linux
> > KERNEL linux
> > INITRD initrd.gz
>
>
> Thank you for posting the info.
>
> I would suggest (at least for now):
>
> DEFAULT linux
> PROMPT 1
> LABEL linux
> LINUX /linux
> INITRD /initrd.gz
>
> The "PROMPT 1" is in preparation for potential troubleshooting.
>
> In my suggestion, I also changed (for now) the paths to be absolute
> (note the initial "/" for the kernel and initrd files).
>
> Please note the change from "KERNEL" to "LINUX".
>
> IOW, if the boot fails, the user would receive a suggestion to change
> from "KERNEL" to "LINUX" and test again (because it
_sometimes_ can
> help, when the size of kernel/initrd files is really "big"), so
let's
> avoid such step and change it already.
>
> Also, since you mentioned some kind of "menu" before, please note
that
> my proposed "EFI/BOOT/syslinux.cfg" file would not present any
boot
> menu (ATM).
>
> Please also note that this is not "/syslinux.cfg" (already in
> boot.img).
>
> Let's see whether there is any kind of improvement now (e.g. different
> messages, or to which boot step we can arrive with these changes,
> etc.).
This all works.  thank you again for the detailed reply.

But. the existing menu does not work.

2 problems I have identified:
If I don't put the above syslinux.cfg and go with what is on the d-i
setup, this seems to hang it:

default vesamenu.c32

#comment that out, and I get to another problem that I haven't taken
the time to track down yet.
Does any of this look like a problem?

carl at twist:~/src/tv/lca/ansible/usbinst/uefi$ cat /media/sdc/syslinux.cfg
# D-I config version 2.0
# search path for the c32 support libraries (libcom32, libutil etc.)
path
include menu.cfg
# default vesamenu.c32
prompt 0
timeout 0

carl at twist:~/src/tv/lca/ansible/usbinst/uefi$ cat /media/sdc/menu.cfg
menu hshift 7
menu width 61

menu title Debian GNU/Linux installer boot menu
include stdmenu.cfg
include gtk.cfg
include txt.cfg
menu begin advanced
    menu label ^Advanced options
    menu title Advanced options
    include stdmenu.cfg
    label mainmenu
        menu label ^Back..
        menu exit
    include adgtk.cfg
    include adtxt.cfg
    include adspkgtk.cfg
    include adspk.cfg
menu end
include x86menu.cfg
label help
    menu label ^Help
    text help
   Display help screens; type 'menu' at boot prompt to return to this
menu
    endtext
    config prompt.cfg
include spkgtk.cfg
include spk.cfg

carl at twist:~/src/tv/lca/ansible/usbinst/uefi$ cat /media/sdc/stdmenu.cfg
menu background splash.png
menu color title    * #FFFFFFFF *
menu color border    * #00000000 #00000000 none
menu color sel        * #ffffffff #76a1d0ff *
menu color hotsel    1;7;37;40 #ffffffff #76a1d0ff *
menu color tabmsg    * #ffffffff #00000000 *
menu color help        37;40 #ffdddd00 #00000000 none
# XXX When adjusting vshift, take care that rows is set to a small
# enough value so any possible menu will fit on the screen,
# rather than falling off the bottom.
menu vshift 8
menu rows 12
# The help line must be at least one line from the bottom.
menu helpmsgrow 14
# The command line must be at least one line from the help line.
menu cmdlinerow 16
menu timeoutrow 16
menu tabmsgrow 18
menu tabmsg Press ENTER to boot or TAB to edit a menu entry

carl at twist:~/src/tv/lca/ansible/usbinst/uefi$ cat /media/sdc/txt.cfg
label install
    menu label ^Install
    kernel linux
    append vga=788 initrd=initrd.gz --- quiet
carl at twist:~/src/tv/lca/ansible/usbinst/uefi$ cat /media/sdc/gtk.cfg
default installgui
label installgui
    menu label ^Graphical install
    menu default
    kernel linux
    append vga=788 initrd=initrdg.gz --- quiet
carl at twist:~/src/tv/lca/ansible/usbinst/uefi$
>
> Best 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