Thanks a lot timg236 for this quick and detailed answer and especially the 2 off the shelf projects you mentioned, that seems completely in line with my initial expectations !
I explored the way rpi-system-update works and how is triggered a full install from scratch (using GPIO based EEPROM config). I am wondering if there is a world where it could be possible to trigger a full install or re-install remotely (ie triggering HTTP boot mode) without GPIO intervention (because in some Pis I use a hat is present with no access to GPIO) nor OS system access to trigger EEPROM update (in case of system being fully crashed).
The idea I had in mind would be to have always the primary boot mode to be HTTP boot mode, with SD or USB as secondary, and follow one of those 2 options:
- A) implement a webserver hosting the boot.img used for HTTP boot mode that would not deliver any image (ex: HTTP 404) if the Pi serial ID that I would expect to be present in some HTTP headers would not match a Pi I need to be recovered through a full new install
- B) Somehow trigger inside the boot.img used for the HTTP boot mode the booting process based on SD or USB device without requiring a full reboot (and then avoiding looping over the HTTP boot mode).
Do you think one of the 2 options could work (or any other one) ?
Thanks!
I explored the way rpi-system-update works and how is triggered a full install from scratch (using GPIO based EEPROM config). I am wondering if there is a world where it could be possible to trigger a full install or re-install remotely (ie triggering HTTP boot mode) without GPIO intervention (because in some Pis I use a hat is present with no access to GPIO) nor OS system access to trigger EEPROM update (in case of system being fully crashed).
The idea I had in mind would be to have always the primary boot mode to be HTTP boot mode, with SD or USB as secondary, and follow one of those 2 options:
- A) implement a webserver hosting the boot.img used for HTTP boot mode that would not deliver any image (ex: HTTP 404) if the Pi serial ID that I would expect to be present in some HTTP headers would not match a Pi I need to be recovered through a full new install
- B) Somehow trigger inside the boot.img used for the HTTP boot mode the booting process based on SD or USB device without requiring a full reboot (and then avoiding looping over the HTTP boot mode).
Do you think one of the 2 options could work (or any other one) ?
Thanks!
Statistics: Posted by DarkoM — Wed Nov 06, 2024 9:01 am
