Small Improvements to Changelog Verification #301
Conversation
Small Improvements to Changelog Verification
|
I decided to re-implement the post-flash status email for the offline feature. At the time, I considered exporting the variable, but it opted to just remove the post-flash email since it was easier:
But considering now I'm exporting it anyways for the changelog above, I may as well re-implement the post-flash email. |
Yeah, when doing an offline update with Alpha/Beta versions, there is no notification from the router itself (i.e. executing the webs_update.sh script) so the corresponding NVRAM vars are not yet set and, therefore, the config entries may be unset as well. Setting those config entries during the offline update looks like a good idea to work around the problem without affecting F/W updates for production releases (as you said). |
OK, understood. The post-reboot email notification serves as a confirmation when the F/W update has been completed successfully. |
|
BTW, do you know what triggers the following messages that sometimes are shown right before the F/W update is about to start? I believe they happen during the call to the /sbin/ejusb command, and I wonder why they occur sometimes but not always. Just wondering... |
No idea, but I've noticed a number of odd things with the ejectusb command in recent firmwares. It's been much more "vocal" than previous versions. Before it never showed anything, then it showed a message if there was no USB, now it's showing kill commands, etc... Not exactly sure if it's a bad thing, but I've noticed it as well. It still makes me think it may be time to revisit an inhouse solution. I know i must sound like a hypocrite because I fought to use this initially, but it's behavior has changed over time... |
I'd suggest to try a simpler solution first: The above call should make it "silent" unless there's an actual error. As you said, those messages don't seem to be a "bad" thing. Other than that, the command seems to be working, AFAICT, and it's not affecting the actual F/W update process. |
As of now, I haven't noticed any changes in its actual behavior in the intended goal of ejecting the actual USB from the router. It's just much more chatty about what it's doing now. (Or not doing..) I'm fine with that suggestion of suppression! |
I'm wondering if those messages are triggered because there is still some running process that's accessing the USB drive right at the time when our script is trying to eject it, so it cannot unmount the filesystem. I'll sleep on this tonight :>)... |
This is the most likely explanation. It's been so long now that I don't remember the specifics, I'd need to go back through the Gnuton PR to see if I can spot the error again, but it felt like something was holding onto the USB still when we were trying to eject it. It was then around the first time I suggested maybe going back to an inhouse solution. I'll see if I can dig up more info again |
Yeah, it would be good to have more information as to when the msgs are triggered. It's not really an issue at all (so far) since the command has been working for our purposes, but I'm trying to understand what's happening to avoid it (if possible). |
Hey, bud. Apologies for the "radio silence." During my first week after coming back from vacation, I've been extremely busy with work, family & house stuff. In any case, I was thinking about the messages coming from the " What do you think of such an approach? |
No worries, I've been busy as well :)
Is your idea to export the cron jobs, remove them, and reimport them afterwards? Or just confirm no cron jobs are executing around the time? I'm not sure how I feel about that approach, I've need to see what you mean to better judge the solution. BTW: I know you had some contact with Jack in the past, any ideas when the dev versions will become main versions?
|
The idea is to remove all cron jobs created by 3rd-party addons from crontab a few seconds before the USB drive is ejected & the actual F/W update process begins. At that point, we want to eliminate the possibility of a cron job starting to execute and possibly accessing th USB drive filesystem when were about to eject the drive and begin the F/W update. The cron jobs will get restore after the router reboots so there's no need to do anything else (no "re-import"). I will submit a PR later in the evening so you can see what I mean and can test how it works. Right now, my wife & I are about to go out to do some shopping (groceries for the week and other stuff) and then will stop by my parents' home. I'll be offline until later today in the evening.
Jack Yaz has gone radio silent for almost a month now. Maybe he's on vacation (it's common in Europe to get a month vacation around this time). I'll ping him in a few days to check about the PRs. |
Description of the Bug/Issue:
When doing an offline firmware update this morning on my ASUS GT-BE98 Pro to the newest alpha build version 3006.102.2_alpha1 using MerlinAU, I noticed that it failed to find the correct changelog file even though the changelog file is present and valid in the directories as found below:
The source of the issue is this line in the changelog verification function:
release_version="$(Get_Custom_Setting "FW_New_Update_Notification_Vers")"This line is what MerlinAU uses to determine which changelog to look for.
As seen by the above screenshot it's looking for the NG file instead of the 3006 file on my 3006 router.
Possible Resolutions:
1. Different logic for offline changelog selection than production.
(Based on installed firmware version instead of update firmware version)
2. I could simply update the entry in the file, or disable the changelog verification.
3. Update the offline logic to update the production file entries if it's used to do a firmware update. This would allow the script to find the correct changelog file without impacting production logic.
With the noticed solution implemented, re-running gave the expected results as seen below:
