Bug#922251: live-build: support syslinux-efi as (additional) bootloader
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. > > >>> 3) Remove ldlinux.c32 for extlinux and syslinux (6fc68c1d) I moved this into its own MR: https://salsa.debian.org/live-team/live-build/merge_requests/26 > > 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 ? > 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...). I changed to module32 and module64 now (also using module32 for the bios modules, for consistency). > > 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. > Good catch, will fix that. Fixed. Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Adrian, thanks again for your thorough review. I'm responding to both your e-mails inline below. > >>> 3) Remove ldlinux.c32 for extlinux and syslinux (6fc68c1d) > >> > >> 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. > > 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). > 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? 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. > > 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". > > 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 ? 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...). > >> 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 > > > > 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 :-) > > Well, you could have a binary_syslinux_cfg file similar to the > binary_loopback_cfg one or maybe binary_shared_cfg. 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
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
El 16/04/19 a las 20:17, Matthijs Kooijman escribió: > I pushed a new version with the above changes to > https://salsa.debian.org/live-team/live-build/merge_requests/19 > > Gr. > > Matthijs 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 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
El 16/04/19 a las 20:17, Matthijs Kooijman escribió: > Hi Adrian, > > thanks for your extensive review. I'll respond inline. > >> 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. > Familiar sentiment. Would be nice to have it, though. > >> What's your use case? What do you need to build live-build based hdd >> imgs? I'm curious. > 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. Ok, understood. >>> 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). >> >> Nice. What you need to make sure is that you cannot choose syslinux-efi >> when trying to build iso/isohybrid images. > Yeah, that's checked by the "Improve bootloader configuration checks" > commit. Ok, I saw that. >>> 0) backward incompatible change >> In the pull request there is a mention about a backward incompatible >> change. Can you please describe in what that change consists? > 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). 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. >>> 1) Refactor some bootloader scripts (969cdf4e) >> >> 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. > 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. Nice. >> 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. > I am indeed planning to reuse the function. I've clarified this in the > commit message. Then it's ok I guess. >> 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'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. Ok. Thank you. >>> 2) Reduce config duplication in syslinux variants (bccd127b) >> >> 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. > 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). 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. >>> 3) Remove
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Adrian, thanks for your extensive review. I'll respond inline. > 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. Familiar sentiment. Would be nice to have it, though. > What's your use case? What do you need to build live-build based hdd > imgs? I'm curious. 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. > > 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). > > Nice. What you need to make sure is that you cannot choose syslinux-efi > when trying to build iso/isohybrid images. Yeah, that's checked by the "Improve bootloader configuration checks" commit. > > 0) backward incompatible change > In the pull request there is a mention about a backward incompatible > change. Can you please describe in what that change consists? 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). > > 1) Refactor some bootloader scripts (969cdf4e) > > 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. 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. > 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. I am indeed planning to reuse the function. I've clarified this in the commit message. > 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'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. > > 2) Reduce config duplication in syslinux variants (bccd127b) > > 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. 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). > > 3) Remove ldlinux.c32 for extlinux and syslinux (6fc68c1d) > > 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. 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
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey Thierry, > Is there a chance that this work will be part of buster live-build > package, or is it too late already ? 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 signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey Adrian, [ About removing --templates from the manpage ] > In that case IMO that commit should be in its own pull request and not > the current one. Done: https://salsa.debian.org/live-team/live-build/merge_requests/21 Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
El 08/04/19 a las 21:29, Matthijs Kooijman escribió: > 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 Commenting below. > > 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. 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. > 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). Nice. What you need to make sure is that you cannot choose syslinux-efi when trying to build iso/isohybrid images. > Gr. > > Matthijs > 0) backward incompatible change In the pull request there is a mention about a backward incompatible change. Can you please describe in what that change consists? > 1) Refactor some bootloader scripts (969cdf4e) 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. > 2) Reduce config duplication in syslinux variants (bccd127b) 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) Remove ldlinux.c32 for extlinux and syslinux (6fc68c1d) 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 ? > 4) Move syslinux modules into subdirectories (53901001) 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) Add syslinux-efi bootloader support (a271f8f9) 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
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
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/ On Wed, Apr 10, 2019 at 09:58:54AM +0200, Matthijs Kooijman wrote: > Hi Adrian, > > > 1) What is the rationale behind removing the --templates option > > explanation on manpage? > 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 > > > Note: I will make more comments about this bug later in the week. > Thanks! > > Gr. > > Matthijs
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
El 10/04/19 a las 09:58, Matthijs Kooijman escribió: > Hi Adrian, > >> 1) What is the rationale behind removing the --templates option >> explanation on manpage? > 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 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 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Adrian, > 1) What is the rationale behind removing the --templates option > explanation on manpage? 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 > Note: I will make more comments about this bug later in the week. Thanks! Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
El 08/04/19 a las 21:29, Matthijs Kooijman escribió: > 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 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 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
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 signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Steve, > 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. 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 signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey Luca, > > 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. > > > > ... > > > > https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L79 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. > Ah silly me, I forgot something simple but quite fundamental: the point > of syslinux is to avoid using grub entirely. But indeed, I was aiming for syslinux, so none of this secure boot stuff will actually work with syslinux. Gr. Matthijs signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi, Steve McIntyre wrote: > Ady on the syslinux list has repeatedly argued against people > suggesting that syslinux-efi will work for disk/CD hybrid media. 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: > > > Maybe Steve McIntyre can contribute an anecdote how he came to the > > > decision in debian-cd to use GRUB2 for EFI Andreas Heinlein wrote: > > 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 ubuntu-12.04-server-amd64.iso indeed has an EFI boot image in its El Torito 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: > We already had working isohybrid media and I didn't want to drop that > - in my opinion it's a very important feature. > [...] > 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. 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
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
On Thu, 2019-02-14 at 18:35 +, Luca Boccassi wrote: > On Thu, 2019-02-14 at 17:18 +0100, Matthijs Kooijman wrote: > > Hey Luca, > > > > > At a quick glance it all sounds good to me, although I can't say > > > I > > > have > > > a lot of experience with syslinux. > > > > Ok. > > > > > 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. > > > > 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...). > > 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/bui > ld/binary_grub-efi#L79 > > Here we copy the binaries in the right places: > > https://salsa.debian.org/live-team/live-build/blob/master/scripts/bui > ld/binary_grub-efi#L164 Ah silly me, I forgot something simple but quite fundamental: the point of syslinux is to avoid using grub entirely. Then disregard anything I've said. D'oh! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Matthijs, There's quite a lot of text here - I hope it helps! :-) On Thu, Feb 14, 2019 at 05:18:42PM +0100, Matthijs Kooijman wrote: > >> 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. >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? 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 grub.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. >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...). 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. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
[ Gah, missed this bit... ] On Thu, Feb 14, 2019 at 05:35:48PM +0100, Thomas Schmitt wrote: ... >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. 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... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey folks, On Thu, Feb 14, 2019 at 05:35:48PM +0100, Thomas Schmitt wrote: ... >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 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, :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
On Thu, 2019-02-14 at 17:18 +0100, Matthijs Kooijman wrote: > Hey Luca, > > > At a quick glance it all sounds good to me, although I can't say I > > have > > a lot of experience with syslinux. > > Ok. > > > 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. > > 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...). 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 > > > 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?). > > 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 Yes we do support that - although not all combinations work IIRC. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Am 14.02.2019 um 17:35 schrieb Thomas Schmitt: > 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. 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
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi, Matthijs Kooijman wrote: > > > https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI I wrote: > > This describes the equipment of debian-live and debian-cd [...] > I'm a bit confused by your message. When you say "This", are you > referring to the syslinux isohybrid page? 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 sysli...@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. > > SYSLINUX EFI stuff is known not to boot from CD, DVD, or BD, but only from > > HDD, SSD, and alike. > 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? A little discussion on the list resulted in the decision not to mention 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 > Or does it then only work when booting the isohybrid image from a > HDD, rather than CD? 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
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey Luca, > At a quick glance it all sounds good to me, although I can't say I have > a lot of experience with syslinux. Ok. > 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. 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...). > > 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?). 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 signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Thomas, > > it seems isohybrid can include a small FAT filesystem with the > > bootloader files. [...] > > https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI > > 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. I'm a bit confused by your message. When you say "This", are you referring to the syslinux isohybrid page? > 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. 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 signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi, Matthijs Kooijman wrote: > it seems isohybrid can include a small FAT filesystem with the > bootloader files. [...] > https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI 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
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
On Wed, 2019-02-13 at 20:57 +0100, Matthijs Kooijman wrote: > Package: live-build > Version: 1:20180925 > Severity: wishlist > > 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. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Package: live-build Version: 1:20180925 Severity: wishlist 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
