Hi Jan,
On 21.02.23 10:21, Jan Kiszka wrote:
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. ;)
The best way to reach the goal...:-D
And yes, this can happen because the part deciding if previous update
was ok, is missing. In most projects, if system is up and running, it is
considered ok. That means the decision is done in SWUpdate's systemd run
unit (or SystemV init script), see also glue logic under
/usr/lib/swupdate. In some other cases, update is ok only if application
is running, a migration of a custom database was ok, ad, and....that
means is outside SWUpdate. SWUpdate supports all these use cases.
To avoid the issue you are seeing, the decsion should be done inside
SWUpdate: something like a transiction TESTING ==> OK, because SWUpdate
is running. But as I said, this can be done if it will be configurable,
or it will break the use cases I mentioned.
Regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: [email protected]
=====================================================================
--
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/42568352-ea72-0f41-0944-fea437f01edc%40denx.de.
