(@adrian, but including the debian-live mailing list for open
discussion)
Hi,
As I said in the other email just sent in reply to your comment on
Debian bug #956131, I wanted to keep discussion there focussed on
fixing the broken ability to create working images, and discussion of a
better disc identification solution could be continued separately...
So firstly, your spec is written with the problem being specific to
Secure Boot situations. Does it not apply generically to EFI?
>From a cursory look at liveid and bug #924053, some thoughts occur to
me...
As to generation of a UUID, you discuss the concept of which build
attributes should go into its generation, but it occurs to me that such
a focus does not take into account other differences in user
customisations - e.g. modifications made by hooks, includes, package
lists, package-includes, apt config files, etc, etc. There are many
such differences that live outside of what is captured in LB_*
variables, that really should be taken into account in generation of a
UUID to uniquely identify non-identical images. Perhaps a hash build
from config directory contents would largely address things, but 'auto'
would maybe also be needed, to cover any work done in there, but then
what about stuff done by higher level user automation scripts external
to live-build, e.g. Kali's creation script, could there be anything
done by them which needs capturing by UUID uniqueness (which would be
unfeasible).
Perhaps a more simple solution of basing it upon a hash of the squashfs
file would easily cover the uniqueness of each image? though we want a
universal solution, not just one for iso images...
You explored a solution of using an LB_ISO_VOLUME label based solution,
but dropped it due to concerns about remastering tools. Firstly I'm not
sure that from the live-build image creation side we need to really
care about remastering tools needing to know to adjust the volume label
to make the remastered image unique. There will always be a need for
them to adjust something to gain uniqueness, unless a mechanism of
searching within the same device can be achieved (see below).
Also, LB_ISO_VOLUME by default contains a timestamp (it defaults to
`Debian ${LB_DISTRIBUTION} \$(date +%Y%m%d-%H:%M)`), but this is
overrideable by the user. The value is determined at time of creation
of the config and is saved in the saved config. It thus gets re-used
for each image created from that same config. This is a problem, even
ignoring the user override aspect. Furthermore it is already a problem
outside of grub disk identification, since if a user tweaks their
config, say to just to change the set of packages to be included and
then rebuilds, then the label each time they subsequently build is the
same as before, with the timestamp really reflecting date/time of
config creation rather than date/time of build, unlike what a user
might expect, and does not get changed upon running `lb config` unless
the user explicitly overrides that option with --iso-volume. Of course
fixing this to not store the timestamp in the config presents
reproducibility issues. Use of a build timestamp on its own presents an
excellent source of uniqueness for image identification, if we can just
solve the reproducibility problem.
The documentation in binary_grub-efi which implements the EFI grub.cfg
that performs the search states that some platforms do this thing where
$root points to the EFI partition. So what happens in other cases? Why
do we need to do the search? If the EFI partition is on the same device
as the real grub.cfg and kernel, etc, then why can we not limit the
search to partitions of the same device? Is grub not smart enough to
allow us to do that? Would than not solve the problem in the most ideal
way? If grub cannot currently do this then can it be modified to do it
in future, which we can then rely upon? This seems like the most
obvious, direct and perfect solution.
You discuss not being able to read the first line of a file into a
variable, but perhaps there's something in the ability to do `source
<file>`, if say we wrote `set uuid=UUID` into the file rather than just
`UUID`? At least if this does not lend itself to finding the right
disc, it could lend itself to comparison of the UUID of the disc that
is found by searching for a '.disk/info' or '.disk/uuid' file that
contains this, with the same ID embedded in the EFI grub.cfg doing the
search, with it giving an error if the disc found does not match the ID
searched for, prompting the user to fix the situation rather than carry
on with loading the wrong disc?
My proposal:
1. If we can have the search limited to partitions on the same device,
and this works universally, then this is surely the perfect solution
and we should use it.
2. live-build should be taught to replace a `@TIMESTAMP@` type
placeholder in LB_ISO_VOLUME, which should be used instead of saving a
timestamp directly at time of config creation, such that the timestamp
will change for each build at build time. For reproducibility however a
--timestamp override option should be provided.
3. If #1 is not possible, use either the timestamp in the same way, or
the ISO volume label, with build-time timestamp (or override) always
used, for the identifier. (Timestamp alone is great, using the full ISO
volume label helps go a little further to what should be sufficient).
Regards,
Lyndon
