Capture list of safeguard measures implemented in the script

[wellloaded]

This can be a file on the repo where all the safety measures are documented.
Things I can think about are:

• certificate check for downloads
• unzip exit code
• MD5 checking on the downloaded file
• etc

Essentially anything/everything that would raise the confidence level and to document: this was thought about

[HommeOursPorc]

For fun I asked Gemini to tell me what it thinks of my script so far:

(Sorry, on my phone right now and gboard copy-paste function is bleh 😮‍💨)

Based on the ftup.sh script you provided and the FreshTomato source code we've analyzed, your script is quite robust and follows the official firmware's logic very closely. You have successfully implemented the "bulletproofing" and safety checks required for a reliable CLI upgrade tool.

Here is an evaluation of your current implementation:
Strengths of Your Script

1. Signal Armor: Your trap_all function effectively mimics the SIG_IGN behavior found in upgrade.c. By trapping signals like SIGHUP and SIGTERM, you ensure the upgrade continues even if the SSH session drops. Service Teardown: Your prepare_upgrade function correctly sets action_service="upgrade-start". This triggers the same cleanup routine as the WebUI, freeing up critical RAM by stopping non-essential services.
Clean Transitions: You correctly use kill -s SIGUSR1 1 to signal the init process to handle the service changes, ensuring the system state is consistent with what init.c expects.
Safety Checks: You've included vital checks that even some manual methods miss, such as:
Verifying enough free memory exists before unzipping.
MD5 sum verification for official downloads.
Explicitly unlinking log files to recover ramdisk space.
2. JFFS Handling
Your handle_jffs logic is a critical safety feature. By checking if the script is running from /jffs or if the download directory is within /jffs, you prevent a scenario where the system tries to unmount a partition that is currently in use, which would cause the upgrade to fail.
3. Areas for Consideration
The "Point of No Return" Backgrounding: You launch the actual flash process in a background subshell ( ... ) &. This is an excellent way to prevent "disconnection incidents" from killing the flash. However, since you use tail -F to show the output, ensure that if the user Ctrl+Cs the tail command, it doesn't accidentally trigger a signal that reaches the background subshell. (Your current trap_all inside the subshell should protect against this).
NVRAM Locking: While you set action_service="upgrade-start", you might consider explicitly setting nvram set g_upgrade=1 early in your prepare_upgrade function. As seen in init.c, this flag is the primary way to tell the init loop to stop reaping processes and checking services.
Flash Failure Recovery: Your script has a recovery block for failed flashes. This is vital. If mtd-write fails, the router is in a precarious state. Providing a 10-second window to cancel the reboot is a great safety net for advanced users to try and fix the flash manually before the system restarts.

---

About nvram set g_upgrade=1, this is automatically done by the upgrade service, no need to add it to the script.