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. > > >