Minor change to the "Help" output #271
Conversation
Added the ".sh" file extension to the listed script commands just to be clear that the extension is definitely needed as part of the script filename.
Welcome back Martinski! I see you saw that development has resumed :P Nice catch btw, I like it! |
It was nice to have a little "pause" for a bit; although I was busy for a few days working with Viktor on BackupMon, and then addressing the "missing vertical scrollbar" issue found in some add-ons webGUI when loaded on the latest 386.14 F/W release.
It's a very minor detail but there's always a novice user who may try the commands without the ".sh" file extension and then complain that "it doesn't work." :>) |
Agreed, and I heard the rumbles of the development with you and Viktor but only from an arms reach, by the time I came in to poke you had already fixed it haha! Although Viktor had some other work for me to pickup as well for RTRMON, so all the help goes around lol!
Yeah very true, it's a minor detail but I've learned that some users really need the instructions to be clear. (Which is fair) I wanted to discuss with you a situation I noticed using the eject usb command, I think it's time to re-evaluate that command. I saw some logs from a user in the forums which did his update over Tailscale. That feature worked and kept his connection alive, but due to that I believe the USB stayed in use and the eject USB command in the system logs was just failing over and over again endlessly. (I'll try to find the logs again, but something along the lines of "The USB device is busy, waiting to try again") |
Yeah, I've seen all the messages about that, but a lot of it went over my head because I have no real context of the situation (I've never used RTRMON and don't have a BE-class router). But it looks like you pretty much took care of it.
Fully agree. With the latest two F/W versions (386.x & 388.x) being released recently, users will be updating their routers within the next few days, or weeks, depending on their cron schedule & postponement days.
Yeah, it's a tricky situation trying to keep TailScale "alive" when eventually the USB-attached drive must be ejected/removed for the F/W flash to be completed successfully. So I agree that the scenario must be re-evaluated & likely some changes will be required to handle things more "gracefully." I've never used TailScale myself so I am not familiar at all with how it works; all I know is that the binaries are Entware packages.
Yeah, it may help to review the user logs more closely. |
I will need to message the user again since the URL expired to his logs on dropbox. But I did copy and paste part of it in my conversation with him in our chat history, so I have this part which is the part of value I think: |
Can you also ask the user to send you the MerlinAU log file for that specific run? |
I actually have those already, but only in screenshot form from the user now. He used our "view log file" feature! One momento |
|
https://imgur.com/a/gxb04oc#nqR7rHe Both screenshots at that location |
OK, got it, thanks. |
Yeah thats no problem, it's all I have for now though to work with unfortunately. His reported issue was that he would try to run MerlinAU over tailscale, it would get the flashing steps, and then "terminate" and not actually update, he would then launch everything all over again and try again. etc he would never disconnect, but it wouldn't update. Here is the screenshots of his "terminated" screen: https://imgur.com/a/g0lJZN2#4GE19OD |
|
My "Higher Power" just summoned me :>) Her laptop PC has been acting "funny" lately, and now she needs me to look at something... Anyway, Hold my Beer!! :>) |
Hahaha enjoy the troubleshooting! Windows amiright? As a Workstation Engineer for a good few years I know all the fun of the famous "acting funny" report 😁 |
This beer be cold, don't be gone too long or you won't find it when you come back! 😜 |
Yep, it's a ~4-year-old Windows 10 HP laptop. It has been working well & a solid performer all these years; it's only during the last week that the "funny" issues started. I ran a disk check and found several bad sectors. I'll just take out the disk drive, do a full disk check, reformat & re-install the OS. Might as well do that to have a "clean" drive, start with a fresh OS, and re-install all the latest device drivers. The good thing is that all her important personal documents/files are stored in one of NAS drives, and the PCs are backed up once a week, so there's really nothing for me to copy over. In the meantime, she borrowed one of my spare laptops. |
OK, just to be crystal clear about the scenario. The user has a "LOCAL" ASUS router and a "REMOTE" ASUS router, with both routers (with their respective LAN subnets) being part of the TailScale "network." For the F/W flash, the user has a local PC (connected to LOCAL router) and using TailScale connects to the REMOTE router via SSH terminal session. The user starts MerlinAU on the REMOTE router to interactively perform the F/W flash onto this REMOTE router. The initial problem was that before the actual flash was started, the script was, by design, stopping all Entware services (including TailScale) which effectively was terminating the connection to the REMOTE router, and this resulted in the script never sending the actual Given the above, the current solution is not to stop the TailScale service on the REMOTE router. Do I understand the scenario correctly?
Yes, I agree. To successfully eject the USB-attached drive and perform the F/W flash, all Entware services must be terminated. I don't think there's way around that, but we can delay stopping TailScale until the very last second, right after the |
|
Found weird "bug" with the Set_FW_UpdateZIP_DirectoryPath function:
It wasn't working for me at all:
Where is the " echo "The directory path for the F/W ZIP file was updated successfully." message? I entered a valid destination different than it was originally set at, and it just threw me back to the main menu over and over again. I decided I'd add a pause of 20 seconds between these 2 lines: At about line 1258. Next run, it correctly showed the message, but then crashed with that error
|
This is all correct. I saw 3 possible solutions to this problem:
|
How is the Set_FW_UpdateZIP_DirectoryPath function updating the $FW_ZIP_BASE_DIR value in the same run? |
|
I answered my own question, it gets updated in the Update_Custom_Settings function when we do an update to the file. |
I have a solution that should address the issue of stopping TailScale and ejecting the USB-attached drive before sending the actual While I was busy rebuilding my wife's laptop main drive & reinstalling all device drives & apps, I had some time to think about this problem and run the various scenarios in my head, and a simpler solution just occurred to me: allow the script to continue executing in the background even after the remote connection has been terminated. This addresses the actual root cause. See PR #273. |
I hope the wifes laptop was a victory as well! |
|
Synced with Gnuton in commit: 7afe01f |
Added the ".sh" file extension to the listed script commands in the "Help" output screen to make it clear that the extension is definitely needed as part of the script filename.
BEFORE:
AFTER:
