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, jnqnfe@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 solution for the last crafted and
accepted is why I feel that it needed to be put to one side just for a
moment while the other four are quickly addressed, before then coming
back to it.
> I agree that if you finally add your code it could cose #924053 so
> that
> you force me to submit a liveid merge request.
One of the submitted patches which has been merged now carried a close
marker for the bug report, which is thus now set to pending and will be
automatically closed upon the next release being issued.
Please go ahead and file a new bug report about the image
identification issue (I could do it myself but though you might like to
be the author since you discovered the issue). A couple of sentences
would suffice if you wanted to keep it short. It just needs to at least
describe the identification clash issue where multiple images are
present in a system, so that this is recorded as a known issue. By all
means also reference your liveid solution as something your working on
as a possible solution you'll propose later. :)
Reply to: