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