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, jnq...@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, jnq...@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, jnq...@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. > > > >
