My email client report my having replied to this previously, but I
don't really doing so properly, so I'll continue at the risk of giving
the same reply twice...
On Thu, 2020-04-16 at 02:26 +0200, adrian15sgd wrote:
> (Bringing back the discussion to debian-live ML.)
>
> El 8/4/20 a las 17:32, jnq...@gmail.com escribió:
> > Hi,
> >
> > Question #1:
> > ------------
> >
> > Your loopback implementation in live-build commit
> > 39038173a890ed4e19e8ce181383e95ce6d3e1ce involved injecting the
> > `findiso=${iso_path}` parameter to all live entries by modifying
> > the
> > set of appended parameters in binary_loopback_cfg, meaning that it
> > is
> > served to the kernel even in non-loopback situations.
> That's true.
> > The supergrubdisk loopback wiki page ([1]) has a link ([2]) to the
> > commit in which Grml implemented there solution, which only serves
> > the
> > kernel the parameter when necessary by doing this:
> >
> > ```
> > if [ ${iso_path} ] ; then
> > set loopback="findiso=${iso_path}"
> > fi
> > ```
> >
> > Followed by using $loopback in the menu entries.
> >
> > Of course that is done in a fixed grub.cfg file.
> That's true.
> > I am curious why your solution did not do something similar, i.e.
> > add
> > the above three lines to grub.cfg and have `"${loopback}"`
> > appended.
> >
> > I meant, was there a specific reason for not doing it this way?
>
> Liveid also needs live-boot package to be patched so that initrd for
> the
> live cds make sure to look for the correct /live/filesystem.squashfs
> (or
> whatever) file.
>
> So live-boot needs to read the liveid kernel parametre. That's why
> the
> kernel has to have it in the first place.
Yes, I get that it needs to be communicated via kernel param. I'm not
certain if you misunderstood me, I'm just suggesting placing the
decision block in grub.cfg _and_ passing the variable name as a kernel
param in the grub.cfg, just like in the original solution that was
referred to from which I believe you designed yours...
With the main benefit of this being that we can correctly only pass
along the value as a kernel param when it is actually appropriate to do
so, as in the original that inspired you.
> > I can foresee that your solution would allow user customised
> > configs
> > without the above three lines to benefit from working looback
> > support,
> > whilst this alternative would not unless they modified their custom
> > grub.cfg to add those lines...
> >
> > With MR #135 moving generation of grub config files out to template
> > files, like syslinux, perhaps it makes more sense to move to the
> > same
> > solution as Grml?
> >
> > Would you concur with that being a good idea? (before I bother to
> > craft
> > an MR)
>
> Explained above. live-boot.
>
> That means that if you want to use liveid in live-build you need
> first
> to be accepted into live-boot .
Erm... these questions are just about the loopback stuff not liveid...
> > Question #2:
> > ------------
> >
> > Was it a deliberate choice to only have it added to live entries?
> > Is it
> > not also helpful for it to be used with install entries?
> I tend not to mess with the code I cannot test (mainly because of
> lack
> of knowledge) that's why I assume I did not add those entries there.
> I
> guess that, yes, it should be also added there and there won't be
> any
> problem but I'm not 100% sure. It would be needed to be tested. Maybe
> I
> tried it in the past and the liveid= entry was repeated twice. Not
> sure.
> Just guessing.
Ok. Thanks.
> > [1]: https://www.supergrubdisk.org/wiki/Loopback.cfg
> > [2]:
> > http://git.grml.org/?p=grml-live.git;a=blobdiff;f=templates/boot/grub/grub.cfg;h=31545bd0042dd1e62ed9f83ae81b85565881969b;hp=7e115d6044f0ff86e1944f3bf8121289ef67955b;hb=641c1ace68b52313653478ba4699ca46a1e84184;hpb=2fb103a7c7d8cc2aed11c42e1d29c273c7848049
