Skip to content
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

Jump to bottom

FS#662 - Sysupgrade messes up Ubiquiti Unifi AP AC Lite #6561

Closed
openwrt-bot opened this issue Mar 28, 2017 · 4 comments
Closed

FS#662 - Sysupgrade messes up Ubiquiti Unifi AP AC Lite #6561

openwrt-bot opened this issue Mar 28, 2017 · 4 comments
Labels
flyspray

Comments

@openwrt-bot
Copy link

rogerpueyo:

=====Problem description=====
Performing a sysupgrade on a Ubiquiti Unifi AP AC Lite causes the device to operate erratically as, on reboot, it keeps the previous kernel while using the newly flashed rootfs.

====Possible cause====
This problem might be related to the way LEDE/OpenWrt must be flashed from the stock firmware, as detailed in [[https://wiki.openwrt.org/toh/ubiquiti/unifiac#unifi_ap_ac_lite_devices|OpenWrt's wiki]]. Flashing the image to kernel0 or kernel1 does not work; both partitions must be flashed with the same image.

====Steps to reproduce it====

  • Revert to stock firmware (e.g. via Ubiquiti's TFTP recovery procedure)
  • Flash LEDE image (e.g. 17.01.0 stable) from stock firmware as described in [[https://wiki.openwrt.org/toh/ubiquiti/unifiac#unifi_ap_ac_lite_devices|OpenWrt's wiki]] (writing both to kernel0 and kernel1 partitions)
  • On reboot, check kernel version (dmesg | head -n1)
  • Sysupgrade to LEDE snapshot (sysupgrade -v -n lede-ar71xx-generic...)
  • Check kernel version again (dmesg | head -n1)

Both kernel versions will be the same. Actually, it's the same kernel, only the rootfs has been upgraded.

======Suggestions======
It seems Ubiquiti's bootloader implements some mechanism to fallback to an older firmware/kernel/rootfs/image/whatever, or maybe the partitioning scheme has been updated in the stock firmware.

If instead of running sysupgrade, the LEDE image is dd'ed to both the "firmware" (mtd2) and the "ubnt-airos" (mtd6) partitions (mtd write /tmp/lede-ar71xx...lite.bin firmware && mtd -r write /tmp/lede-ar71xx...lite.bin ubnt-airos), the new image is booted (including the new kernel). However, the "ubnt-airos" partition is read-only so a LEDE image having this partition set to rw must be first compiled and flashed from the stock firmware.
@openwrt-bot
Copy link
Author

bmork:

I believe this is exactly the same issue I had with my Ubiquiti Unifi AP AC PRO. See the forum thread at https://forum.lede-project.org/t/solved-ubnt-unifi-ac-pro-partition-problems-kernel0-vs-kernel1/1944

I believe there are 3 minor issues that should be fixed here:

  • LEDE images should make both firmware partitions writeable by default, as well as the "bs" partition
  • Initial installation instructions should describe the "bs" partition and provide a way to make sure it points to the firmware partition where LEDE is installed (which must be "kernel0" with the current images)
  • the sysupgrade script should verify the "bs" partition content, making sure that the newly installed image is used on the next boot

The first point is currently the most critical, as any device booting LEDE from "kernel1" is currently impossible to upgrade without using the mtd_rw trick/hack or a serial console.

@openwrt-bot
Copy link
Author

rotanid:

this issue also affects sysupgrades on similar devices like Unifi AC Mesh and Unifi AC Mesh Pro. (AC Mesh is similar to Unifi AP AC Lite and AC Mesh Pro similar to AP AC Pro)
there's also a downstream issue at the Gluon project: freifunk-gluon/gluon#1301

@openwrt-bot
Copy link
Author

hexa-:

bs partition was made writable in lede-project/source@f17173f.

Check which partition is labeled with "bs".

Then use dd if=/dev/zero bs=1 count=1 of=/dev/mtdN (replace N with partition number) and your device is going to boot from kernel0.

@openwrt-bot
Copy link
Author

vpont:

I'm sorry to bring back this topic but I've found myself in this exact situation after updating [[https://forum.openwrt.org/t/upgraded-from-18-06-1-to-18-06-2-no-wifi/30648|from 18.06.1 to 18.06.2]] and I don't really know how to proceed.

I'm on 18.06.2 filesystem with the 18.06.1 kernel.

Would the command dd if=/dev/zero bs=1 count=1 of=/dev/mtd7 force booting the newer kernel?

Thank you in advance!

Update: Yes, that command forced booting from the new kernel.

@dzzinstant dzzinstant mentioned this issue Apr 13, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@openwrt-bot