So this device was healthy and already running UBI formware normally, then you flashed sysupgrade and since then it always drops you to recovery mode (ie. you see only 2.4ghz wifi and configuration won't survive reboot)? Please confirm in detail, so I can understand what's going on.
The recovery you are running comes from v0.5 UBI installer from what I can tell and that should be working fine.
What is happening is probably that the device has crashed and because of that is now starting recovery for you to figure out what was happening and report to us
Please open SSH console on the device and check PSTORE/ramoops content and report back the output:
ls -1 /sys/fs/pstore
cat /sys/fs/pstore/*
After that, you can delete the PSTORE content which should make the device return to boot normally.
rm /sys/fs/pstore/*
Disconnecting the power from the device for 10-15s should also make it forget PSTORE content in RAM and return to normal operation.
root@OpenWrt:~# ls -1 /sys/fs/pstore
root@OpenWrt:~# cat /sys/fs/pstore/*
cat: can't open '/sys/fs/pstore/*': No such file or directory
root@OpenWrt:~# ls -1 /sys/fs/pstore
root@OpenWrt:~# cat /sys/fs/pstore/*
cat: can't open '/sys/fs/pstore/*': No such file or directory
root@OpenWrt:~# cat /sys/fs/pstore/
cat: read error: Is a directory
root@OpenWrt:~#
Yes, very strange indeed. Did you disconnect the power or toggle the power switch maybe? That also clears PSTORE and hence makes it go back to normal boot.
Modify recovery to submit crashlogs somewhere or keep them in additional UBI volume, ..., then remove them from PSTORE and reboot. This is how imagine it for remote-managed unattended devices. Minimal network config as well as URI for submission can be stored in U-Boot env.
Soon LuCI will have notification support, and that will allow to clearly show that the device has booted into recovery mode and also that there are crashlogs in PSTORE. Probably we (any volunteers?) can make a LuCI UI to view or download logs from /sys/fs/pstore (using rpcd file access methods or dedicated rpcd-mod-pstore backend) and also allow to easily clear it to go back to normal boot.
Depends on https://github.com/openwrt/luci/pull/5041
If you want to disable the feature entirely, tell the bootloader not to care:
fw_setenv bootcmd "run boot_ubi"
which will replace the default which is
if pstore check ; then run boot_recovery ; else run boot_ubi ; fi
The last couple of releases, I've been having frequent wifi issues. Both 5ghz and 2.4ghz networks will go down and then come back up a few minutes later. I think it might be related to the recent hostapd change.
This is not caused by channel switching or DFS and there are no logs indicating a reason for the radio/hotspot restart. I'm on r17101-f4e3ff5b07 - would be good to hear if others are having this issue or if anyone has ideas for addressing this.
@daniel The issue happened to me again this night (note i'm the original reporter unless there was a 3rd person before me), again roughly around 23 CET (at 4:30 i've seen kernel msg connecting my LAN cable 5h 50 min after boot, that would make it around 22:40). Sadly I was not aware of your pstore comment, so i went straight to the poweroff to resolve it.
Next time I will be ready along with system logs on USB stick set up using this guide, I expect it to happen after another few days.
@Dopam-IT_1987 note you don't need to flash new system - half a minute poweroff restores original configuration. I did reflash (bricking device) because I thought system was not installed fully and wanted to start over, then I went into TFTP recovery to restore from the bricked state.
That screenshot is utterly useless in this format. Get a copy of your UCI network and wireless configs instead (run the commands uci show network and uci show wireless in CLI and paste the result here - make sure you remove the sensitive details like SSID, MAC adress, WiFi PSK).
Hey all,
Picked up a couple Linksys E8450s on sale with the intention of installing OpenWRT and using them in "dumb" AP mode, eventually in 802.11s mesh mode. Tested with the factory-compatible snapshot, and things worked very well for a few days.
Went ahead and did the UBI install from the prebuilt images on github, but saw the same problems with the network quitting that a couple of people seem to have mentioned above. Installed the latest snapshot via Attended Sysupgrade yesterday to see if that would help, and it did. BUT...
It randomized the ethernet macs and, not realizing this, I thought I had locked myself out. Ended up doing a full reset before figuring out what it had done. Is that normal? I generally set up my DHCP server configured so MAC addresses get "static" IPs. This is very useful after a factory reset on APs, switches, etc.
The sysupgrade also re-activated odhcpd and possibly the firewall, which I had disabled, and I am wondering what the proper OpenWRT way is to avoid this when doing a sysupgrade. Or is the proper upgrade procedure to backup, sysupgrade, reset to defaults, and restore? I'd like to be able to upgrade devices in-place, especially with the one probably going in the attic.
Many thanks to all the devs.
Usually, across stable maintenance updates, one can easily sysupgrade with leaving the configuration in place. However, even then I usually do back it up just in case. With snapshots, this is a little bit a different story and such rather unpleasant surprises are somewhat expected. One could now investigate what exactly went wrong and ultimately fix this I guess.
I'm seeing the randomized MAC's as well. I reverted back to a firmware I generated with ImageBuilder from a couple days back and it cleared up the problem. Not sure what changed in the past couple days in the snapshot that appears to be causing this. I have two RT3200 running a BATMAN mesh.
I'm seeing this in Luci, Network -> Interfaces -> Devices tab. eth0, lan1-4, wan were all showing MAC addresses not programmed into my router. i reverted back to a snapshot that had kernel 5.10.50, and it was back to my router's MACs.
)