Missing overlay partition, sysupgrade doesn't work (Ubiquiti UniFi-AC-PRO)

I am helping an organization upgrade their OpenWrt devices, they use a custom image, on some devices using a particular build they have the following situation:

$ mount

rootfs on / type rootfs (rw)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)

There's no overlay! Upgrading these via sysupgrade doesn't work.

This is the output I get on other devices using different builds which do work well with sysupgrade:

/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup on /sys/fs/cgroup type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct,blkio,memory,devices,freezer,net_cls,pids)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mtdblock5 on /overlay type jffs2 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)

My question is, apart from reflashing via serial console, which is very time consuming, is there any other option which we can execute remotely via SSH?

Thanks in advance!

even if this is some non commercial org, the answer would probably be

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

If anyone ever got into a situation like this and has any advice it would be appreciated, thanks.

Nobody here knows, what is the intended/normal partition structure and file systems for that unnamed device. Similarly, we have no information on the possible sysupgrade or other upgrade functionality that the firmware author has designed and placed there.

As partition structure, file systems and also the update method varies a lot between devices, there is no uniform way to do sysupgrade. If you look at the target sources in OpenWrt source repo, you can see the variation between targets.

(Your other device seems to have the common read-only /rom rootfs + read-write overlay. your problem device seems to have r/w rootfs, so completely different design. But actually the overlay itself does not play a role in sysupgrade...)

1 Like

@nemesis Is this an x86 device? They don't happen to be using ext4 images? Because the root is r/w by default there, unlike with SquashFS images. As pointed out before it would really help to know what exact type of hardware we are looking at (and if not x86, then the specific hardware).

Thanks for the information @Borromini @hnyman :pray:.

They've been around for some years and use to rely on Ubiquiti mostly, here's some more detailed info:

  • model: Ubiquiti UniFi-AC-PRO
  • build: OpenWrt 19.07.4 r11208-ce6496d796
  • soc: Qualcomm Atheros QCA956X ver 1 rev 0

I added the model to the title, so that people knowledgeable about that device might notice.

Based on the wiki page for that device, the installation might be somewhat complex but it should have sysupgrade, I think.

In 19.07 there have been both older ar71xx images and newer DTS based ath79 images for the device. The variant being installed might have impact.

ar71xx vs ath79 was my thought too. You can force a sysupgrade I think - but only while wiping your settings as well. So doing this remotely is a no-go probably.

I can force it remotely, but -n is not enough, should I use -p?

You should check from boot logs, how the mtd partitions are recognised, and what partitions are recognised. And what errors/warnings/info there are regarding overlay and mtd.

1 Like