> Hello,
>
> Ady via Syslinux said on Sun, Oct 25, 2015 at 08:15:37PM +0200:
> >_ Creating filesystem that _does_ conform to ISO-9660;
>
> I think the only issue is with a tag. That same image boots with grub
> 0.99
I understand. My point is, in theory, "everything" is frequently
expected to work as it was designed; in practice, it is not. So my
suggestions are intended to minimize potential problems, even when we
don't usually would think that 'X' characteristic / feature could be
a
problem. The fact that some feature works as expected when testing
other bootloaders would make us believe that such feature "surely has
no issues", and yet, if we could minimize its potential impact I would
suggest trying to do so. For troubleshooting, KISS.
>
> >_ The fat image should not be bigger than 32MiB, and it should be
> >aligned. The latter suggestion is usually ignored by almost everyone,
> >but if we are troubleshooting...
>
> Tried with more and less than 30 MB without impatc.
> Aligned: could you give me an example of how you would create it with dd
> ?
Not exactly, but see below.
>
> >_ Creating a UEFI-boot-only image...
>
> I can try that indeed. Don't think it's creating an impact as I do
see
> the bootable VFAT32 part of my media and can navigate to it.
I'm not sure what exactly you mean by "can navigate to it". Do you
mean
that from the EFI shell you can read the content of the FAT image and
you can find (from the EFI shell) the relevant efi boot file (which
should be a copy of 'syslinux.efi')?
Also, please note that I keep talking about FAT1x, and not a VFAT32
image. For troubleshooting, I would avoid unnecessary long-file-name
support in FAT (so, simple FAT, no VFAT, although the UEFI Specs
support LFN) and I would suggest using FAT1x as expected by the UEFI
Specs for removable media (not FAT32, although in some sections the
UEFI Specs use the term "_may_ contain... FAT32" for removable media
too; another source of confusion from the long UEFI Specs). As I
mentioned before, the fact that some firmware is capable of accepting /
reading / using different features than what the UEFI Specs state can
be either a pro or a con. Either way, KISS.
>
> >_ genisoimage is not the same as mkisofs; do not use the former (which
> >has been unmaintained since 2010). BTW, the EFI parameters for mkisofs
> >are documented in its manual (year 2012 is the latest version of the
> >manual available, with 2010 being the prior version of the manual).
>
> I mentioned that I'm using RHEL7 to make my tests as a source. And
their
> version is highly moified. They *do* produce UEfI bootable images with
> grub2 BTW using their toolset. Their mkisofs is a link to genisoimage
>
> # mkisofs -v
> I: -input-charset not specified, using utf-8 (detected in locale
> settings)
> genisoimage 1.1.11 (Linux)
> genisoimage: Missing pathspec.
> Usage: genisoimage [options] -o file directory ...
>
> Use genisoimage -help
> to get a list of valid options.
>
> Report problems to debburn-devel at lists.alioth.debian.org.
>
> >_ "eltorito-alt-boot -efi-boot 1.img -no-emul-boot" will be
inadequate
> >for mkisofs.
>
> Yes but not for their version.
> My tool is working on a large variety of Linux distributions so it tries
> to first find the historical mkisofs command to burn. If found it uses
> it, if not it tries with genisoimage as params are very similar for what
> I do.
The reason genisoimage is highly modified is because... It is
unmaintained! :-O :). The "real" genisoimage (and any reincarnation of
it) might never work with Syslinux; who knows? Or it might; we won't
ever know it, as -- guess what? -- genisoimage is UNmaintained.
CDRTOOLS (which includes the real mkisofs) _is maintained_. I do
understand that you have this already set up, for several distros,
other scenarios, other bootloaders... But we are now trying to find out
why 'syslinux.efi' fails, aka troubleshooting. You have Thomas here,
the developer of xorriso. He is participating in this email thread. I
cannot see any good reason to keep testing (Syslinux) with
"genisoimage".
>
> >_ Since you don't even get to the Syslinux prompt, I would suggest,
for
> >troubleshooting purposes, to not even care about the kernel+initrd;
> >don't add these files. Let's just see syslinux.efi + ldlinux.e*
get to
> >the Syslinux boot prompt.
>
> How can I *see* that ?
> I still need to try the virtual serial port part but I'm surprised
there
> is no way to make syslinux more verbose so we know in which step it is.
> For PXE boot, at least I can do tcpdump to monitor what happens. Here
> I'm lost :-(
To make Syslinux more verbose, we should at least get some kind of
relevant output, and for that to happen we need to get 'syslinux.efi'
and 'ldlinux.*' loaded, at least. This is still true for binaries
compiled with debugging options. In a certain way, this is equivalent
to the POST making different types of "beeps" when there is yet no
visual output available. We don't have troubleshooting "beeps" in
Syslinux :(.
>
> >You mentioned some MBR. The efi image should not have any MBR, and if
> >the ISO image was treated with isohybrid, I would suggest avoiding it
> >at this time, for troubleshooting purposes.
>
> MBR for the image created which is then used as a parm to the -efi-boot
> option of genisoimage.
No, again, the UEFI-required FAT image for booting optical media does
not need (nor want, nor accept, nor use) any kind of partitioning
scheme. It is a FAT volume, only one, with no MBR, nor GPT, nor
anything related to partitioning. At least, this is my understanding
from the UEFI Specs. Of course, I could be wrong about the UEFI Specs,
but I do not know of any distro in which the UEFI-required FAT image
used for booting optical media in UEFI mode has a MBR.
Now, regarding (additional) partitioning schemes being added by
isohybrid, I am suggesting _not_ to use them at this time, for
troubleshooting. If your goal were, for instance, to boot from a USB
flash drive after _dd'ing_ the ISO image to it, then isohybrid would be
a factor. But we are before that point. If we cannot boot optical media
in UEFI mode with Syslinux, then we won't be able to achieve the
"dd'ing" part in any meaningful way.
As I wrote in my original email back in last April, _copying_ the
content of the ISO image (not dd'ing) *can* achieve the goal of booting
from storage media. We are not discussing such method either.
So, for now, I am suggesting not to use isohybrid, and certainly not to
use MBR as part of the UEFI-required FAT image.
>
> >For troubleshooting, KISS.
>
> That's really what II try to do. But I've not found an easy way to
make
> syslinux.efi verbose :-(
>
> BTW I've reproduced the red screen I get with another case: when using
the
> option -r blksize for the tftp server in PXE mode. Maybe it can give an
> idea to someone.
>
> I'm unsure of what is printing this screen.
> Bruno.
> --
I do not know either, but that doesn't mean much. Reproducing the same
output while using a completely different UEFI boot method (optical
media vs. network booting) would suggest that the specific firmware
(and its capabilities, features / functions / UEFI-compliance) might be
a bigger factor than we have weighted during this email thread.
Considering other email threads of this Syslinux Mailing List during
the last year or so, I am not surprised.
I know, I know... Other bootloader(s) successfully boot this same
system using equivalent UEFI boot methods (optical media, network
boot). I am not saying that Syslinux is not at fault (probably lacking
some feature), but rather that the results, at this time, might be
suggesting that the firmware in this system could be a factor (too).
I am attaching a zipped FAT12 image for you to test (hopefully it
passes the mailing list filters). I would recommend using xorriso for
testing, and no isohybrid (nor equivalent xorriso options either). A
second (different, separated) test could perhaps use only UEFI boot --
not having BIOS boot would be uncommon, but I'm sure Thomas can help
with the adequate xorriso command.
I would expect for the content of the ISO image, other than the FAT12
image for UEFI boot optical media, to be irrelevant at this time (at
least regarding the UEFI boot part).
The intention is not to boot any particular kernel, so there should be
no need to add files to this FAT12 image. The first goal should be to
get Syslinux to boot (to a boot prompt) when booting optical media in
UEFI mode. If this first goal is achieved, then this FAT12 image might
show a warning message about not being able to find a configuration
file (this would be expected) and then the Syslinux boot prompt should
be seen. With this image, you won't be able to do much after that boot
prompt, but at this point it would be plenty enough :).
Regarding the attached zipped FAT12 image:
_ It contains the UEFI binaries provided by Gene (from
sl604p0g18-x64.tgz), renamed and relocated to act as the default efi
application when booting optical media in UEFI x64 mode.
_ If this FAT12 image were to be used in BIOS mode by itself, it could
potentially "BIOS-boot" SYSLINUX 6.03 (not the same version as the
UEFI
counterpart included in this FAT12 image), since it contains the
relevant VBR and boot files too. This could potentially be a problem in
our UEFI optical media scenario, considering that, in theory, UEFI
should ignore any BIOS code, but in practice certain UEFI
implementations don't "like" finding BIOS code in UEFI mode, thus
making sometimes inadequate assumptions and acting against users'
wishes. Once again, real-life UEFI implementations that do not comply
to the Specs have pros and cons.
_ The Volume label can be seen as a zero-byte file in certain cases, as
the "hidden" attribute is not set for it. Although this is uncommon,
it
should not affect the boot process in any way. I mention this point
just to answer a potential question: "what is this zero-byte file doing
here?".
_ This FAT12 image is "aligned" to 2048 bytes.
_ This FAT12 image is _not_ using an 'Nx36x2' CHS geometry, so the
probability of this image being effectively used as (undocumented) El
Torito floppy-emulation type 3 image for BIOS booting is very low. The
CHS geometry of this FAT12 image is 31x64x32 and, in theory, should not
affect UEFI booting in any negative way. Whether the geometry could
affect some real-life UEFI firmware in any UEFI-booting scenario, I do
not know (but perhaps it is worth a check, right?)
_ This FAT12 image has 32 reserved (boot) sectors (as a typical FAT32
image), instead of just 1 (as a typical FAT12 image would). All the 32
reserved sectors end with the "55AA" magical number (not just the
first
one). Although UEFI does not use it, it is there for convenience.
_ For this FAT12 image, the max "root directory entries" is 64 (so you
would not be able to use / put more than 63 files or directories in the
"/" directory of the image). This is an uncommon value, but it should
not affect the current tests.
I want to be clear: I am not saying that 'syslinux.efi' is capable of
booting
optical media in UEFI mode with this (attached) FAT12 image. I am just
attempting to reduce the gap between the UEFI Specs and the FAT images
that
Bruno is using for testing. Whether it would effectively change the
prior
results, I do not know.
Let's get some test results / feedback.
Regards,
Ady.
-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: ADY4UEFI.ZIP
Date: 30 Oct 2015, 9:56
Size: 317345 bytes.
Type: ZIP-archive
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ADY4UEFI.ZIP
Type: application/zip
Size: 317345 bytes
Desc: not available
URL:
<http://www.zytor.com/pipermail/syslinux/attachments/20151030/b2c55a34/attachment-0001.zip>