Update: July 21st : All has been fine since I got a replacement back in April.
I've been using LEDE v17.01.2 on my WRT1900ACS v2 with 30+ days uptime, and today I wake up to find the net is down, so I check the router and there's only 2 LEDs on (first and last, they may have been flashing, don't remember as I was half awake).
After powering the device off/on again it booted back into the Linksys firmware, and I was wondering if that is meant to happen after a crash?.
Anyway i'm back on LEDE now after using the restore previous firmware option.
No idea why it crashed, haven't changed anything, and using the same devices. 1 Wired, and 4 Wireless, with one permanently connected (Sky Box).
uboot environment has to be switched to boot the other kernel
How lede did that.. well you need uboot commands to do that
This is how it's done
#hacked from /lib/upgrade/linksys.sh
cur_boot_part=`/usr/sbin/fw_printenv -n boot_part`
if [ "$cur_boot_part" = "1" ]
fw_setenv boot_part 2
fw_setenv bootcmd "run altnandboot"
elif [ "$cur_boot_part" = "2" ]
fw_setenv boot_part 1
fw_setenv bootcmd "run nandboot"
# re-enable recovery so we get back if the new firmware is broken
fw_setenv auto_recovery yes
Hi, thanks for the reply, but I'm not asking how to switch partitions. My device switched by its self after crashing, and was wondering if that's meant to happen.
No, it should not happen.
Boo, it happened again, this time the device was up less than a day.
The LEDs flashed like before, but then most of them flashed on and off, it did that a few times until i turned it off/on and then i was back in the OEM firmware again.
Used the "restore previous firmware option" again and booted back into LEDE no problem.
Maybe the device is faulty?
Sigh, crashed again, but this time I didn't have to do anything, it rebooted back into LEDE all by its self.
Don't know if there's meant to be crash logs or something, but I see nothing in /tmp or /proc/sys/debug.
Not sure if I should wait for the next release of LEDE, or get it replaced.
if crashlog I think it is to be found in:
you can force and check:
echo c >/proc/sysrq-trigger
There is a crashlog under /sys/kernel/debug/, though it's empty, even after triggering a crash with "echo c >/proc/sysrq-trigger"
Yep, just tested on a rango and mamba, just an empty file, could have sworn that was being populated on the mamba when first tested for this. Best bet may be to try and capture information from a crash via serial output if you have a USB/TTY cable.
I don't have a cable yet, as this router needs a 2.0mm pitch cable, yet i can only find 2.54mm in the UK. I'm sure somewhere must sell them, I'm just new to all this.
Might just be simpler to replace the router, easy enough through Amazon.
Hit ebay for both, cheap on a slow boat from...
3 wires and a SBC with a 3.3 TTL UART onboard will do in a pinch.
As your report seems to be a one-off it might actually be the device. You might also want to try a master snapshot image to check for same result.
Had the same issue with mine the first day i got it except mine was lasting about max 10 minutes before crashing... started a return with amazon and got the replacement yesterday. Lasted through the night without crashing so fingers crossed....
Oops, I had forgot all about this post, had gotten busy, and my device had been working fine until today.
It crashed after being up for 180+ days, and unlike before I had to wait a few minutes before the device would boot up, seems it's heat related, today's been in the 80s and have no AC, it is the UK after all, so it's quite a bit hotter in the house.
Gonna try and get it replaced like I was going to do before, but never got around to it, didn't help that it was working fine.
Got my replacement all setup, lets see how this one goes.