On Tue, Sep 23, 2025 at 6:32 PM Lennart Poettering <[email protected]> wrote:
> On Di, 23.09.25 14:46, Itxaka Serrano Garcia ( > [email protected]) wrote: > > > > > 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? > > what would you even put there on UKIs that have no profiles? > > > 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? > > If the /run/systemd/stub/profile file doesn't exist it means "default > profile selected". And a UKI without profiles is understood to be the > same as one which just has one profile and that one is the default > one. > yes but that means we cannot use that to identify which efi file we booted on, only which profile in a file with multiple profiles. This is VERY specific to our use case I would say and I don't want to make any more unneeded noise here, but we need to identify which efi file we booted on always, if its multiprofile or not its good and the profile it launches even better, but we need to alkways trigger things depending on the efi file launched so this wont work for ourselves so we cannot fully rely on the profile (although Im gonna guess that there is nothing preventing us from creating UKIs with a single profile always, so we would get that ID+TITLE in there :)) > > > 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. > > sd-boot style assesment counters work the same for type 1 and type 2? > In type 1 case the .conf file is renamed, in type 2 case the .efi file > is renamed? > Yeah but I feel much more secure modifying a text file rather than an efi file which has been loaded fully into memory :) Notice that sometimes our UKI files are about 800Mb and we even do remote http iso boot, so I feel safe when our installer or upgrade agent just has to interact with a 10 bytes text file that anyone can fix :D > > Lennart > > -- > Lennart Poettering, Berlin > Thanks for all the info man, much appreciated, it's very useful for our future planning.
