On Mon, Sep 22, 2025 at 4:18 PM Lennart Poettering <[email protected]> wrote:
> On Mo, 22.09.25 15:01, Itxaka Serrano Garcia ( > [email protected]) wrote: > > > Hello folks, > > > > we are investigating a bit around multi-profile UKIs and cmdlines and > while > > this works as expected, we noticed that on Type 1 entries, the Title ID > is > > not read from the .profile of the entry. > > > > I guess this is kind of expected as that saves time poking the file and > > extracting data if any, but IIRC, systemd-boot already pokes the file to > at > > least know if it's in there, as if you add an entry pointing to a > > non-existent efi file, systemd-boot will be intelligent enough to not > show > > it in the menu. > > > > I also notice that in case of Type 2 entries, the autodiscovery also > > doesnt use the Title in the .profile section but still defaults to the > > PRETTY_NAME from the os-release and in case more than one entry matches > it > > also appends the cmdline. > > > > This is a bit weird IMHO as then whats the point of the ID and TITLE in > the > > .cmdline part? I would expect at least Type 2 to get the Title from there > > if any, otherwise you cant set any name and believe me, the entries are > > terrible, as the cmdline takes the whole screen and there is no > visibility > > if something just changes a value at the end of the cmdline. > > > > 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 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. 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. Cheers, Itxaka
