I somewhat isolated the problem. I used efibg 0.9 and tested with an infinite loop at the end of efi_main() just before loading the image, and indeed in this case the watchdog does work. Furthermore, when booting, I noticed that disabling the module (in my case, it is built-in the kernel) with initcall_blacklist=iTCO_wdt_init_module in the kernel options does fix my issue (basically the watchdog does reboot the system a little while after booting into linux as expected).
So it seems the cause of my issues is that the iTCO_wdt module somewhat resets the watchdog set by efibg at boot. I wonder if it's possible to make the module load without messing with the efibg watchdog set at boot. Second, I noticed in "bg_setenv -c" that the code for the "-c" argument doesn't contain anything that stops the watchdog when confirming. I was somewhat expecting this based on the state machine found in "UPDATE.md" which seems to state the watchdog reboot doesn't happen if we confirm in time. So even after confirming, my system will reboot (even if iTCO_wdt did leave the efibg watchdog alone in an hypothetical situation). One way I see of respecting UPDATE.md state machine (one way to make it work) would be to compile the kernel with iTCO_wdt as a module and preventing it to be loaded at boot. Then I could confirm with "modprobe iTCO_wdt; bg_setenv -c" i.e. loading the module to cancel the watchdog reboot, and then confirming But... isn't bg_setenv -c supposed to take care of the watchdog?! I'm confused. -- 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/CAPWAaBtv%2BU%3D2Edr6jv0MAqVry2EBBK8iU9%3DYKuJ%3Da34S7UCdQA%40mail.gmail.com.
