On 21.02.23 09:31, Stefano Babic wrote: > Hi Jan, > > On 21.02.23 08:09, Jan Kiszka wrote: >> Hi again, >> >> playing with updates, I maneuvered the EBG envs on a system into this >> weird state: >> >> >> ---------------------------- >> Config Partition #0 Values: >> in_progress: yes >> revision: 4 >> kernel: C:BOOT1:linux.efi >> kernelargs: >> watchdog timeout: 0 seconds >> ustate: 3 (FAILED) >> >> user variables: >> recovery_status = failed >> >> >> >> ---------------------------- >> Config Partition #1 Values: >> in_progress: no >> revision: 3 >> kernel: C:BOOT1:linux.efi >> kernelargs: >> watchdog timeout: 0 seconds >> ustate: 2 (TESTING) >> >> user variables: >> > > I see - we should *never* reach this state. > >> >> To get there, I started an upstate with swupdate and booted into testing >> path #1. > > Ok > >> But then didn't confirm this update and rather started it >> again, using the same swu. > > It looks to me that this is the point. SWUpdate requires to close the > transaction, for itself or for the deployment server (Hawkbit). If a > system boots with TESTING, the glue logic should start SWUpdate asking > to close the transaction - with OK or FAILED by passing the -c parameter. > > However, this was thought to work together with the deployment server, > because it handles the state machine on Hawkbit. The parameter is > ignored if another deployment interface (Webserver, USB, ..) is used. > This is managed (again) on such situation on glue logic, and the > transaction (that is set of ustate) is done before starting SWUpdate. Or > in case of U-Boot, it is also managed with the help of additional (and > custom) variables. > > In your case, it seems that nothing is done at boot time, and SWUpdate > is started. SWUpdate does not know (because it expects that someone has > already decided, and ustate is not checked) that a new software is > running, and the same SWU is loaded again. > >> That didn't complete because the UUID clash >> was detected. swupdate terminated, and I was left with the above. >> >> I can still boot this constellation, EBG will select path #1 (endless >> testing, so to say). OTOH: >> >> # bg_printenv -c >> Using latest config partition >> Values: >> in_progress: yes >> revision: 4 >> kernel: C:BOOT1:linux.efi >> kernelargs: >> watchdog timeout: 0 seconds >> ustate: 3 (FAILED) >> >> user variables: >> recovery_status = failed >> >> >> That is not quite correct. To be fair, bg_printenv deals with an illegal >> state here. > > Agree. > >> Still... >> >> The key question is where to avoid best entering this state in the first >> place? > > My question is why the transaction was not closed before running > SWUpdate. This is a common pattern even with other bootloader, but it is > more important here because EBG stores an history (well, with deep=1) of > previous run. > > SWUpdate can check the state when is running, but there is no general > cases. There are use cases where the OK is coming from the application, > and SWUpdate waits via IPC the result (but then SWUpdate is started with > WAIT option, and does not try to load a new SWU). So SWUpdate cannot > decide itself that TESTING is a wrong ustate, because it depends on a > single project.
I was running swupdate manually from the command line. No backend involved, just the desire to intentionally break things. ;) Jan -- Siemens AG, Technology 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/5b7c25ce-d70f-fac7-7a85-660ebcf45847%40siemens.com.
