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, jnqnfe@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, 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: