Update MerlinAutoUpdate.sh

[Martinski4GitHub]

Some minor cleanup and tightening up code.

[Martinski4GitHub]

WRT your "check_memory_and_reboot()" function where you check for free RAM vs F/W file size, I think there are a couple of other places along the way when free RAM may not be sufficient:

1. Before downloading the ZIP file into the router's "$HOME" folder (instead of a USB-attached drive), the router may already be in a "low free RAM" state, depending on the number of processes & extra add-ons running as well as other factors that slowly consume RAM over time (more so if the router's uptime is several weeks or months).

2. After just downloading the ZIP file into the router's "$HOME" folder, there may not be enough free RAM to continue to uncompress & extract the F/W files into the same $HOME folder.

For such cases, you might need to check available free RAM before the ZIP file is downloaded, and then again before uncompressing/extracting the files, especially if using the router's "$HOME" directory for all of it, and not the USB drive at all. Also, you might need to add some "overhead" to the file size comparison to account for the "ZIP + F/W" files being on the "$HOME" directory at the same time, even if just temporarily.

I don't have a router with low physical RAM (< 512MB), so I have no way to test/verify the above scenarios, but I think that's something to consider for future improvements.

Just my 2 cents.

[ExtremeFiretop]

WRT your "check_memory_and_reboot()" function where you check for free RAM vs F/W file size, I think there are a couple of other places along the way when free RAM may not be sufficient:

1. Before downloading the ZIP file into the router's "$HOME" folder (instead of a USB-attached drive), the router may already be in a "low free RAM" state, depending on the number of processes & extra add-ons running as well as other factors that slowly consume RAM over time (more so if the router's uptime is several weeks or months).
2. After just downloading the ZIP file into the router's "$HOME" folder, there may not be enough free RAM to continue to uncompress & extract the F/W files into the same $HOME folder.

For such cases, you might need to check available free RAM before the ZIP file is downloaded, and then again before uncompressing/extracting the files, especially if using the router's "$HOME" directory for all of it, and not the USB drive at all. Also, you might need to add some "overhead" to the file size comparison to account for the "ZIP + F/W" files being on the "$HOME" directory at the same time, even if just temporarily.

I don't have a router with low physical RAM (< 512MB), so I have no way to test/verify the above scenarios, but I think that's something to consider for future improvements.

Just my 2 cents.

I actually fully agree, to be honest I don't like my implementation, it's too basic because it doesn't re-trigger the update post reboot, it would be ideal if we could schedule a cron for lets say, 5 minutes out, and commit it to memory, and then reboot, so upon reboot it tries again. The complication for me is how to undo the committed 5 minute cron after the update is done? do we even need too or would it be flushed out after the update?

I know currently our cron flushes out after a reboot, so it's not committed yet anyways.

[Martinski4GitHub]

I actually fully agree, to be honest I don't like my implementation, it's too basic because it doesn't re-trigger the update post reboot, it would be ideal if we could schedule a cron for lets say, 5 minutes out, and commit it to memory, and then reboot, so upon reboot it tries again. The complication for me is how to undo the committed 5 minute cron after the update is done? do we even need too or would it be flushed out after the update?

I know currently our cron flushes out after a reboot, so it's not committed yet anyways.

Take a look at the code changes in PR #14. They address both scenarios where a cron job needs to be persistent across reboots, and also the "post-reboot" trigger to rerun the script after some delay to make sure all services are started (such as NTP) so networking services are ready to go. I have not tested it all yet, but so far the add/delete mechanism for persistency works fine on my router.