Add profile reference in the Bootloader spec #165
Conversation
Itxaka
force-pushed
the
profile_boot_spec
branch
from
00a07eb to
659291a
Compare
Itxaka
force-pushed
the
profile_boot_spec
branch
from
659291a to
54cac70
Compare
specs/boot_loader_specification.md
Outdated
| See the section `multi-profile UKIs` in [the UKI Specification](unified_kernel_image.md) | ||
| for more information. | ||
| This should only be used when `efi` is set to a multi-profile UKI. Behaviour is undefined | ||
| for any other cases. |
There was a problem hiding this comment.
"linux" not "efi".
"linux" is for stuff that is a linux kernel, and that includes UKIs. "efi" is for everything else, that isn't a linux kernel, for example the efi shell or so.
There was a problem hiding this comment.
Umm, we been using EFI in our type 1 entries with no issues since the start, and it has worked with no issues. Are we misusing the key or it's also valid for any EFI files? It's very confusing then because Linux seems to point to just a kernel, to be used with the initrd key while EFI seems especifically for EFI files no matter the type.
Are we wrong on using the EFI key for ukis? It's not supposed to work or we are just lucky that it does?
There was a problem hiding this comment.
in fact looking at the spec:
linux specifies the Linux kernel image to execute. The value is a path relative to the root of the file system containing the boot entry snippet itself.
It is recommended that every distribution creates a subdirectory specific to the entry-token or machine-id, and underneath that, subdirectories specific to the kernel version, and places places the kernel and initrd images there (see below).
It mentions nothing of EFI files, UKIs or anything like that.
While efi refers to any arbitrary efi file, which UKI/USI fall in:
efi refers to an arbitrary EFI program. If this key is set, and the system is not an EFI system, this entry should be hidden.
If indeed UKI/USI need to go under linux keys maybe we should clarify that
There was a problem hiding this comment.
so, both work, but if you let the boot loader know you are invoking a kernel here it can do things differently. for example, it can pass some more stuff to it (i.e. creds, confext, sysext or so), or it can do some reasonable fall back on non-efi, or it can find some metadata in the PE image it would otherwise not search and so on.
But yeah, it certainly would make sense to update the "linux" description to say, ukis are covered too.
There was a problem hiding this comment.
So, there's also #135, which you this way reminded me to dust off and actually merge just now.
It might make sense to list "uki", "uki-url" hence. But not "efi", because as mentioned that's not something where Linux comes into play. And not "linux" either, because profiles are an UKI concept, and I don't see how it could apply to plain "linux".
There was a problem hiding this comment.
so, both work, but if you let the boot loader know you are invoking a kernel here it can do things differently. for example, it can pass some more stuff to it (i.e. creds, confext, sysext or so), or it can do some reasonable fall back on non-efi, or it can find some metadata in the PE image it would otherwise not search and so on.
But yeah, it certainly would make sense to update the "linux" description to say, ukis are covered too.
Sounds good I will change and maybe add a comment under the Linux key to note that if you are using UKI you should also use that entry for it.
Any idea what metadata or extra file is ignoring? We haven't found any issues in our nodes running with that, so it would be nice to be aware of future problems that could arise from that
There was a problem hiding this comment.
done and pointed it to refer to uki/uki-url keys instead
|
if you fix that, looks good to merge. |
Itxaka
force-pushed
the
profile_boot_spec
branch
from
a0fe712 to
2ba87cb
Compare
|
you seem to have pushed the wrong version? |
Clarifies the use of the profile key to choose the profile associated with Type 1 configs. Complements PR at systemd/systemd#39088 Signed-off-by: Itxaka <[email protected]>
Itxaka
force-pushed
the
profile_boot_spec
branch
from
2ba87cb to
f7d8168
Compare
done, I had it stashed to rebase to main and forgot to unstash it :D |
| * `profile` refers to the profile number to use in multi-profile EFI programs. | ||
| See the section `multi-profile UKIs` in [the UKI Specification](unified_kernel_image.md) | ||
| for more information. | ||
| This should only be used when `uki` or `uki-url` is set to a multi-profile UKI. Behaviour is undefined for any other cases. |
There was a problem hiding this comment.
@poettering Is "undefined" the best way to go here? "implementation-defined" might do the same and be more easier understood by readers, but I maybe we can just define a reasonable semantic here so that people always know what will happen.
There was a problem hiding this comment.
I think "undefined" is ok'ish. I think it makes sense to allow implementations to either ignore the field in this case or generate error or warning. "undefined" seems ok.
|
Any updates on this? The feature is already merged on systemd, I would not like to leave this hanging in case we forget about it |
|
wouldn't mind changing "undefined" → "implementation-defined", as suggested by @behrmann, consider pushing that as a follow-up. |
4 participants
Clarifies the use of the profile key to choose the profile associated with Type 1 configs.
Complements PR at systemd/systemd#39088