Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
Response embedded below. Just a quick note first - it was a little hard to read the response you wrote because the embedded responses were directly adjacent to the quoted text, with no spacing between (my email client does not automatically add spacing and shows both quote and text in similar colours unfortunately); it'd be helpful to add some spacing please next time. :) On Thu, 2020-04-16 at 01:15 +0200, adrian15sgd wrote: > El 8/4/20 a las 16:56, jnq...@gmail.com escribió: > > To fix the issue of broken EFI booting when syslinux is not used > > (and > > thus binary_syslinux was not put in place /live/vmlinuz), I was > > intending to solve by moving creation of short filename kernel > > files > > out of binary_syslinux into somewhere common. > > > > The first problem with this though is that alone of course it is > > not > > enough because it does not cover the `/live/vmlinuz1` multi-flavour > > case, so a change to binaru_grub-efi would also be needed in order > > to > > dynamically change the searched for file to /live/vmlinuz1 where > > appropriate. > > You should also know that current isolinux/syslinux supports booting > from long filenames. So we could ditch using short 8.3 names for the > kernels. Ok, noted, though I don't know that I'll bother the team with submitting that change for now at least. > This problem about having to update binary_grub-efi for searching > for > long names would arise anyways. Except when switching to a solution not involving the kernel filename, as is the case now with the `/.disk/info` based search now merged. > > However, I now understand from reading #924053 that although this > > would > > fix things in all/most cases, it's at risk of breaking for odd > > situations like your HP laptop case. Using /.disc/info as the > > searched > > for file as proposed in #924053 is much a better solution. > It collides with Ubuntu live usbs which also have /.disc/info but it > would be a quick and easy fix for the current situation where HP > laptop > are involved. Exactly. > > My current intention is to take the patch of yours provided in > > #924053 > > that makes this change, though with a tweaked commit message (I > > think > > the problem is EFI specific not Secure Boot specific), and submit > > it in > > an MR, along with the fix for grub-pc, and some additional loosely > > related work, in one or more MRs. > The Secure Boot code works from an EFI sort-of-ramdisk so it needs > to > find its own root somehow. That's why it was Secure Boot specific. Ok. I can't say that I currently follow. It's been a long time since I last researched bootloader specifics, and I don't think there even was Linux secure boot support back then. I was a little confused (1) by the comments in the binary_grub-efi script as to which bits were generically EFI and which bits secure boot, considering you saying the bit concerning the root search is secure boot specific, and (2) from the fact that the search bit seems involved in loading an image in an EFI virtualbox VM, which I don't think emulates secure boot. But anyway, I think you know more about this than I currently... > > While the concept of correctly identifying discs (aka liveid type > > stuff) is interesting and of some potential value, priority should > > be > > given to simply fixing the ability to create working images first > > and > > foremost. > > > > I will have the patches mark this bug and #924053 as closed, and > > leave > > you to create a new wishlist bug to propose or re-start discussion > > of > > the unique-disc identification stuff as you wish. > > I don't think your solution is optimal (because you are postponing > the > actual fact that every live cd cannot detect itself). > > Liveid let's you find the correct live cd. As things stand with the currently released version of live-build, we have the following problems: 1. If using `--bootloaders grub-pc` you get an unbootable image. 2. If using `--bootloaders grub-pc,grub-efi` you get an unbootable image in both BIOS and EFI (I'm not certain grub-efi can be used on its own, I've not tried, but presumably it would fail just the same). 3. If using `--bootloaders syslinux,grub-efi` with multiple kernel versions such that you end up with `vmlinuz1`, you get an unbootable image for EFI. 4. You've got the problem with the HP system. 5. You've got the problem liveid focusses on of correctly loading the right image in a situation where there are multiple (multiple CDs/DVS/pendrives; a pendrive containing multiple images like with rEFInd). Solving them: - The first four are easily solvable with just two tiny tweaks (the `- -prefix=boot` grub-pc fix and the `/.disk/info` based search fix, both of which have now been merged. - Fixing the last requires a much bigger and more complex solution, with lots of decisions to make on how to proceed, issues with whether or not the team will like the proposed solution, etc. The difficulties with getting a final
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
Apologies once again for the time it's taking to get back to you, so
much to do. I'll try to get focussed on responding to all of your
messages now/next...
The fix for this bug report has been merged now since your response.
The piece of code modified to add `--prefix=/boot/grub` lived within a
condition of `"${LB_FIRST_BOOTLOADER}" = "grub-pc"`, so does not apply
to the default situation of using syslinux at least...
Furthermore the code concerns generation of a 'grub_eltorito' file,
which is then later used in a xorriso only when grub-pc is selected for
use.
So it seems to me that this only affects grub-pc...
It's been quite some time since I last researched the details of ISOs
and bootloaders and such. So I cannot say with complete confidence that
you're mistaken in being concerned about this breaking secure boot.
Especially since testing is tricky since I don't think my VM emulates
it, so would be a pain to double check, considering how busy I am.
If you're still concerned, would you happen to please have a little
spare time to double check?
Thanks,
Lyndon.
On Thu, 2020-04-16 at 01:03 +0200, adrian15sgd wrote:
> I suspect this would break Secure Boot support but it's only a guess.
>
> El 8/4/20 a las 2:23, jnq...@gmail.com escribió:
> > update: I've just tried adding --prefix=/boot/grub to the grub-
> > mkimage
> > command in binary_iso (which should really be done in binary_grub-
> > pc)
> > that generates the core_img file that becomes part of
> > grub_eltorito,
> > and success!
> >
> > So now that I know how fundamentally to fix the problems, I'll
> > follow
> > up soon with patches.
> >
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
El 8/4/20 a las 17:42, jnq...@gmail.com escribió: Oh, one more thing I mean to say, @adrian, can you please confirm that this installation of a live-build (?) image in this HP system does not in fact include the /.disk/ files. Moving to a /.disk/info/ based detection is of course not going to improve things in that situation if the file exists in it anyway. I'm sure you probably thought of this, but I did not notice any explicit mention in your discussion in #924053... I have saved the original laptop partitions into my mediapc but I'm not sure I'm going to check on those on the mid-term. I guess there was not /.disk/ folder there but I cannot confirm it. On Wed, 2020-04-08 at 16:05 +0100, jnq...@gmail.com wrote: Oh, quick addition of something I forgot to put in the below message: So in the discussion of #924053 it was suggested that the /.disc/info based solution would only work for ISO/ISO-hybrid images because this file was created by xorriso. I added a comment just now pointing out that in fact this file is created by the binary_disc script, which generates it for iso, iso-hybrid and hdd image types. It does not create any such info for netboot and tar images types, though. I do not expect the tar image will be booted will it? and thus there's no concern there? I really do not know all that much about netboot, so I do not know whether or not there is a problem there. On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote: Hi, Okay, so I've just take a cursory look at your liveid stuff which also led me to #924053 where you've already brought up the EFI failure side of things. I'll limit my response here (this bug report discussion) to matters relating to simply fixing the broken ability to get bootable images; discussion of a unique-disc identification solution can take place separately. To fix the issue of broken EFI booting when syslinux is not used (and thus binary_syslinux was not put in place /live/vmlinuz), I was intending to solve by moving creation of short filename kernel files out of binary_syslinux into somewhere common. The first problem with this though is that alone of course it is not enough because it does not cover the `/live/vmlinuz1` multi-flavour case, so a change to binaru_grub-efi would also be needed in order to dynamically change the searched for file to /live/vmlinuz1 where appropriate. However, I now understand from reading #924053 that although this would fix things in all/most cases, it's at risk of breaking for odd situations like your HP laptop case. Using /.disc/info as the searched for file as proposed in #924053 is much a better solution. My current intention is to take the patch of yours provided in #924053 that makes this change, though with a tweaked commit message (I think the problem is EFI specific not Secure Boot specific), and submit it in an MR, along with the fix for grub-pc, and some additional loosely related work, in one or more MRs. While the concept of correctly identifying discs (aka liveid type stuff) is interesting and of some potential value, priority should be given to simply fixing the ability to create working images first and foremost. I will have the patches mark this bug and #924053 as closed, and leave you to create a new wishlist bug to propose or re-start discussion of the unique-disc identification stuff as you wish. Regards, Lyndon On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote: I think what you need is liveid. https://github.com/rescatux/liveid Here you can find the technical details and commits: https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md That way you won't longer depend on arbitrary files such as vmlinuz. Feedback is welcome. P.S.: I was going to do proper merge requests in about 5 or 6 months later but here you are. adrian15 El 8/4/20 a las 1:02, jnq...@gmail.com escribió: update: 1) from my notes, in fact I'd gone back as far as v5.0 confirming the presence of the grub-pc failure. 2) I've noticed the presence of the fixed path '/live/vmlinuz' in binary_grub-efi, and with a hack to have this replaced with the long name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the problem, so that explains how the EFI stuff ends up checking that fixed /live/vmlinuz' path and presents an alternate opportunity for a fix. It seems the author of the EFI live-build functionality only tested it with syslinux.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
El 8/4/20 a las 17:05, jnq...@gmail.com escribió: Oh, quick addition of something I forgot to put in the below message: So in the discussion of #924053 it was suggested that the /.disc/info based solution would only work for ISO/ISO-hybrid images because this file was created by xorriso. I added a comment just now pointing out that in fact this file is created by the binary_disc script, which generates it for iso, iso-hybrid and hdd image types. It does not create any such info for netboot and tar images types, though. I do not expect the tar image will be booted will it? and thus there's no concern there? I really do not know all that much about netboot, so I do not know whether or not there is a problem there. I'm neither an expert on netboot so I cannot advise. On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote: Hi, Okay, so I've just take a cursory look at your liveid stuff which also led me to #924053 where you've already brought up the EFI failure side of things. I'll limit my response here (this bug report discussion) to matters relating to simply fixing the broken ability to get bootable images; discussion of a unique-disc identification solution can take place separately. To fix the issue of broken EFI booting when syslinux is not used (and thus binary_syslinux was not put in place /live/vmlinuz), I was intending to solve by moving creation of short filename kernel files out of binary_syslinux into somewhere common. The first problem with this though is that alone of course it is not enough because it does not cover the `/live/vmlinuz1` multi-flavour case, so a change to binaru_grub-efi would also be needed in order to dynamically change the searched for file to /live/vmlinuz1 where appropriate. However, I now understand from reading #924053 that although this would fix things in all/most cases, it's at risk of breaking for odd situations like your HP laptop case. Using /.disc/info as the searched for file as proposed in #924053 is much a better solution. My current intention is to take the patch of yours provided in #924053 that makes this change, though with a tweaked commit message (I think the problem is EFI specific not Secure Boot specific), and submit it in an MR, along with the fix for grub-pc, and some additional loosely related work, in one or more MRs. While the concept of correctly identifying discs (aka liveid type stuff) is interesting and of some potential value, priority should be given to simply fixing the ability to create working images first and foremost. I will have the patches mark this bug and #924053 as closed, and leave you to create a new wishlist bug to propose or re-start discussion of the unique-disc identification stuff as you wish. Regards, Lyndon On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote: I think what you need is liveid. https://github.com/rescatux/liveid Here you can find the technical details and commits: https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md That way you won't longer depend on arbitrary files such as vmlinuz. Feedback is welcome. P.S.: I was going to do proper merge requests in about 5 or 6 months later but here you are. adrian15 El 8/4/20 a las 1:02, jnq...@gmail.com escribió: update: 1) from my notes, in fact I'd gone back as far as v5.0 confirming the presence of the grub-pc failure. 2) I've noticed the presence of the fixed path '/live/vmlinuz' in binary_grub-efi, and with a hack to have this replaced with the long name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the problem, so that explains how the EFI stuff ends up checking that fixed /live/vmlinuz' path and presents an alternate opportunity for a fix. It seems the author of the EFI live-build functionality only tested it with syslinux.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
El 8/4/20 a las 16:56, jnq...@gmail.com escribió: Hi, Okay, so I've just take a cursory look at your liveid stuff which also led me to #924053 where you've already brought up the EFI failure side of things. I'll limit my response here (this bug report discussion) to matters relating to simply fixing the broken ability to get bootable images; discussion of a unique-disc identification solution can take place separately. I see. To fix the issue of broken EFI booting when syslinux is not used (and thus binary_syslinux was not put in place /live/vmlinuz), I was intending to solve by moving creation of short filename kernel files out of binary_syslinux into somewhere common. The first problem with this though is that alone of course it is not enough because it does not cover the `/live/vmlinuz1` multi-flavour case, so a change to binaru_grub-efi would also be needed in order to dynamically change the searched for file to /live/vmlinuz1 where appropriate. You should also know that current isolinux/syslinux supports booting from long filenames. So we could ditch using short 8.3 names for the kernels. This problem about having to update binary_grub-efi for searching for long names would arise anyways. However, I now understand from reading #924053 that although this would fix things in all/most cases, it's at risk of breaking for odd situations like your HP laptop case. Using /.disc/info as the searched for file as proposed in #924053 is much a better solution. It collides with Ubuntu live usbs which also have /.disc/info but it would be a quick and easy fix for the current situation where HP laptop are involved. My current intention is to take the patch of yours provided in #924053 that makes this change, though with a tweaked commit message (I think the problem is EFI specific not Secure Boot specific), and submit it in an MR, along with the fix for grub-pc, and some additional loosely related work, in one or more MRs. The Secure Boot code works from an EFI sort-of-ramdisk so it needs to find its own root somehow. That's why it was Secure Boot specific. While the concept of correctly identifying discs (aka liveid type stuff) is interesting and of some potential value, priority should be given to simply fixing the ability to create working images first and foremost. I will have the patches mark this bug and #924053 as closed, and leave you to create a new wishlist bug to propose or re-start discussion of the unique-disc identification stuff as you wish. I don't think your solution is optimal (because you are postponing the actual fact that every live cd cannot detect itself). Liveid let's you find the correct live cd. I agree that if you finally add your code it could cose #924053 so that you force me to submit a liveid merge request. adrian15 Regards, Lyndon On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote: I think what you need is liveid. https://github.com/rescatux/liveid Here you can find the technical details and commits: https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md That way you won't longer depend on arbitrary files such as vmlinuz. Feedback is welcome. P.S.: I was going to do proper merge requests in about 5 or 6 months later but here you are. adrian15 El 8/4/20 a las 1:02, jnq...@gmail.com escribió: update: 1) from my notes, in fact I'd gone back as far as v5.0 confirming the presence of the grub-pc failure. 2) I've noticed the presence of the fixed path '/live/vmlinuz' in binary_grub-efi, and with a hack to have this replaced with the long name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the problem, so that explains how the EFI stuff ends up checking that fixed /live/vmlinuz' path and presents an alternate opportunity for a fix. It seems the author of the EFI live-build functionality only tested it with syslinux.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
I suspect this would break Secure Boot support but it's only a guess. El 8/4/20 a las 2:23, jnq...@gmail.com escribió: update: I've just tried adding --prefix=/boot/grub to the grub-mkimage command in binary_iso (which should really be done in binary_grub-pc) that generates the core_img file that becomes part of grub_eltorito, and success! So now that I know how fundamentally to fix the problems, I'll follow up soon with patches.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
partially answering my own question here, the binary_grub-efi script rejects use for netboot images (as well as hdd coincidentally), so no need to be concerned with compatibility there. On Wed, 2020-04-08 at 16:05 +0100, jnq...@gmail.com wrote: > Oh, quick addition of something I forgot to put in the below message: > > So in the discussion of #924053 it was suggested that the /.disc/info > based solution would only work for ISO/ISO-hybrid images because this > file was created by xorriso. I added a comment just now pointing out > that in fact this file is created by the binary_disc script, which > generates it for iso, iso-hybrid and hdd image types. > > It does not create any such info for netboot and tar images types, > though. I do not expect the tar image will be booted will it? and > thus > there's no concern there? I really do not know all that much about > netboot, so I do not know whether or not there is a problem there.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
Oh, one more thing I mean to say, @adrian, can you please confirm that this installation of a live-build (?) image in this HP system does not in fact include the /.disk/ files. Moving to a /.disk/info/ based detection is of course not going to improve things in that situation if the file exists in it anyway. I'm sure you probably thought of this, but I did not notice any explicit mention in your discussion in #924053... On Wed, 2020-04-08 at 16:05 +0100, jnq...@gmail.com wrote: > Oh, quick addition of something I forgot to put in the below message: > > So in the discussion of #924053 it was suggested that the /.disc/info > based solution would only work for ISO/ISO-hybrid images because this > file was created by xorriso. I added a comment just now pointing out > that in fact this file is created by the binary_disc script, which > generates it for iso, iso-hybrid and hdd image types. > > It does not create any such info for netboot and tar images types, > though. I do not expect the tar image will be booted will it? and > thus > there's no concern there? I really do not know all that much about > netboot, so I do not know whether or not there is a problem there. > > On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote: > > Hi, > > > > Okay, so I've just take a cursory look at your liveid stuff which > > also > > led me to #924053 where you've already brought up the EFI failure > > side > > of things. > > > > I'll limit my response here (this bug report discussion) to matters > > relating to simply fixing the broken ability to get bootable > > images; > > discussion of a unique-disc identification solution can take place > > separately. > > > > To fix the issue of broken EFI booting when syslinux is not used > > (and > > thus binary_syslinux was not put in place /live/vmlinuz), I was > > intending to solve by moving creation of short filename kernel > > files > > out of binary_syslinux into somewhere common. > > > > The first problem with this though is that alone of course it is > > not > > enough because it does not cover the `/live/vmlinuz1` multi-flavour > > case, so a change to binaru_grub-efi would also be needed in order > > to > > dynamically change the searched for file to /live/vmlinuz1 where > > appropriate. > > > > However, I now understand from reading #924053 that although this > > would > > fix things in all/most cases, it's at risk of breaking for odd > > situations like your HP laptop case. Using /.disc/info as the > > searched > > for file as proposed in #924053 is much a better solution. > > > > My current intention is to take the patch of yours provided in > > #924053 > > that makes this change, though with a tweaked commit message (I > > think > > the problem is EFI specific not Secure Boot specific), and submit > > it > > in > > an MR, along with the fix for grub-pc, and some additional loosely > > related work, in one or more MRs. > > > > While the concept of correctly identifying discs (aka liveid type > > stuff) is interesting and of some potential value, priority should > > be > > given to simply fixing the ability to create working images first > > and > > foremost. > > > > I will have the patches mark this bug and #924053 as closed, and > > leave > > you to create a new wishlist bug to propose or re-start discussion > > of > > the unique-disc identification stuff as you wish. > > > > Regards, > > Lyndon > > > > On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote: > > > I think what you need is liveid. > > > > > > https://github.com/rescatux/liveid > > > > > > Here you can find the technical details and commits: > > > > > > https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md > > > > > > That way you won't longer depend on arbitrary files such as > > > vmlinuz. > > > > > > > > > Feedback is welcome. > > > > > > > > > P.S.: I was going to do proper merge requests in about 5 or 6 > > > months > > > later but here you are. > > > > > > adrian15 > > > > > > > > > El 8/4/20 a las 1:02, jnq...@gmail.com escribió: > > > > update: > > > > > > > > 1) from my notes, in fact I'd gone back as far as v5.0 > > > > confirming > > > > the > > > > presence of the grub-pc failure. > > > > > > > > 2) I've noticed the presence of the fixed path '/live/vmlinuz' > > > > in > > > > binary_grub-efi, and with a hack to have this replaced with the > > > > long > > > > name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI > > > > side > > > > of > > > > the > > > > problem, so that explains how the EFI stuff ends up checking > > > > that > > > > fixed > > > > /live/vmlinuz' path and presents an alternate opportunity for a > > > > fix. It > > > > seems the author of the EFI live-build functionality only > > > > tested > > > > it > > > > with syslinux. > > > >
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
Oh, quick addition of something I forgot to put in the below message: So in the discussion of #924053 it was suggested that the /.disc/info based solution would only work for ISO/ISO-hybrid images because this file was created by xorriso. I added a comment just now pointing out that in fact this file is created by the binary_disc script, which generates it for iso, iso-hybrid and hdd image types. It does not create any such info for netboot and tar images types, though. I do not expect the tar image will be booted will it? and thus there's no concern there? I really do not know all that much about netboot, so I do not know whether or not there is a problem there. On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote: > Hi, > > Okay, so I've just take a cursory look at your liveid stuff which > also > led me to #924053 where you've already brought up the EFI failure > side > of things. > > I'll limit my response here (this bug report discussion) to matters > relating to simply fixing the broken ability to get bootable images; > discussion of a unique-disc identification solution can take place > separately. > > To fix the issue of broken EFI booting when syslinux is not used (and > thus binary_syslinux was not put in place /live/vmlinuz), I was > intending to solve by moving creation of short filename kernel files > out of binary_syslinux into somewhere common. > > The first problem with this though is that alone of course it is not > enough because it does not cover the `/live/vmlinuz1` multi-flavour > case, so a change to binaru_grub-efi would also be needed in order to > dynamically change the searched for file to /live/vmlinuz1 where > appropriate. > > However, I now understand from reading #924053 that although this > would > fix things in all/most cases, it's at risk of breaking for odd > situations like your HP laptop case. Using /.disc/info as the > searched > for file as proposed in #924053 is much a better solution. > > My current intention is to take the patch of yours provided in > #924053 > that makes this change, though with a tweaked commit message (I think > the problem is EFI specific not Secure Boot specific), and submit it > in > an MR, along with the fix for grub-pc, and some additional loosely > related work, in one or more MRs. > > While the concept of correctly identifying discs (aka liveid type > stuff) is interesting and of some potential value, priority should be > given to simply fixing the ability to create working images first and > foremost. > > I will have the patches mark this bug and #924053 as closed, and > leave > you to create a new wishlist bug to propose or re-start discussion of > the unique-disc identification stuff as you wish. > > Regards, > Lyndon > > On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote: > > I think what you need is liveid. > > > > https://github.com/rescatux/liveid > > > > Here you can find the technical details and commits: > > > > https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md > > > > That way you won't longer depend on arbitrary files such as > > vmlinuz. > > > > > > Feedback is welcome. > > > > > > P.S.: I was going to do proper merge requests in about 5 or 6 > > months > > later but here you are. > > > > adrian15 > > > > > > El 8/4/20 a las 1:02, jnq...@gmail.com escribió: > > > update: > > > > > > 1) from my notes, in fact I'd gone back as far as v5.0 confirming > > > the > > > presence of the grub-pc failure. > > > > > > 2) I've noticed the presence of the fixed path '/live/vmlinuz' in > > > binary_grub-efi, and with a hack to have this replaced with the > > > long > > > name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side > > > of > > > the > > > problem, so that explains how the EFI stuff ends up checking that > > > fixed > > > /live/vmlinuz' path and presents an alternate opportunity for a > > > fix. It > > > seems the author of the EFI live-build functionality only tested > > > it > > > with syslinux. > > >
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
Hi, Okay, so I've just take a cursory look at your liveid stuff which also led me to #924053 where you've already brought up the EFI failure side of things. I'll limit my response here (this bug report discussion) to matters relating to simply fixing the broken ability to get bootable images; discussion of a unique-disc identification solution can take place separately. To fix the issue of broken EFI booting when syslinux is not used (and thus binary_syslinux was not put in place /live/vmlinuz), I was intending to solve by moving creation of short filename kernel files out of binary_syslinux into somewhere common. The first problem with this though is that alone of course it is not enough because it does not cover the `/live/vmlinuz1` multi-flavour case, so a change to binaru_grub-efi would also be needed in order to dynamically change the searched for file to /live/vmlinuz1 where appropriate. However, I now understand from reading #924053 that although this would fix things in all/most cases, it's at risk of breaking for odd situations like your HP laptop case. Using /.disc/info as the searched for file as proposed in #924053 is much a better solution. My current intention is to take the patch of yours provided in #924053 that makes this change, though with a tweaked commit message (I think the problem is EFI specific not Secure Boot specific), and submit it in an MR, along with the fix for grub-pc, and some additional loosely related work, in one or more MRs. While the concept of correctly identifying discs (aka liveid type stuff) is interesting and of some potential value, priority should be given to simply fixing the ability to create working images first and foremost. I will have the patches mark this bug and #924053 as closed, and leave you to create a new wishlist bug to propose or re-start discussion of the unique-disc identification stuff as you wish. Regards, Lyndon On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote: > I think what you need is liveid. > > https://github.com/rescatux/liveid > > Here you can find the technical details and commits: > > https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md > > That way you won't longer depend on arbitrary files such as vmlinuz. > > > Feedback is welcome. > > > P.S.: I was going to do proper merge requests in about 5 or 6 months > later but here you are. > > adrian15 > > > El 8/4/20 a las 1:02, jnq...@gmail.com escribió: > > update: > > > > 1) from my notes, in fact I'd gone back as far as v5.0 confirming > > the > > presence of the grub-pc failure. > > > > 2) I've noticed the presence of the fixed path '/live/vmlinuz' in > > binary_grub-efi, and with a hack to have this replaced with the > > long > > name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of > > the > > problem, so that explains how the EFI stuff ends up checking that > > fixed > > /live/vmlinuz' path and presents an alternate opportunity for a > > fix. It > > seems the author of the EFI live-build functionality only tested it > > with syslinux. > >
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
I think what you need is liveid. https://github.com/rescatux/liveid Here you can find the technical details and commits: https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md That way you won't longer depend on arbitrary files such as vmlinuz. Feedback is welcome. P.S.: I was going to do proper merge requests in about 5 or 6 months later but here you are. adrian15 El 8/4/20 a las 1:02, jnq...@gmail.com escribió: update: 1) from my notes, in fact I'd gone back as far as v5.0 confirming the presence of the grub-pc failure. 2) I've noticed the presence of the fixed path '/live/vmlinuz' in binary_grub-efi, and with a hack to have this replaced with the long name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the problem, so that explains how the EFI stuff ends up checking that fixed /live/vmlinuz' path and presents an alternate opportunity for a fix. It seems the author of the EFI live-build functionality only tested it with syslinux.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
update: I've just tried adding --prefix=/boot/grub to the grub-mkimage command in binary_iso (which should really be done in binary_grub-pc) that generates the core_img file that becomes part of grub_eltorito, and success! So now that I know how fundamentally to fix the problems, I'll follow up soon with patches.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
update: 1) from my notes, in fact I'd gone back as far as v5.0 confirming the presence of the grub-pc failure. 2) I've noticed the presence of the fixed path '/live/vmlinuz' in binary_grub-efi, and with a hack to have this replaced with the long name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the problem, so that explains how the EFI stuff ends up checking that fixed /live/vmlinuz' path and presents an alternate opportunity for a fix. It seems the author of the EFI live-build functionality only tested it with syslinux.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
Package: live-build Version: 1:20191221 As mentioned previously in work on an MR, testing images built with grub (grub-pc and grub-efi) instead of syslinux, I've found that they are non-bootable, at least with ISO images and in the VM I used. - If you use `--bootloaders=grub-pc` on an otherwise default config, booting the image in a VM (BIOS based) results in a blinking underline in the top left of a black screen. - If you use `--bootloaders=grub-pc,grub-efi` then you get the same for grub-pc using the VM in BIOS mode of course, and an error regarding a missing '/live/vmlinuz' in EFI mode (again on an otherwise black screen). - I have not bothered trying `--bootloaders=grub-efi` only, but expect no difference. - I have not bothered trying grub-legacy. Investigating, there are definitely two parts to this problem. I have identified one issue, for which I will craft a patch in due course; the other I do not yet know the cause of. I'm submitting this to ensure that the problem is documented, until such time as it is completely solved. The one issue that I have identified (as I'd previously guessed at) is that the syslinux script takes responsibility for creating copies of the kernel files with short filenames. When syslinux is not used, the kernel files with short filenames (/live/vmlinuz and /live/initrd.img) do not exist. I have confirmed with a modified image that when the short filename copies of the kernel files are present, the issue in EFI mode goes away. So one part of the solution is to move the creation of the short filename files out of the syslinux script to something used in all (or more) cases. (Since I cannot see any reference to the filename/path in creation of the ISO, I presume /live/vmlinuz and /live/initrd.img paths are hard coded into the grub EFI binaries, so this is therefore the only solution, not just probably the ideal one anyway). This does not however solve the problem with BIOS mode (i.e. grub-pc). I do not know the cause of the failure here. Hence I felt it appropriate to get a bug report created. Note that I have previous made some effort to try to try to locate the point at which grub-pc last worked, if it ever did, but only got as far as confirming that this is not a problem introduced by any of my recent work. It predates that, if grub-pc support ever actually worked at all (I would not be surprised if it has always been broken). Again, all my testing has been with ISO images. I've not tried any others.
