Dev v0.2.28 Targeted to Be New Master Release#27
Conversation
Document to keep track of known issues, areas to improve, general ideas and possible enhancements.
Reverted some changes related to setting the directory paths for the ZIP & LOG files as it was getting the wrong paths when changing the default setting to a different directory. Some more code improvements.
Update MerlinAU.sh in Dev branch.
Code changes & improvements to handle the case where the expected USB-attached drive path set up to download the ZIP file is not found at the time the F/W update check is run. In other situations, if the directory is not located we select the $HOME path and ask the user to confirm when running in "menu mode." Otherwise, we continue wit the temporary selection made.
Update MerlinAU.sh
Update MerlinAU.sh
Fixed bug causing the ZIP file to be deleted even when located on a USB-attached drive where Entware is installed & some code improvements in "Get_Custom_Setting()" function. Also modified "_DoCleanUp_" function to try to keep the ZIP file from being deleted under some conditions. Minor cleanup.
Update MerlinAU.sh
I just noticed in the README a note in the "Remaining/Planned Features" section saying "Be aware that JFFS partitions may not work post-upgrades in some cases." |
Martinski! I gotchu, I had to do a bit of lookup to find where this "came from" but it came from Yota in the snbforums when we were discussing the original design and limitations of this script. It's not "new" in the readme, it's been there since the start. Specifically this post: https://www.snbforums.com/threads/seeking-feedback-contributions-merlin-auto-update-solutions.87044/post-868240 Where he says: "A suggested idea is: prerequisite the router must have a USB drive connected, and then save the configuration files, jffs backup and current and newer versions of firmware in the USB drive before each update, because this is the only persistent storage location that has enough storage space and will work when router jffs doesn't work. (Yes, we have to assume that in some cases the jffs partition does not work after upgrading, because in history, they have adjusted the jffs partition by upgrading the firmware, and this kind of thing may cause jffs to not be mounted or need to be initialized)." I have not personally experienced this myself, but apparently it's a risk we had to identify/mention. |
Ah OK, got it. Thanks for the clarification. I think the note in the README should be clearer about the context. The way it's written now makes it sound as if the F/W update process itself could cause JFFS to fail, whereas the situation is more nuanced. The rare scenario can happen when a new F/W update includes a resizing or reconfiguration of the JFFS partition, in which case JFFS must be reformatted & reinitialized so any custom configs/scripts/files are deleted. IOW, it's not the case that "JFFS may not work" after the update; it's just that after JFFS has been reformatted & reinitialized during or following the F/W update, any custom configuration files, scripts, etc. are deleted so it "appears" as if "it's not working." I believe this happened once in the last 5 years, so yes it can happen but it's very rare, and the Release Notes usually point this out to users. My 2 cents. |
As always your 2 cents are more like 2 dollars! ;) |
This would be my preference since the scenario is very rare and unrelated to the script itself. It's just one of those post-update situations caused by changes in the new F/W, regardless of how the update was triggered (manual or automatic). |
Done deal. Updated in Dev and pushed through right away to Main here: #30 This kinda stuff is just documentation updates, don't think it requires approval lol. Especially considering we just discussed it. |
2 participants
Dev v0.2.28 Targeted to Be New Master Release