[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

El 8/4/20 a las 17:42, jnqnfe@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, 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: