Sysupgrade not actually doing anything

For Developers
1

I'm working with a customized OpenWRT 18.06.1 build on some Ubiquity Bullet-M and Alfa Tube-2HP units. The firmware initially loaded OK, and at least one attempted update worked, but currently it seems that updates are simply not being written to Flash. If I have added files in places that aren't preserved by the "save config" option, they are still there after the reboot - and any new files in the firmware image are NOT there.

This happens with both the Luci update tab, and direct use of 'sysupgrade' over SSH. In the latter case, I'm getting an "Image metadata not found" message, but that doesn't seem to be stopping the update process (and 'sysupgrade -F' didn't work any better). This happens whether or not I choose the "save config" option.

I have added some large files to the image, but it's still only 6.1MB, which should easily fit on these units (especially the Tube, which has 16MB Flash).

Does anyone have any idea what could be going wrong here? How would I debug this?

2

Can you remove some of the files from your custom build; and see if the smaller image flashes then?

3

I removed the largest of my custom files, which got the image size down to 5.8MB - that's about what it was when I first built this OpenWRT version. The problem still occurs.

I'm going to try doing the 'sysupgrade' over the serial port - perhaps there's some error that's not showing up until after the network connection is killed, and therefore can't be seen via SSH.

1 Like
4

There used to be a bug a while back where sysupgrade was e.g. waiting for wireless to shut down and eventually gave up.

In case you were trying to upgrade over wireless, try doing so wired - or bring down wifi manually before calling sysupgrade, e.g.:

# /sbin/wifi down && sysupgrade /tmp/sysupgrade-file.img
5

Looks like I've got this fixed, finally. One of my customizations was to disable the serial console, for potential future use of the single serial port on these devices. (Which killed my idea of running 'sysupgrade' via the serial port to see what was going wrong, I was unable to re-enable the port with the limited utilities compiled into my image.) I had done this by making of a copy the target definitions in the appropriate makefiles, adding "-noconsole" to their names, and editing the console specification. It turns out that this isn't all you need to do to add a new target device; in particular, the second stage of 'sysupgrade' (after the network is killed) invokes /lib/upgrade/platform.sh, which checks the device name against a long list of known devices in order to choose how to actually write the firmware. And of course, my -noconsole devices are not on that list...

I reverted the changes to those makefiles (using the serial port for other things isn't an immediate requirement), rebuilt, forcibly installed this version via the device bootloaders, and 'sysupgrade' now seems to be working normally.

1 Like
6

sysupgrade -F /tmp/up.bin

7

I have a similar problem. when i perform upgrades. it cause occasional reboots(nothing changed)， i realize you maybe right. Is there any documentation of what you're talking about? And how can i verify it？

8

You can pass the -v switch to sysupgrade for increased verbosity, but once it kills the network (which is rather early in the process) you will need serial to get more info on what's going on after that.