On 22.03.24 17:30, 'Michael Adler' via EFI Boot Guard wrote: > Hi Christopher, > >> I haven't tried this with the latest version. > > I checked the code, and this is indeed intended behavior: > `journal_process_action` has some special logic in place (see [1]), which > results in calling `ebg_env_setglobalstate` if `ustate` is to be updated. This > function sets the `ustate` of *all* environments to zero, as per documentation > [2]. > >> I am wondering, if `bg_setenv --confirm` should set only the booted >> configuration to OK or if the case which I have here, where all configs are >> set to OK, even though one is FAILED ? > > Good question. I guess there are reasons for the current behavior :) Jan > Kiszka might remember the reason. I can only guess; maybe it is meant to > prepare the standby BGENV for the next update (starting with a clean slate) > since you are not supposed to roll back anymore. >
I don't remember this detail anymore either. It dates back to the early days of our code base, and the commit introducing this was not properly motivate - my bad having accepted it back then. Christian, as this behavior is also part of the library API, can you remember when this global setting of ustate(s) to OK would be needed? The current state machine is definitely convoluted and not well maintainable anymore. But as we have an official API, it's also not easy to change things. We are already discussing internally for a while that it would need a "version 2" to reconstruct the actually needed features and behavior without having to deal with the legacy. Jan -- Siemens AG, Technology Linux Expert Center -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to efibootguard-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/3168c49e-89b0-4588-883c-559c886b8589%40siemens.com.
