Hi, >>> 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?
Nope, my best guess is that it was not a technical necessity but rather a semantically motivated implementation decision: When you confirm the current state to be OK, then there's probably little reason (semantically) to leave an environment in FAILED state as you just confirmed everything to be OK and the former FAILED-marked environment will not be considered for being booted anyway ― at least as long as the more recent current environment is not corrupt. That said, just because a boot path is marked as FAILED doesn't prevent the environment selection logics from considering it for being booted, see https://github.com/siemens/efibootguard/blob/next/env/fatvars.c#L207-L226. That, though, could be considered a "feature" as it tries very hard to bring the machine up, even in light of some FAILED-marked trickery like yours :) However, it only tries hard for the latest two environments, not considering further if you happen to have them... The bigger problem with setting all environments to OK on an `bg_setenv ―confirm` is, however, that all environments are written to. In SWUpdate, we're going to great lengths to avoid this, see https://github.com/sbabic/swupdate/blob/master/bootloader/ebg.c#L37-L93. Kind regards, Christian -- Dr. Christian Storm Siemens AG, Technology, T CED OES-DE Otto-Hahn-Ring 6, 81739 Munich, Germany -- 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/E8D9D118-E126-426E-A105-5B072C7F784B%40siemens.com.
