Syslinux - Aug 2015 - Aside comments WAS:EFI: HP + syslinux = crash

> 
> For a KISS troubleshooting, *all* the c32 files should be located 
> together, in the root of the filesystem, where syslinux.efi and 
> ldlinux.e64 (for EFI x86_64) should be located too.
> 
 
I should clarify, just in case. In my previous email, when I mentioned 
"all" the c32 files, I actually meant all the c32 files that pertain
to
the adequate firmware's architecture.

If we are talking about UEFI x86_64, then the c32 files are all those 
located under the "efi64" directory tree of the Syslinux build. Plus, 
the relevant "ldlinux.*" core module.

I am clarifying (or attempting to) my prior statements about "all" the
c32 files because of some recurrent problems:

_ mixing files from different builds;

_ mixing c32 files from one firmware's architecture (BIOS, EFI32, 
EFI64) with another;

_ not having all the required library modules in the right place.


These are the reasons for a frequent request: add some kind of 
"version" ID to each and all c32 files in some "standard"
way.

One reason to recommend the root directory as the "installation" 
directory for the bootloader (and its core "ldlinux" module) file(s) 
and the modules at this stage of testing is to avoid (or rather 
workaround) any potential "path" troubles; relevant for the 
configuration file content, actual location of files, filesystem 
support, the PATH directive (which is still in need to be patched, see 
bugzilla) and, of course, KISS.

Regards,
Ady.

On 07-08-15 05:56, Ady via Syslinux wrote:
> If we are talking about UEFI x86_64, then the c32 files are all those
> located under the "efi64" directory tree of the Syslinux build.
Plus,
> the relevant "ldlinux.*" core module.
I wonder why ldlinux.c32 got renamed to ldlinux.e64 whereas all other 
modules remained their c32 extension. This confused me as a beginner.
> _ mixing c32 files from one firmware's architecture (BIOS, EFI32,
> EFI64) with another;
Does EFI32 exist out there in the real world?  Is it the same as EBC 
(EFI Byte Code) I see in the RFC for architecture 0x7?

Right now I just feed EFI64 to both 0x7 and 0x9 architectures because of 
the dhcpv6 spec mixup, but this is probably not safe in the future.

For now it works, because the HP is EFI64 and advertises as 0x7.

> _ not having all the required library modules in the right place.
Which should result in an explanatory error message anyway.

> These are the reasons for a frequent request: add some kind of
> "version" ID to each and all c32 files in some
"standard" way.
Seconded! ;-)

Also, an e32 or e64 extension will also help keeping conflicting modules 
apart.

> On 07-08-15 05:56, Ady via Syslinux wrote:
> > If we are talking about UEFI x86_64, then the c32 files are all those
> > located under the "efi64" directory tree of the Syslinux
build. Plus,
> > the relevant "ldlinux.*" core module.
> 
> I wonder why ldlinux.c32 got renamed to ldlinux.e64 whereas all other 
> modules remained their c32 extension. This confused me as a beginner.
 
 
Oh no, not again! I am... hmm... bored(?) with this question.

Although I understand the initial confusion and sympathize with the 
feeling, I don't want to write about this matter yet again; sorry.

There are several parts for a full answer about the matter, and even a 
part that has not been implemented in the code (yet), but the most 
important part to answer to beginners is: because you don't want to 
have to re-write the current configuration files (and documentation, 
and explain how older forum posts, blogs and emails would not be 
relevant anymore, and...).

For example:
LABEL lslabel
COM32 ls.c32

works for every firmware's architecture supported. It wouldn't work for 
"anyone and everyone" if we were to change the file name extensions 
according to each architecture, and each time you would want to change 
from BIOS to EFI* (or from EFI32 to EFI64) you would need to re-write 
the config file.

Then someone would suggest to "parse" the config differently, 
interpreting ".c32" and trying several variations if the first one 
fails. No, thank you. We have enough problems with enough different 
parsers already, and the other problems would not be avoided anyway.

For the other parts of the reasoning... Well, maybe some other day :). 
I am sure someone will ask (or even complain) about this in the future.

Unfortunately, web search engines treat this official Syslinux Mailing 
List as "dead" or "closed" or "inactive", or
simply ignore it, since
October 2012. In spite of this, _some_ posts are still being "found"
by
popular web search engines, most probably because they are referenced 
in some other mailing list, forum posts, blog... somewhere that is 
being accepted / cached by these search engines.


> 
> > _ mixing c32 files from one firmware's architecture (BIOS, EFI32,
> > EFI64) with another;
> 
> Does EFI32 exist out there in the real world?  Is it the same as EBC 
> (EFI Byte Code) I see in the RFC for architecture 0x7?
> 
> Right now I just feed EFI64 to both 0x7 and 0x9 architectures because of 
> the dhcpv6 spec mixup, but this is probably not safe in the future.
> 
> For now it works, because the HP is EFI64 and advertises as 0x7.
 
EFI32 does exist; most known ones (from a recent "era") are some 
(many?) tablet-like PCs.
 
> 
> 
> > _ not having all the required library modules in the right place.
> 
> Which should result in an explanatory error message anyway.
 
There is no limit to error / warning / information messages (which do 
exist to some degree, and could be seen more clearly when using the CLI 
and with no TIMEOUTs).

FWIW, "ldd" can be your friend :). See:
 http://www.syslinux.org/wiki/index.php/Library_modules 

Or, simply, copy over all the c32 files from the relevant architecture 
the same build.

Sometimes symlinks have been reported also as a problem. Whether this 
is a "user-related" problem or a really technical (file system
related)
one, I don't know. Therefore, I suggest _copying_ the whole set of c32 
files for troubleshooting purposes.
> 
> 
> > These are the reasons for a frequent request: add some kind of
> > "version" ID to each and all c32 files in some
"standard" way.
> 
> Seconded! ;-)
> 
> Also, an e32 or e64 extension will also help keeping conflicting modules 
> apart.
 
Different file name extensions are relevant for the core module, 
"ldlinux.*". It is not going to be relevant for non-core modules, 
especially non-library modules.

I am still hoping some day my (one year old) suggestion for optional 
alternative file _names_ for configuration files will be merged in the 
official Syslinux code, as part of the solution for multiple 
architecture support. That goes in the same direction as ldlinux using 
different file name extensions, and has no relation to the question 
about the other modules using the same c32 extension; I am just taking 
the opportunity to remind HPA and GeneC about it :).

Regards,
Ady.
 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>