OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version All
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Roger - 28.03.2017
Last edited by Mathias Kresin - 03.07.2018

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

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 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

  1. Revert to stock firmware (e.g. via Ubiquiti’s TFTP recovery procedure)
  2. Flash LEDE image (e.g. 17.01.0 stable) from stock firmware as described in OpenWrt's wiki (writing both to kernel0 and kernel1 partitions)
  3. On reboot, check kernel version (dmesg | head -n1)
  4. Sysupgrade to LEDE snapshot (sysupgrade -v -n lede-ar71xx-generic...)
  5. 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.

Closed by  Mathias Kresin
03.07.2018 20:18
Reason for closing:  Fixed
Additional comments about closing:  

https:/ /git.openwrt.org/f17173f5a36999f070a2ccb de2953d5d0d98001b

Bjørn Mork commented on 21.04.2017 14:59

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:

  1. LEDE images should make both firmware partitions writeable by default, as well as the "bs" partition
  2. 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)
  3. 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.

rotanid commented on 09.01.2018 02:50

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: https://github.com/freifunk-gluon/gluon/issues/1301

Martin Weinelt commented on 11.02.2018 17:24

`bs` partition was made writable in https://github.com/lede-project/source/commit/f17173f5a36999f070a2ccbde2953d5d0d98001b.

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.

Víctor Pont commented on 05.02.2019 15:09

I'm sorry to bring back this topic but I've found myself in this exact situation after updating 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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing