On 21.11.18 15:56, Mathieu Alexandre-Tétreault wrote:
Hi Andreas,
Thank you for your answer.
On Mon, Nov 19, 2018 at 09:32:52PM +0000, Mathieu Alexandre-Tétreault wrote:
Howdy,
I went through the source code and I have a few questions:
1. Is efibootguard able to detect a failed boot? How is it handled? From what
I understand, is that the code simply returns using: error_exit.
Hi, yes this is the whole sense of efibootguard. You could read the docs in the
docs/ folder. There it is explained.
Short version:
The whole thing works with using the hardware watchdog timer together with a
redundant environment on disk. When you update the system, you trigger a variable
in the environment and if the system fails to boot, >the watchdog will reset
the system and efibootguard will see the already triggered variable and bring the
system back to a working state.
My bad, it seems I went through the doc a little bit to fast.
2. I’d like to be able to use a boot counter to toggle the rootfs/kernel used.
For example, if after three failed boot attempt, the boot switched to
rootfs2 and kernel2. So each time efibootguard boots, the counter is
incremented, and as soon as the kernel is fully loaded a user service
resets the boot counter. As far as I know, this feature is not implemented
in efibootguear (am I wrong?). I was thinking about using the uservars for
that purpose. Is there any concern with that, or things I should be awared
of?
You are implementing a completely different logic on top of the actual
switching logic then. Also I don't get your example:
"... if after three failed boot attempt, the boot switched to rootfs2 and
kernel2."
Does not make sense to me. efibootguard switches back after the first failed
attempt to bring up new rootfs/kernel. It does not test three times but one time.
Why would you try it more then once? A system should be >reliable.
This is actually a customer's requirement. They want the system to test the
update more than once. Their point is that the power could get disconnected
thus, a failed attemp could be due to power outtage and not a corrupted update.
Hmm, sounds like a not completely far-fetched point - though I wonder how
unreliable their power supply may be that such case requires device-side
handling. Conceptually, we could introduce a retry counter that only makes a
transition to "failed" when it reaches 0 and otherwise keeps the device in the
"testing" state. Feel free to propose a patch.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/efibootguard-dev/62d53dac-837d-40a3-a293-049a83a62bcb%40siemens.com.
For more options, visit https://groups.google.com/d/optout.
