On Tue, Sep 23, 2025 at 1:07 PM Lennart Poettering <[email protected]> wrote:
> On Mo, 22.09.25 16:35, Itxaka Serrano Garcia ( > [email protected]) wrote: > > > > > Would be nice to know if this is a wanted feature on both types, or > type > > > 2 > > > > only or what. I think it would be nice to have on both so the same > files > > > > can be either dropped for autodiscovery or teh title dropped from the > > > type > > > > 1 configs so its gets autofilled from the existing values per > profile. > > > > > > The thinking is that if you have a type 1 entry pointing to a type 2 > > > uki, then you *want* to override/parameterize it somehow, and give it > > > a different title. > > > > > > If you just want to use the embedded data of the type 2, then why use > > > a type 1 at all? > > > > > > Lennart > > > > > > -- > > > Lennart Poettering, Berlin > > > > > > > In our case it is due to needing to differentiate the "state", like we > have > > an active/passive/recovery but the actual content of the efi files are > the > > same (at least initially) so we identify them by checking the > > LoaderEntrySelected efivar and compare that to our list. So a conf called > > active.conf matches our active, and another marked as active-debug.conf > > would match active but with debug. We need this as we run different > things > > depending on the entry you choose > > You can look into /run/systemd/stub/profile (after tmpfiles ran in the > initrd) or /.extra/profile (before it ran), and it should tell you > exactly which profile was booted. > Yup this seems to work, but does it work only with multiprofile efi files? AFAIK what its there its the .profile section, but on single profile efi files the .profile section is not needed, so its not backwards compatible with older efi files, even if you were to create a .profile for single profile efi files no? In any case, the LoaderEntrySelected is the most compatible thing for this and while I would love to move to a Type 2, which is immensely easier, dealing with text files is much much simpler, for example to reset the boot assesment counter, or change the order-id during runtime, which I think its very important as we are talking signed+measured efi files, which means we cant alter anything on them after their creation. Type 1 gives more flexibility in this aspect IMHO. > > > Unfortunately we havent found how to rework this in order to move to > Type 2 > > entries which would make our lifes easier. > > > > My point still stands though, on Type 2, the TITLE value from the > .profile > > seems unused, so I'm not sure if that's supposed to be like that or > > not. > > If you drop-in a type 1 entry that references a type 2 uki, then the > data from the type 1 overrides to the embedded data to the point this > is possible (i.e. security policies might disallow this, but if all is > off, then the type 1 data matters). > > > That also would break or move to a Type 2 as it would get the default > name > > which is not ideal and no other way of overriding the entry Title in a > Type > > 2 entry. > > Hmm? boot loaders are supposed to synthesize menu item titles from the > type 2 profile data. See how this is done in particleos, for example > here. > > > https://github.com/systemd/particleos/blob/main/mkosi.uki-profiles/90-factory-reset.conf > > The TITLE= field will be included in the menu entry title. > > Lennart > You are correct, somehow I was putting the whole cmdline into the TITLE so I though it was defaulting to os-release PRETTY_ID + cmdline, but its just defaulting to PRETTY_ID + TITLE. > > -- > Lennart Poettering, Berlin > Thanks for all the info, it clarifies a lot. BTW I sent a patch to add the profile key into Type 1 entries so they are on par with Type 2 or at least they get on par with the multiprofile feature: https://github.com/systemd/systemd/pull/39088 not sure if its something wanted or not. Cheers, Itxaka
