-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GL-iNet USB150 bricked when updated to 2145 or 2152 #645
Comments
I'll dig out my USB150 this weekend and take a look. My guess is that something changed specifically for this device when we did the OpenWRT upgrade to their latest version earlier this week. Anyway, dont try an upgrade on the USB150 again until I update this ticket. |
I'm gonna leave it at 3.22.12.0 for now... |
The last couple of version of nightly have been weird with the USB150. It now sort of powers down and doesn't come back up after upgrade. |
Update. KC2CBD hit the nail on the head. After the update, the node powers off and does not power back on. However after updating, if you wait for the node to power off (about 4 minutes), then you power cycle it, and wait several more minutes, it will come back up with the new firmware and appears to be working correctly. |
I was actually going to create an issue but K6CCC beat me to it. |
Same issue with nightly 2159. After the update the USB150 powers down, but does not power back up. Must be manually power cycled to get it to boot up. |
Still the same thing with NB 2166. Node powers down, but does not power back up after firmware update. Requires manual power cycle. |
Thanks for checking. I promise to update this ticket when there's any relevant changes though ... if you want to save yourself some time. |
Update: |
2180 was new..it took the firmware and then basically shut off. I then power cycled and like previously it was updated to 2180. |
2187 seems to have fixed the USB150 on my Desktop but on the Laptop it still did the same thing. |
Neither 2187 nor 2195 fixed this for me. Both required multiple power cycles to bring the USB150 back onto the mesh. |
Ever optimistic .. but I dont have anything in the works to address this problem ... hoping for some revelation at some point. |
I moved the "storage" location for the USB150 at home to an outlet that is remotely controllable, so easy to power cycle now... |
@aanon4 here is an openwrt issue that looks like the same issue (with the fix) ... https://forum.openwrt.org/t/reboot-command-fail/113250/3 |
Unfortunately, adding broken-flash-reset to the DTS did not fix things. |
Also, historically, the serial port was disabled - but I tried disabling that again (in case there was some side-effect in doing that) but that also made no difference. |
Flashing the OpenWRT reference image shows the same behavior so .. in case there was any doubt .. this problem is not related to our configuration or changes. |
The last couple of firmware releases have been working correctly. |
Concur. 2245 did not require a power cycle, and I just updated to 2267 and that did not require a power cycle on the USB150. |
Updated all 14 of my nodes to Nightly 2145 and all worked except my USB150. The 2145 update was made over an RF link of about 6 feet. When I got home and checked it out, a computer would recognize that a USB device was plugged in, but could not get an IP address from it. Power cycled several times with the same result. I don't remember for sure what the previous version was, but it was a nightly from sometime in the past week.
This morning used the GL-iNet unbrick process to unbrick the USB150. Then did an update to 3.22.12.0 That properly came up with the first boot screen and then after the next reboot, it was operating properly as far as I could tell. I don't have any other 2 GHz AREDN here to test an AREDN RF link with. Next updated to nightly 2152. Again, the USB150 bricked. The attached computer recognizes that a USB device has been plugged in, but can not get an IP address from it.
Repeated the unbrick and then AREDN load and update process with the same result.
The text was updated successfully, but these errors were encountered: