Hi folks,

currently, live-build seems to only support EFI systems using the
grub-efi bootloader, but not for netboot or hdd images (effectively only
for iso images, I believe).

Syslinux also has an EFI version, that can be installed through
the syslinux-efi package. It would be useful for live-build to support
this. I need this for a client, so I'm planning to implement support in
the coming weeks. This report serves to track progress and discuss
the implementation.

I've done some experiments by adding syslinux-efi to an existing image
manually (not with a full live-build image, but with my own hdd image
that at least uses live-build for building the image, so should be
representative in this area). This shows that adding syslinux-efi is
fairly easy. The existing FAT partition can function as an ESP (EFI
System Partition) as it is now.

Installing the bootloader is a matter of dumping some files in the
EFI/BOOT directory. This lets the bootloader be detected as a fallback
bootloader, which is AFAIU intended for removable media. Syslinux needs
some additional files (ldlinux, additional modules, configuration) which
can live in that same directory.

Both 32-bit and 64-bit EFI can be supported at the same time, by
installing both versions of syslinux-efi (named bootx64.efi and
bootia32.efi respectively). One caveat is that syslinux needs different
.c32 modules for both architectures (though they are both named .c32 and
are explicitly referenced in the config file). This means either
duplicating the bootloader configuration file for 32 and 64 bit (which
hinders modifications to the config), or putting the modules in
subdirectories and using the PATH config directive to point to either
directive before including the common configuration. I have not tried
this latter approach but it is described here (though currently
syslinux.org seems to be unavailable, I tried the Google cache):

https://www.syslinux.org/archives/2014-August/022545.html

(subject: syslinux efi configuration file name proposal)

I've also tried to let the syslinux-efi config file include the normal
syslinux configuration file (or at least the bulk that is in live.cfg),
which seems to work just fine.

Since config sharing is easy and syslinux-efi is a matter of adding some
files to the existing image, it would make sense to add syslinux-efi by
default on normal syslinux hdd images (perhaps adding a new option to
disable this?). This also seems to hold for ISO9660 images, where
it seems isohybrid can include a small FAT filesystem with the
bootloader files. This might need some additional work to generate the
filesystem image and/or pass options when generating the iso. See:

https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI


Using syslinux-efi exclusively (e.g. passing it to --bootloader and not
installing normal syslinux) might also be an extra option. However, I'm
not much interested in this case, so I will likely not implement it
(I'll try not to make it too hard to add it later).


In terms of code, this is probably best implemented in the existing
binary_syslinux script. The bulk of what needs to happen is essentially
copying bootloader files from config/bootloaders into binary, taking
care to resolve symlinks. I'm planning to put the code that does that
into a shell function, so it can be called at the current place and then
a second time for syslinux-efi later.

I think it would be good to copy files *from*
config/bootloaders/syslinux-efi-addon or something similar, to leave
config/bootloaders/syslinux-efi available for an EFI-only image. These
two directories would be identical in terms of syslinux binary files,
but the configurations would differ (the addon would include the normal
boot/syslinux/syslinux.cfg, while the standalone version would contain
the complete config).

I haven't really looked at the iso version yet (which is also not my
primary interest, but I think it would be good to handle as well).

Happy to hear any thoughts :-)

Gr.

Matthijs

Hi,

At a quick glance it all sounds good to me, although I can't say I have
a lot of experience with syslinux.

For feature parity, I'd encourage to look into supporting Secure Boot
like the grub-efi implementation does, since we are preparing to ship
that in Debian 10. It's not much extra work on top of adding the rest
anyway.

Hi,

Matthijs Kooijman wrote:

This describes the equipment of debian-live and debian-cd (DVD-*, BD-*,
netinst) ISOs. See e.g. debian-live-9.5.0-i386-xfce.iso and its
MBR partition table.

Debian and nearly all others use GRUB 2 for their EFI capable ISOs.
See Knoppix 8.[12] for examples of SYSLINUX EFI in ISOs.

SYSLINUX EFI stuff is known not to boot from CD, DVD, or BD, but only from
HDD, SSD, and alike.


Have a nice day :)

Thomas

Hi Thomas,
I'm a bit confused by your message. When you say "This", are you
referring to the syslinux isohybrid page?
Again, I'm confused. If syslinux-efi is known not to boot from
CD/DVD/BD, then why do they document how to include it into an isohybrid
image? Or does it then only work when booting the isohybrid image from a
HDD, rather than CD?

Gr.

Matthijs

Hey Luca,
Ok.
Can you elaborate a bit on how grub-efi supports Secure Boot exactly? I
can't really find anything about this in the code?

Looking at build/scripts/binary_grub-efi and build/scripts/efi-image, I
see that a new efi firmware binary is built using grub-mkimage, so I
suppose that that image is not already signed, and there is nothing
suggesting that image is be signed at that time. Looking at binary_iso
there is also no reference to signing or secure boot.

AFAIU, to support secure boot, you need to sign the bootloader,
typically using a key from MS. I've read about the Shim bootloader,
which is signed and typically used to then load grub or other
bootloaders (signed by the Debian key or other keys included in Shim).
However, I can see no reference to shim either.

Looking at the grub package more closely, I *think* that it installs shim
alongside grub when using grub-install, but that is not used here?

Regardless, how would you suggest we "support Secure Boot" with
syslinux-efi exactly? AFAICT there is no syslinux-efi image available
signed with the MS key, and I suspect it is not signed with the Debian
key or any other key used by shim (also, since syslinux does not seem to
support key verification on kernels, I guess there is no secure way to
get syslinux booting under secure boot without compromising secure boot,
but I might be missing an important point about SB here...).

I just noticed that lb config has a --bootloaders that supports
*multiple* bootloaders, so that would be perfect way to support this.
E.g. --bootloaders syslinux,syslinux-efi to have combined image (which
would also become the default for hdd images), or an explicit
--bootloaders syslinux or --bootloaders syslinux-efi to choose either
one individually.

Gr.

Matthijs

Hi,

Matthijs Kooijman wrote:

I wrote:

Yes. The doings of SYSLINUX program "isohybrid" are also implemented in
libisofs underneath xorriso.

It was me who wrote that wiki page with info collected from the
mailing list syslinux@zytor.com and with my knowledge as developer of
libisofs and xorriso.
But currently i get "Connection refused" when trying to connect to
www.syslinux.org. So i can only see the Google "cached" document or
a text draft of mine from june 2014.
the SYSLINUX EFI problems or GRUB2. Courtesy among upstreams ...

Regrettably there is still no official position towards the failure with
SYSLINUX EFI code booting via El Torito from optical media.
But already the inventor of the "isohybrid" program's --uefi option,
Matthew J. Garrett equipped his Fedora ISOs by EFI software from GRUB2
together with BIOS software from SYSLINUX. (Plus some HFS+ filesystem
image pointed to by an Apple Partition Map.)
Maybe Steve McIntyre can contribute an anecdote how he came to the
decision in debian-cd to use GRUB2 for EFI and thus to create the need
for two independent boot menu configurations.

Klaus Knopper, on the other hand, believes that it could work on some
machines. But he tested only with virtual machines and i found no
confirmation that it works on any real iron in native EFI mode from DVD.
See e.g. this 4 GB image:
http://ftp.uni-kl.de/pub/linux/knoppix-dvd/KNOPPIX_V8.2-2018-05-10-EN.iso

If you find a real machine that boots in native EFI mode Knoppix 8 from DVD,
then this would be a novelty.  (Virtual machine firmware is known to be
sloppy with the distinction of HDD and CD-ROM boot paths.)


Have a nice day :)

Thomas

Am 14.02.2019 um 17:35 schrieb Thomas Schmitt:

I am only taking a guess here, but maybe he just took over something
that was already done in Ubuntu. IIRC, Ubuntu 12.04 was the first distro
to support EFI booting (without Secure Boot, that was introduced in
14.04 via shim), and they did it that way. One reason was that Syslinux
EFI wasn't ready at that time. The other one was that Ubuntu
traditionally put a lot of effort into user experience, and they were
using gfxboot as menu system with legacy syslinux. Unfortunately,
gfxboot hadn't been ported to EFI the last time I asked about two years
ago. A quick google search didn't turn up anything new, so I guess that
is still the case. Someone on the syslinux mailing list told me that the
gfxboot code was actually from someone not directly involved with
syslinux and more or less abandoned, so someone would have to dive into
it and port it to EFI. That means if you want to use syslinux EFI, you
will have to stick with its traditional menu system. On the other hand,
grub themes allowed for similar "shiny" menus so they chose this.

Bye,

Andreas

So for the secure boot case in binary_grub-efi, what we do is that if
the signed monolithic EFI binaries are available we copy those instead
of building a new image. As you correctly mentioned these have to be
signed already, so we can't do that when building the image, but they
are already available in the Debian archive as packages.

Here we check if they are available:

https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L79

Here we copy the binaries in the right places:

https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L164

Yes we do support that - although not all combinations work IIRC.

Hey folks,

On Thu, Feb 14, 2019 at 05:35:48PM +0100, Thomas Schmitt wrote:

...

Ady on the syslinux list has repeatedly argued against people
suggesting that syslinux-efi will work for disk/CD hybrid media. I've
not looked at the code to see why - I have no desire to, :-)

[ Gah, missed this bit... ]

On Thu, Feb 14, 2019 at 05:35:48PM +0100, Thomas Schmitt wrote:

...

We already had working isohybrid media and I didn't want to drop that
- in my opinion it's a very important feature. Plus, when I first
started hacking on EFI things back in 2011 (or was it 2012? not sure)
I genuinely could not get syslinux to do anything useful with EFI. As
I already knew that people had EFI working with GRUB for booting off
disk, I went that way and had a prototype running in a couple of
days. Hacking on menus etc. was relatvely easy in comparison after
that.

Once we had that, it was an obvious step to use the same setup on live
media as was already known to work on installation media.

In fact, one of the projects I've been trying to get to for a couple
of years now is simplifying things by going the other way: using GRUB
for everything and dropping syslinux on Debian media.

I guess I can see the attraction of syslinux, but I don't want to use
it any more if I can avoid it. GRUB is massively more flexible and
powerful. It's cross-platform (x86, arm32/arm64, sparc, powerpc, mips
at least), actively maintained and reasonably well understood by quite
a large group of people. It's far from perfect (as we all know!), but
I think it's the best solution we have.

That's my story for Debian EFI...

Hi Matthijs,

There's quite a lot of text here - I hope it helps! :-)

MS won't sign GRUB directly due to the licensing. So that's one of the
reasons why shim was developed. It's a small piece of software which
lives entirely in the UEFI environment and can be readily
verified. The shim binary shipped by each distro includes a public key
*specific to that distro* which is used to verify the rest of the
stack that comes afterwards (GRUB -> Linux, normally). Machine Owner
Keys (MOK) can be added too, under the control of the Machine Owner
(hence the name!) rather than by the distro. GRUB has some knowledge
of how SB works, but AFAIK there's not much needed - it's calling into
APIs provided by the UEFI platform and shim underneath it.

Debian has a shim binary signed by Microsoft, including our own
key. We have implemented a process to create signed versions of a very
small number of our own packages:

 * GRUB
 * Linux
 * fwupd
 * fwupdate

and you can find those signed versions in the archive in Sid and
Buster.

In terms of building a grub binary is well-understood, as you can see
in the build/scripts/efi-image script in live-build. But that will
never give you a signed binary. Instead, if you look in the equivalent
efi-image script in the d-i build system you'll see that it's been
updated. For some arches (amd64 only so far, with others to come), we
still build the grubXXXX.efi binary, but where possible we grab the
binary directly from the -signed package in the archive so we can keep
that signature.

For Debian's official live images built with live-wrapper, we just
pull in the same files that d-i has created so we inherit the same SB
support.

No, you're correct. syslinux is not in a state to do SB at all, and I
can't see it happening any time soon.

of syslinux is to avoid using grub entirely.

Then disregard anything I've said. D'oh!

Hi,

Steve McIntyre wrote:

Ady emphasized that it does work with HDD. It was others and me who
pointed out that nobody ever could show success with CD-ROM on real iron.

For a short while Klaus Knopper convinced me that his complete mini-GNU/Linux
inside the EFI partition could solve the problem. But then appeared
negative reports on the german support forum and no positive ones.
It does work from USB stick but still not from DVD.


I wrote:

Andreas Heinlein wrote:
catalog. The MBR partition table does not have an entry of type 0xef, though.
So it was not treated by isohybrid option --uefi.

The boot image has the path "/boot/grub/efi.img", a FAT filesystem with
only one data file
  /EFI/BOOT/BOOTX64.EFI
of which the end looks much like Debian's BOOTX64.EFI when it tries to hop
from EFI partition to ISO filesystem:
  search --file --set=root /.disk/info
  set prefix=($root)/boot/grub/x86_64-efi
  source $prefix/grub.cfg

In debian-9.3.0-amd64-netinst.iso we can see:
  search --file --set=root /.disk/info
  set prefix=($root)/boot/grub
  source $prefix/x86_64-efi/grub.cfg
  (memdisk)/boot/grub

So possibly Colin Watson was the one who first used this GRUB gesture
within the EFI partition / boot image.


Steve McIntyre wrote:

See results of program grub-mkrescue when grub-pc and grub-efi-ia32-bin or
grub-efi-amd64-bin are installed.

The main disadvantage of grub-mkrescue ISOs with EFI partition is the
lack of a mountable ISO partition. For exploring other layouts, i made a
man-in-the-middle script to be run as

   grub-mkrescue --xorriso=frontend/grub-mkrescue-sed.sh ...

which manipulates the xorrisofs options before running the real xorriso.

I like the result of its default mode "mbr_only" and of mode "gpt_appended"
both with -partition_offset 16.
See
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/frontend/grub-mkrescue-sed.sh


Have a nice day :)

Thomas

Hey Luca,
Aha! Turns out I was looking at an old version, I messed up my git
checkout apparently. That script indeed does what I would expect:
Install shim alongside grub and use signed grub to make shim load it.

But indeed, I was aiming for syslinux, so none of this secure boot stuff
will actually work with syslinux.

Gr.

Matthijs

Hi Steve,

Hm, that's another interesting thought. I was aiming for syslinux, since
our current setup uses that (along with some custom configuration).
However, that seems to be impossible to work with secure boot (which
would be nice to have) and impossible to boot from optical media (which
for my personal case is not an issue).

I could imagine switching to grub completely (which means that this
issue changes from "add syslinux-efi" to "make grub-pc & grub-efi work
for hdd images"), though that's probably a bit more work for me and my
client.  I'll dig in a bit deeper to see how much work that would be.

Thanks for everyone's input so far!

Gr.

Matthijs

Hi Luca & others,

I've been working on syslinux-efi support in the past weeks and just
submitted a MR with a working implementation, along with some small
bootloader-related cleanups and refactors:

https://salsa.debian.org/live-team/live-build/merge_requests/19

In the end, I opted to implement syslinux-efi rather than make grub-efi
work on hdd images, since that seemed easier and allows preserving the
existing bootloader config files in our project. Getting grub-efi to
work on hdd images might still be an interesting project that could be
implemented alongside syslinux-efi support, though I do not have any
specific purpose for it as of yet.

As predicted by others in this bug report, my work does not enable
secure boot (which syslinux simply does not support), nor enable
syslinux-efi support in iso/isohybrid images (since syslinux-efi does
not support this, or at least it apparently does not work).

Gr.

Matthijs

El 08/04/19 a las 21:29, Matthijs Kooijman escribió:

1) What is the rationale behind removing the --templates option
explanation on manpage?

Do you remove it in any of your commits? Which one?
Or someone else did remove it?

Thank you.

Note: I will make more comments about this bug later in the week.

adrian15

Hi Adrian,
I wondered about this option and looked around the source for it, but
could not find any implementation for it, so it seemed good to remove
the documentation for it.

Prompted by your question, I looked a bit further and found that it was
indeed removed:

https://salsa.debian.org/live-team/live-build/commit/7e633e77f24b6f5ab9a8b22d7d6cf6521454d638
Thanks!

Gr.

Matthijs

El 10/04/19 a las 09:58, Matthijs Kooijman escribió:

In that case IMO that commit should be in its own pull request and not
the current one.

That way it can opt to be applied inmediately while the rest of your
commits is being studied.

adrian15

Dear Matthijs,

thanks a lot for your work on syslinux-efi, i am relying on syslinux for
Sage Debian Live [1], and more and more laptops are not able to boot on
legacy (bios) formatted devices (including macs).

Is there a chance that this work will be part of buster live-build
package, or is it too late already ?

Ciao,
Thierry

[1] https://sagedebianlive.metelu.net/

El 08/04/19 a las 21:29, Matthijs Kooijman escribió:
Commenting below.
I implemented multi bootloader support back in the day and maybe
grub-efi, not sure about that last one.

I didn't implement the hdd part because I didn't know what was the
purpose of an hdd image and how I was supposed to test it.

I might take a look into your notes to implement grub-efi + secure boot
in hdd img but... this might be in 2021 XD . Too busy at the moment.

What's your use case? What do you need to build live-build based hdd
imgs? I'm curious.

Nice. What you need to make sure is that you cannot choose syslinux-efi
when trying to build iso/isohybrid images.
In the pull request there is a mention about a backward incompatible
change. Can you please describe in what that change consists?

1.1) Nice idea the Get_Bootloader_Config_Dir function.
Have you made sure that $BOOTLOADER variable is not used anywhere else
in the code?
Maybe you should make that variable local.

1.2) The function Install_Bootloader_Files does not seem to be right.
If you are not going to reuse that function in more than one place (I'll
check your other commits later) you might consider not having that
function in the first place.

Even if the Install_Bootloader_Files function was a good idea it's not
well implemented commit-wise. You are performing two changes. One about
moving the functionality to a function. Another one is chaning the
comment about "two steps" to "three steps". It's hard to notice if you
changed something other than that comment on that commit.

I mean... this part should be splitted in two commits.

I know it's better the way you merge files there but I think the
original idea was about having independent configuration files for each
different media.

I mean there were not meant to be merged together in the first place.

3.1) Nice. I didn't know about those new syslinux architecture dependent
files. As per the wiki you link (
https://wiki.syslinux.org/wiki/index.php?title=Library_modules#All_Syslinux_variants_need_an_additional_ldlinux_module
) in the commit description I guess that even ldlinux.c32 wouldn't be
used but ldlinux.e64 instead.

3.2) BTW Do you support both EFI IA32 and EFI X64 or only EFI X64 ?

Shouldn't those c32 modules be moved to a folder named c32-modules (or
c32mods for short name) instead?

Let's see how you name the UEFI modules folder later.

In "Add syslinux-efi bootloader support (a271f8f9)" you use modules32
folder name for some c32. Shouldn't you use modules32 as a folder name
in this "Remove ldlinux.c32 for extlinux and syslinux (6fc68c1d)" commit
in the first place?

I'm not sure about this one I might be missing something.
5.1) You have got a nice bug on that code XD . Just after the Echo_error
statements about syslinux-efi not being supported there should be an
exit 1 statement.

Else you are just echoing a warning but not stopping the build.

5.2) Anyway I don't think I like this code at all. I mean... you are
supposed to create a new file named:
scripts/build/binary_syslinux-efi
and not hack around the existant one: binary_syslinux
.

I know it's difficult to work on a new binary file because of the way
binary_syslinux handles kernel images and renames them.
But I was able to handle that on the loopback.cfg binary file.

Probably the common code for generating cfg files should be on a common
binary file which it's only triggered if either binary_syslinux or
binary_syslinux-efi is being used as a bootloader.

5.3) I see you add a lot of c32 and efi as symbolic links to paths on
the system.
I'm not sure this is the right way of doing this.
Are other equivalent files already implemented like you are doing?
Or is it me finding it out for the first time.

5.4)
In "Move syslinux modules into subdirectories (53901001)" you are using:
"path modules"
here you are using:
"PATH /@EFI_DIR@/modules32"
.

This should be using either "path" in both files or "PATH" in both
files. As the rest of the syslinux commands are in non capital letters I
suggest using "path".

6) Only default to grub-efi for iso* images (118de99a)

Seems good to me.

7) Improve bootloader configuration checks (5fb9ab31)

I need to read through these changes another day.
Was live-build to be based on python given a compatibility matrix based
on nested arrays... this should be easier to implement.

8) Remove --templates from lb_config manpage (371892af)

As I said in another mail this option makes more sense in another pull
request but I guess you can leave it in this pull request for now.

9) Use syslinux-efi for hdd images by default (4e292ed0)

Seems good to me.

10) I think buxy implemented syslinux-efi support back in the day. I
guess it wasn't added to live-build because of reasons? Because grub-efi
enabled Secure Boot to work?

Anyways... Did you ever check buxy's work just in case it has something
that you can recycle?



I'll try to comment on "Improve bootloader configuration checks
(5fb9ab31)" on the next days. I need to be focused on this one :) .


Waiting for your feedback on the rest of the points. Hopefully we can
agree on the binary_syslinux-efi creation and other points :) .




adrian15

Hey Adrian,

[ About removing --templates from the manpage ]
Gr.

Matthijs

Hey Thierry,
I'm not the maintainer of live-build, but given the freeze state that
buster is in, I highly doubt this will make it into buster.

Gr.

Matthijs

Hi Adrian,

thanks for your extensive review. I'll respond inline.
Familiar sentiment. Would be nice to have it, though.
I'm using live-build to build Webconverger (a kiosk OS booting into a
full-screen browser) and an image derived for that for Bizplay (a
digital signage system).

We need hdd images rather than isohybrid images, so the resulting
USB-disk can be written to. This is needed firstly to update the
bootloader configuration to change the kernel commandline (we use this
to customize the image, e.g. change the default homepage shown).
Secondly, the image uses git to manage the root filesystem and a running
image can update itself, but that again needs a writable filesystem.
Yeah, that's checked by the "Improve bootloader configuration checks"
commit.
I've added one commit with a NEWS file that describes this issue in a
bit more detail. Does that clarify sufficiently?

Note that while writing the NEWS entry, it seemed more confusing to have
a bootloaders/syslinux-common directory as well as a syslinux-common
Debian package, so I ended up modifying my commits to use
"syslinux-shared" rather than "syslinux-common" (I'll also use the
former below).
Good point. I guess I was following the style of other functions (that
dod not use local variables either), but that's no reason not to do it
here. I updated the PR with this change.
I am indeed planning to reuse the function. I've clarified this in the
commit message.
I'm usually a nitpick in this area, but here I decided for a bit more
simplicity. You're right, though. I ended up splitting this into three
commits, one for Get_Bootloader_Config_Dir, one for
Install_Bootloader_Files and one for the comment.
The reason to do this, is that I want configuration files to be shared
between syslinux and syslinux-efi (which can co-exist in the same
image). If these would be duplicated everywhere, modifying the
bootloader config after an image is written to disk requires modifying
it in two places.

Note that syslinux-efi could still not have its own config files, but
refer to files contained in bootloaders/syslinux (without the need for
bootloaders/syslinux-shared), but then you can never have an image that
*only* contains syslinux-efi (which you can with the syslinux-shared
approach, since then you use syslinux-shared for the config and
syslinux-efi for the efi images).
Actually, ldlinux.e64 is only for EFI. This commit only touches
BIOS-related stuff. I'm not sure how "architecture dependent files" are
relevant here, since this commit just removes some files which are
really superfluous (since the 'syslinux' and 'extlinux' commands used to
install the bootloader in binary_hdd make sure to copy their own version
of these files into the image).
Yes, but that's a later commit.
I think the missing bit might be that
bootloaders/{syslinux,syslinux-shared} is installed into binary/boot,
while bootloaders/syslinux-efi is installed into binary/EFI/boot, so
these are distinct locations.

Also, EFI supports 32 and 64 bit (hence modules32 and modules64), but
BIOS is (by definition, I think) only 32-bit, so I just used "modules".
Thanks, fixed.

That would make sense if I wanted syslinux-efi to be really indepenent,
but as I noted above, I wanted to make them share a single configuration
(and also allow syslinux-efi to be installed by itself). This seemed
like best way to achieve that, though alternative suggestions are
welcome :-)

I pushed a new version with the above changes to
https://salsa.debian.org/live-team/live-build/merge_requests/19

Gr.

Matthijs

El 16/04/19 a las 20:17, Matthijs Kooijman escribió:
Ok, understood.
Ok, I saw that.
Ok, now 'Add NEWS entry about syslinux config refactoring'
(00eab3a7) makes clear what it's not backward compatible (under certain
circumstances).

It's ok for me.
Nice.
Then it's ok I guess.
Ok. Thank you.
Ok, I guess it's fine. live-wrapper produced ISOs from official Debian
also have those common and shared cfg files I guess that stolen from the
way Ubuntu (and other distros) deal with this too.
I'm revisiting this commit and I'm not sure this is right thing to do.
If your pull request only affects syslinux-efi why do you even care
about 32bit code?

You are assuming that syslinux and extlinux commands are only used in
binary_hdd and by grepping the code it's seems to be true. So it's ok
with this assumption.

I guess that this directory was initially meant to be used as a template.
So it makes sense to keep those c32 files into their original place.
Just in case you want to override these files with your own custom c32
files.

Is it worth keeping those files there nowadays?
They are just symlinks after installing the package.

Well, I'm not sure about this one commit.

Anyway I think this commit should be on its own Merge Request because I
think adding syslinux-efi is going to work regardless of these files
getting into the final disk.
Ok.
You are right. This was the missing bit. I see.

Well, I think you should use something else.
modules32 is 9 characters long (not 8.3 compatible). What about module32
and module64? So that we can reuse the code in the iso side when
isolinux is updated to support hybrid isos in efi mode ?
Nice.

Well, you could have a binary_syslinux_cfg file similar to the
binary_loopback_cfg one or maybe binary_shared_cfg.

6.1)
PATH syslinux command is still being written in capital letters in
share/bootloaders/syslinux-efi/syslia32.cfg and
share/bootloaders/syslinux-efi/syslx64.cfg while it should be written in
non-capital letters.

6.2) What you should learn about the multibootloader support is that it
should let use as much as bootloaders as you want to.

So, you could have something like:


adrian15

El 16/04/19 a las 20:17, Matthijs Kooijman escribió:



7) Only default to grub-efi for iso* images (47d99222)
Looks good to me.
8) Use syslinux-efi for hdd images by default (658c0e2d)
Looks good to me.
9) Improve bootloader configuration checks (3e6645a2)
Well, the way how defaults.sh checks if anything is valid is kind of
antique.

In my opinnion binary_syslinux, binary_syslinux-efi, binary_grub-pc and
so on... should be able to be sourced and use sort of can_i_boot
function where you input architectures, filesystem and if the bootloader
is the first bootloader or not.

Then the binary_syslinux (or whatever) replies.

Anyways... that would be another improvement towards moving live-build
into a more Object-Oriented approach.

I haven't checked every possible combination you put there I guess it's ok.

So, once again looks good to me.


adrian15

Hi Adrian,

thanks again for your thorough review. I'm responding to both your
e-mails inline below.
True, this was just a cleanup I came across. It is sort of related due
to the next commit that moves all c32 modules into a subdirectory. I
wondered whether to also move ldlinux.c32 and whether leaving it would
cause problems with the CWD change in the EFI boot. I then concluded the
file was not used at all and just sidestepped the issue by removing it
entirely.

I did one more test and noted that the existence of these files do not
cause problems for syslinux-efi. I'm not sure it it makes sense to keep
them or not, but dropping this commit from this MR for now seems fine
with me.
Good point, hadn't considered 8.3 compatibility. Singular "module32"
sounds a bit weird to me, but it is probably clearer than something like
"mods32" or even just "c32" (the latter seems reasonable, except that
the "c64" directory would then still contain ".c32" files since that's
what 64-bit syslinux-efi also uses...).
That would indeed make some sense. I had not really considered this
before, but did now. The problem with this approach is that both
binary_syslinux_cfg, binary_syslinux and binary_syslinux-efi would need
to duplicate code. At least they all need Install_Bootloader_Files,
which could be slightly generalized and moved into functions.

There is also a bunch of code which post-processes .cfg and splash.svg
files. This would be mostly needed in binary_syslinux_cfg only (since
the syslinux/syslinux-efi only contains a minimal config file that
includes the shared config file and needs minimal post-processing).

However, if binary_syslinux_cfg would install syslinux-shared and then
do all the post-processing, followed by binary_syslinux and/or
binary_syslinux-efi without any post-processing, you would:
 - lose the ability to override some the shared config files with
   bootloader-specific (e.g. syslinux/isolinux/extlinux)
 - lose backward-compatibility with existing live-build configs that do
   not have a syslinux-shared config directory but have all their config
   in the bootloader-specific directory (which is installed *after*
   configs are post-processed).

This can probably be fixed by further splitting the cfg step into an
install and post-processing step. You would then get:
 - binary_syslinux_cfg that installs config files verbatim (runs if any
   of syslinux/extlinux/isolinux/syslinux-efi is selected).
 - binary_syslinux that installs the modules and main config file for
   syslinux/isolinux/extlinux (runs if any of syslinux/extlinux/isolinux
   is selected, but not if only syslinux-efi is selected).
 - binary_syslinux-efi that installs the modules and main config file for
   syslinux-efi (runs if syslinux-efi is selected).
 - binary_syslinux_proces_cfg that post-processes all config files
   installed by previous steps (runs if any of
   syslinux/extlinux/isolinux/syslinux-efi is selected).

But I'm not so sure that this is really better than the current
single-script for everything approach (which essentially just does the
above four steps in a single script).
Good catch, will fix that.
I see, and I think this still "works" with my MR.
I'm not so convinved that this is how it should be. I guess the
complication comes from HDD images, as you mentioned. On ISOs you just
have multiple bootloader "slots" with one being the default. On a HDD
image, you sort of have 2 bootloader "slots": the BIOS MBR and the EFI
boot dir. As long as you select only one BIOS bootloader and one EFI
bootloader, they can (and probably should) nicely coexist. Once you
select more than one, they will likely overwrite each other, or perhaps
only the first one should take effect (the latter is how it works with
ISOs, I guess.).

I guess the interpretation of multiple bootloaders is currently
image-type-specific:
 - For iso images, all bootloaders are installed and the first one is
   made the default.
 - For hdd images before my MR, only the first bootloader is installed.
   Any extra bootloaders have their config files installed, but they are
   not installed into the MBR. EFI bootloaders are not supported for hdd
   images.
 - For hdd images with my MR applied, any BIOS bootloader is only
   installed if it is the first bootloader. Any EFI bootloader (which
   can only be syslinux-efi) is installed, regardless of its position.
   Multiple efi bootloaders would overwrite each other.

This might warrant an extra configuration check for hdd images perhaps,
that checks that no BIOS-bootloader appears in second or further
positions and only one EFI bootloader appears in the list? I did not add
anything like that, since there is no such check in place currently and
I did not want to further complicate the MR.
I actually think no grub is supported by hdd, the only grub code in
there is in a big FIXME:
https://salsa.debian.org/live-team/live-build/blob/00eab3a77f3da176f3f0aa807b886206f8f0f0f1/scripts/build/binary_hdd#L282-311

But this is probably beside the point.
This is what the current MR implements. In this case, the
"syslinux-shared" configuration is installed, which is referenced by the
"syslinux-efi" installation.

See https://salsa.debian.org/matthijs-guest/live-build/blob/syslinux-efi/scripts/build/binary_syslinux#L165-171
In what sense would you want to improve this? It's not very pretty that
binary_hdd has to know about each bootloader, but since bootloader
installation in most cases needs details about the image type and
bootloader, some crossover is going to be present anyway.

Or did you see something else to improve?
I do not think any updates to binary_hdd are needed for efi support (and
any improvements I can see to binary_hdd are mostly unrelated to efi
support as well). Would that answer your question?
Yeah, I usually rebase whenever I push an update.
That would certainly be better, but also out of scope for this PR (and
probably an intrusive change as well...).

I'll make the changes mentioned above later (no more time now), but feel
free to already respond to the above in the meanwhile :-).

Gr.

Matthijs

Hi Adrian,

I just updated the MR with the changes I discussed in my previous mail
(and also listed below). My previous mail also contained some responses
and questions, if you have some time to respond to those that would be
great.
I moved this into its own MR:
https://salsa.debian.org/live-team/live-build/merge_requests/26
I changed to module32 and module64 now (also using module32 for the bios
modules, for consistency).
Fixed.

Gr.

Matthijs

-- 
How Are You,
I'm Mr. Ali Moses, how are you doing hope you are in good health, the
Board director try to reach you on phone several times Meanwhile, your
number was not connecting. before he ask me to send you an email to
hear from you if you are fine. hoping to hear from you soonest.

Thanks
Mr. Ali Moses

Sincerely.
Dr. Irene Lam.