Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
El 8/4/20 a las 16:56, jnqnfe@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, jnqnfe@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.
Reply to: