Re: liveid
El 8/4/20 a las 19:12, jnqnfe@gmail.com escribió:
(@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?
My spec handles two boot problems:
The first one is Secure Boot embedded grub.cfg finding its own root. As
you say if Secure Boot EFI is not triggered you probably don't have this
problem.
However, later in the boot process the live cd initrd (which it's called
live-boot) is going to search for something like
/live/filesystem.squashfs . If two devices (usb, partitions, etc) have
both of them that /live/filesystem.squashfs you still have a problem.
Why? Because live-boot initrd will not match its associated
/live/filesystem.squashfs.
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,
That's a nice idea I guess. Something to be added to what it's already
taken into account. Why? Because you can build live cds without a config
directory being present.
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).
Yeah, I mean, what I have implemented might not be perfect but it's way
better than checking /live/vmlinuz or /.disk/info .
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...
Yeah, you could hash .img, .fat32 or whatever other livesquashfs
extensions are used. Or squash every file in the directory (there's an
option for generating a directory instead of an image if I'm not
mistaken). But I don't like this idea too much. Having to hash such big
files seems overkill to me.
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).
LB_ISO_VOLUME has only 13 characters size if I'm not mistaken. Too small
for uniqueness.
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.
Yeah, I override it myself when building Rescatux.
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.
Yeah, that's why I guess I use some of the LB variables as a base
because I think they did not change between builds.
And, yes, I guess that reproducible-check-tool should override the
--iso-volume switch.
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.
No program ever runs from the hard disk.
Not even your GNU/Linux installed distribution.
The reason why your GNU/Linux distro boots is because Grub gives the
kernel (actually the initrd) a filesystem uuid where to find its root
filesystem. So the kernel is not smart enough to figure out its own root
filesystem.
Same thing happens with this RAM-disk grub EFI image. It's loaded in RAM
and you are alone. It reads its own ram-filesytem where it finds its
stub grub.cfg .
Yeah, you could tweak that specific stub grub.cfg to have the same
contents as the live cd grub.cfg but, then, if you add too many fancy
stuff (like background images) it might mean that the UEFI firmware is
not able to boot your EFI image into RAM (because of being too big).
And, additionally, you would have the same repeated grub.cfg twice which
would make things complex when modifying it.
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`?
Yeah, that's a nice idea. That could work. I haven't thought of that.
However that modification would imply having to modify live-boot in
order for it to be able to read "set uuid=UUID".
And that does not make sense. I mean, yeah, you can parse it with some
tools but... this "set uuid=UUID" would be in the EFI ramdisk and not
accessible to live-boot.
I prefer my approach of /LIVEID/ABCD/EDCD/EFFE/1234 so that it's easier
to handle with more simple tools.
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?
This is elegant but it's very complex. So you would have to loop on all
the devices MANUALLY which it's not easy (Believe, I have implemented it
in Super Grub2 Disk) and then try to loop-mount the efi-ramdisk and
compare its set variable with your original one. Loop-umount it and try
the next disk.
If I just use the grub search command with a path+file I'm done.
Everything is done in the background by grub and it's only one line. The
first match for the first file found is saved onto a variable and we are
done.
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.
As I said above that's not true. The EFI ramdisk is loaded into the RAM
by the UEFI firmware and grub reads what's inside. Using what's inside
that filesystem grub needs to decide what it's is own root.
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.
I'm not sure basing the UUID on only LB variable instead of various LB
variables is a good idea.
Anyways I'm most interested in UUID being used than how it's generated
in the first place.
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).
That's not possible. You cannot force the user to have a timestamp in
its volume label. And the volume label is rather small for it (13
characters).
I mean... I might agree on generating the UUID based on a timestamp but
I won't agree on storing either the timestamp or the UUID on the ISO
volume label.
Regards,
Lyndon
Reply to: