FreshTomato Wiki

User Tools

Site Tools

Trace:
remote_upgrade_poc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Last revisionBoth sides next revision
remote_upgrade_poc [2023/07/13 16:50] – [Concerns, Issues, and Known Challenges] -formatting hogwildremote_upgrade_poc [2023/07/13 16:51] – [Concerns, Issues, and Known Challenges] -formatting hogwild
Line 87: Line 87:
     - On its first run, FreshTomato will recreate and initialize required default parameters.     - On its first run, FreshTomato will recreate and initialize required default parameters.
     - A "dirty" upgrade (without NVRAM full erase/reset) might work. However, it is strongly discouraged,\\ since conflicts of current parameters/functions with the old ones can cause issues. \\  \\     - A "dirty" upgrade (without NVRAM full erase/reset) might work. However, it is strongly discouraged,\\ since conflicts of current parameters/functions with the old ones can cause issues. \\  \\
-  - Some form of permanent storage is needed. A full erase/reset of NVRAM-stored parameters via //mtd-erase// \\ is not committed until the next reboot/power cycle.+  - A form of permanent storage is needed. A full erase/reset of NVRAM-stored parameters via //mtd-erase// \\ is not committed until the next reboot/power cycle.
     - What is the difference betweeen the //mtd-erase// and //nvram erase// commands?     - What is the difference betweeen the //mtd-erase// and //nvram erase// commands?
-      - Issuing the //nvram erase// command still erases the nvram mtd. However, upon actions like a reboot, \\ NVRAM is saved to mtd from RAM. Thus, it will not wipe everything unless power is removed \\ right after the command completes. However, //nvram erase// clears the NVRAM in RAM then writes to flash, \\ but doesn't zero out all the flash. \\ See also: [[https://wiki.dd-wrt.com/wiki/index.php/Hard_reset_or_30/30/30#Erasing_NVRAM|Hard reset or 30/30/30 - DD-WRT Wiki]]+      - Issuing the //nvram erase// command still erases the nvram mtd. However, upon actions like a reboot, \\ NVRAM is saved to mtd from RAM. Thus, it will not wipe everything unless power is removed \\ right after the command completes. However, //nvram erase// clears the NVRAM in RAM then writes to flash, \\ but doesn't zero out all the flash. See also: [[https://wiki.dd-wrt.com/wiki/index.php/Hard_reset_or_30/30/30#Erasing_NVRAM|Hard reset or 30/30/30 - DD-WRT Wiki]]
       - The //nvram erase// command maintains the NVRAM header/checksum/length structure but erases variables. \\ The //mtd// command erases a flash partition's sectors, leaving its data values set to "FF" (flash erase state). \\  \\       - The //nvram erase// command maintains the NVRAM header/checksum/length structure but erases variables. \\ The //mtd// command erases a flash partition's sectors, leaving its data values set to "FF" (flash erase state). \\  \\
   - Thus, options for storage persistence would seem to be:   - Thus, options for storage persistence would seem to be:
Line 101: Line 101:
   - Having a stable basic Internet connection, VPN, and LAN parameters could allow an internal device \\ (like a PC or small service/maintenance appliance RPI) to announce its availability. This could allow it \\ to be accessed remotely for finalizing the whole post-upgrade configuration. A VPN might not be needed \\ if a remote access tool such as Teamviewer were available). \\  \\    - Having a stable basic Internet connection, VPN, and LAN parameters could allow an internal device \\ (like a PC or small service/maintenance appliance RPI) to announce its availability. This could allow it \\ to be accessed remotely for finalizing the whole post-upgrade configuration. A VPN might not be needed \\ if a remote access tool such as Teamviewer were available). \\  \\ 
   - Upgrade options using TFTP wouldn't be viable because of the need to trigger the transfer during a short \\ (a few seconds) service window during power-up. Such options might also require specific button combinations \\ which would not be practical.\\  \\    - Upgrade options using TFTP wouldn't be viable because of the need to trigger the transfer during a short \\ (a few seconds) service window during power-up. Such options might also require specific button combinations \\ which would not be practical.\\  \\ 
-  - Other options to do a controlled reconfiguration during upgrade might include leaving specific entry points, \\ hooks, or callback scripts. However, this would require thorough examination, development and testing. Such work might be unfeasible if developer resources were limited.+  - Other options to do a controlled reconfiguration during upgrade might include leaving specific entry points, \\ hooks, or callback scripts. However, this would require thorough examination, development and testing. \\ Such work might be unfeasible if developer resources were limited.
  
  
remote_upgrade_poc.txt · Last modified: 2023/07/13 17:05 by hogwild

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki