David Bauer <m...@david-bauer.net> writes:
> As the reported major bugs are ironed out, switch to the new kernel to
> begin testing with a broader audience.
Hmm... I wonder if you might want to hold back on that for a while.
I have no useful info yet since I don't have console access on this
device, but I just lost network access to a UniFi AP AC PRO after trying
out current master (fcd14017007d).
I'll see what I can get out of it, but I don't promise anything if I
can't figure out a way to get network access. The AP is located
semi-outdoors so I don't really want to open it and break the seal..
The AP ran a similar arbitrary master checkout from January before
upgrading (b070101c506c), having a v4.19.93 kernel. I upgraded using
'sysupgrade -v ...' in a shell, keeping existing configs, as I usually
do unless told not to ;-)
The part of the upgrade which is visible via ssh looked fine:
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r11998-b070101c506c
-----------------------------------------------------
root@unifiac2:~# sysupgrade -v
http://owrt.mork.no/lede/r12793-fcd14017007d/targets/ath79/generic/openwrt-snapshot-ath79-generic-ubnt_unifiac-pro-squashfs-sysupgrade.bin
Downloading
'http://owrt.mork.no/lede/r12793-fcd14017007d/targets/ath79/generic/openwrt-snapshot-ath79-generic-ubnt_unifiac-pro-squashfs-sysupgrade.bin'
Connecting to 192.168.99.1:80
Writing to '/tmp/sysupgrade.img'
/tmp/sysupgrade.img 100% |*******************************| 5056k 0:00:00 ETA
Download completed (5178139 bytes)
Saving config files...
etc/config/dhcp
etc/config/dropbear
etc/config/firewall
etc/config/lldpd
etc/config/network
etc/config/network.save
etc/config/system
etc/config/ubootenv
etc/config/wireless
etc/crontabs/root
etc/dropbear/authorized_keys
etc/dropbear/dropbear_rsa_host_key
etc/group
etc/hosts
etc/inittab
etc/opkg/keys/0b26f36ae0f4106d
etc/opkg/keys/1035ac73cc4e59e3
etc/opkg/keys/5151f69420c3f508
etc/opkg/keys/72a57f2191b211e0
etc/opkg/keys/792d9d9b39f180dc
etc/opkg/keys/99db1e0996685023
etc/opkg/keys/9ef4694208102c43
etc/opkg/keys/b26f36ae0f4106d
etc/opkg/keys/b2d571e0880ff617
etc/opkg/keys/b5043e70f9a75cde
etc/opkg/keys/b72aa96b291719cc
etc/opkg/keys/c10b9afab19ee428
etc/opkg/keys/dace9d4df16896bf
etc/opkg/keys/dd6de0d06bbd3d85
etc/opkg/keys/f94b9dd6febac963
etc/passwd
etc/profile
etc/rc.local
etc/shadow
etc/shells
etc/sysctl.conf
Commencing upgrade. Closing all shell sessions.
Connection to unifiac2 closed by remote host.
Connection to unifiac2 closed.
There isn't anything out of the ordinary in my configs AFAIK. The "main"
ethernet port is connected to an unmanaged media converter, using 3
tagged VLANs for AP management and two wlan bridges. The second ethernet
port is not connected. I've tried accessing 192.168.1.1 untagged, in
case the network config somehow reverted to default, but there wasn't
anything responding to arps there either.
Do you have any suggestions as to what could have gone wrong? It would
help to know if I should have expected some changes to the network
config - I can work with that. Also useful to know if there is a flash
related issue or some crash to be expected.
And no need to worry about me - I'm writing this FYI in case you want to
delay broadening the 5.4 testing.
only. I am pretty sure I can revive the AP by temporarily reverting to
vendor firmware using bootloader tftp. And then reinstall a known
working OpenWrt image. But this will obviously prevent any further
debugging, so I'll hold on for a while before doing that.
Bjørn
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
