On 14.10.21 11:58, Michael Adler wrote: > Hi Jan, > >> Could you explain the use case here? I'm not against the change per se, >> but I'm against zero verbosity ;). > > yes, sure. One use-case would be to determine the ustate of the overall > system (and based on this, do something else, > e.g. perform a migration). There are (at least) two ways to accomplish that: > > 1) Parse the output of bg_printenv. > > There are typically two ustate values in the output, so you have to `grep` > for all the ustates and then check > symmetrically (e.g. part 0/1 is in ustate 0/1 or 1/0, which is considered to > be the same overall ustate). > > Usually the output processing happens in some sort of shell script and so > everyone tends to cook up his own hacks (which may not > work in all shells). > > With this patch, I can run something like `bg_printenv -p 0 | grep "^ustate"` > for each partition and then perform the > comparisons (the correct usage of `head` and `tail` will accomplish the same). > > Eventually though, I would like to further extend bg_printenv to get rid of > the `grep` as well. In that sense, the patch is > a first step to reach that goal.
You mean you want the effective ustate, considering what is the latest env in use etc. - would be fine with me and likely has an even higher value. > > 2) (UGLY!) Mount each boot partition and use something like bg_printenv -f > BGENV.dat | grep ustate. > > Slightly off-topic: When I do AB firmware updates with U-Boot, I only use a > single ustate to track the update state. > This makes things a lot easier (e.g. certain ustate combinations such as 1,1 > are impossible by design). I assume you are referring to using classic U-Boot A/B selection via scripts, not via UEFI and EBG: U-Boot has a different strategy to make that single state persistent and (hopefully) robust against corruptions via power-cuts during updates. EBG has the strategy to never touch the data that is sufficient to boot a working system, only update the one that will eventually replace that. That said, nothing speaks against presenting a virtual state that takes that into account. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/2444f90d-3a03-a263-30b1-af514524bdbc%40siemens.com.
