| Message ID | 20241103152312.1181339-1-radian.dc@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | web-app: add 120s timeout fallback for restart modal | expand |
Hi Adrian, On 11/3/24 16:23, Adrian DC wrote: > If SWUpdate is provided only per-request from a secondary system > (such as a rescue minimal Linux running of an EEPROM), > and if the update leads to a primary system without SWUpdate services, > after updating the SWUpdate page will never respond after rebooting. > > Add a 120s timeout upon SWUpdate restart modal access, > normal usage remains applicable, and 2 minutes timeout clears dialog. It is unclear to me what you want to achieve. Yes, if you update via a rescue, and production software has no SWUpdate, there is no connection at all. The same happens for a lot of different reasons, for example rescue and production have different IPs. By setting the timeout, it looks like that connection is established, but it is not and it is faking. A reload from the browser will just report 404. So which is the intention ? Best regards, Stefano Babic > --- > > Signed-off-by: Adrian DC <radian.dc@gmail.com> > --- > web-app/js/swupdate.js | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/web-app/js/swupdate.js b/web-app/js/swupdate.js > index faeca3d2..d2afd700 100755 > --- a/web-app/js/swupdate.js > +++ b/web-app/js/swupdate.js > @@ -30,6 +30,13 @@ function showRestart () { > const restartModal = new bootstrap.Modal('#swu-restart-modal', { backdrop: 'static', keyboard: false }) > restartModal.show() > window.setTimeout(tryReload, 3000) > + window.setTimeout(fallbackRestart, 120000) > +} > + > +function fallbackRestart () { > + if ($('#swu-restart-modal').is(':visible')) { > + $('#swu-restart-modal').modal('hide') > + } > } > > function tryReload () {
Hi Stefano, Initially this fix was to avoid developers / users / client of our STM32MP1 board to wait forever, without providing "guessed" informations. For context if you're interested, I have three cases, the two first being rather identical from SWUpdate's point of view : - factory -> rescue : STM32MP1 initial boot, over EEPROM (flashed over USB through DFU / snagboot) - rescue -> rescue : First SWUpdate "rescue" image update, which also prepares the eMMC partitions hence mandatory per compatibility checks - rescue -> runtime : Second (or regular developer tests) SWUpdate "runtime" image update, enabling EEPROM U-Boot to default boot over eMMC, and without SWUpdate at all for security reasons, the access to rescue being restricted and per physical access validation over interactive U-Boot UART boot menu At second glance now, the restarting modal going away does give you access to fake SWUpdate features though unconnected, I agree with your feedback. I'll see if I have time to refactor this into a timeout that shows a static modal just like restarting, would make way more sense. And add hints to close the page and such. Best regards, Le lundi 4 novembre 2024 à 10:32:34 UTC+1, Stefano Babic a écrit : Hi Adrian, On 11/3/24 16:23, Adrian DC wrote: > If SWUpdate is provided only per-request from a secondary system > (such as a rescue minimal Linux running of an EEPROM), > and if the update leads to a primary system without SWUpdate services, > after updating the SWUpdate page will never respond after rebooting. > > Add a 120s timeout upon SWUpdate restart modal access, > normal usage remains applicable, and 2 minutes timeout clears dialog. It is unclear to me what you want to achieve. Yes, if you update via a rescue, and production software has no SWUpdate, there is no connection at all. The same happens for a lot of different reasons, for example rescue and production have different IPs. By setting the timeout, it looks like that connection is established, but it is not and it is faking. A reload from the browser will just report 404. So which is the intention ? Best regards, Stefano Babic > --- > > Signed-off-by: Adrian DC <radi...@gmail.com> > --- > web-app/js/swupdate.js | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/web-app/js/swupdate.js b/web-app/js/swupdate.js > index faeca3d2..d2afd700 100755 > --- a/web-app/js/swupdate.js > +++ b/web-app/js/swupdate.js > @@ -30,6 +30,13 @@ function showRestart () { > const restartModal = new bootstrap.Modal('#swu-restart-modal', { backdrop: 'static', keyboard: false }) > restartModal.show() > window.setTimeout(tryReload, 3000) > + window.setTimeout(fallbackRestart, 120000) > +} > + > +function fallbackRestart () { > + if ($('#swu-restart-modal').is(':visible')) { > + $('#swu-restart-modal').modal('hide') > + } > } > > function tryReload () {
diff --git a/web-app/js/swupdate.js b/web-app/js/swupdate.js index faeca3d2..d2afd700 100755 --- a/web-app/js/swupdate.js +++ b/web-app/js/swupdate.js @@ -30,6 +30,13 @@ function showRestart () { const restartModal = new bootstrap.Modal('#swu-restart-modal', { backdrop: 'static', keyboard: false }) restartModal.show() window.setTimeout(tryReload, 3000) + window.setTimeout(fallbackRestart, 120000) +} + +function fallbackRestart () { + if ($('#swu-restart-modal').is(':visible')) { + $('#swu-restart-modal').modal('hide') + } } function tryReload () {
If SWUpdate is provided only per-request from a secondary system (such as a rescue minimal Linux running of an EEPROM), and if the update leads to a primary system without SWUpdate services, after updating the SWUpdate page will never respond after rebooting. Add a 120s timeout upon SWUpdate restart modal access, normal usage remains applicable, and 2 minutes timeout clears dialog. --- Signed-off-by: Adrian DC <radian.dc@gmail.com> --- web-app/js/swupdate.js | 7 +++++++ 1 file changed, 7 insertions(+)