NeoRaider:

Similar report: freifunk-gluon/gluon#1010

Occording to remote debugging I did via IRC a few weeks ago (sorry for not reporthing this here earlier), the cause of this issue seems to be a change in the partition layout.

It seems the sda1 (boot) partition grows, but the kernel can't update its partition definitions (a call to partx added to platform_do_upgrade() will fail), as the new sda1 overlaps with the old sda2 (root), which is still mounted during sysupgrade. This will make the sda1 mount fail, so sysupgrade.tgz can't be written.

I don't think there is an easy way to make sda2 unmountable during sysupgrade? So maybe we must find a different place to store the sysupgrade files...

NeoRaider:

I have some working code in my staging tree at https://git.lede-project.org/?p=lede/neoraider/staging.git;a=shortlog;h=refs/heads/sysupgrade now that changes sysupgrade to use the staged sysupgrade mechanism on all targets. I have verified that it works correctly on ar71xx, x86 and ramips (nand); it will need more testing, but it should work on the other targets, too.

On top of the sysupgrade changes, which don't touch target-specific code at all, the branch also contains the following:

• The call to the NAND sysupgrade code is simplified on ramips (a similar change should be done in all NAND targets eventually, so we can get rid of a few hacks in sysupgrade)
• partx calls are added to the x86 sysupgrade to make the partition table updates more robust. This should be done on all targets using harddisk-like storage with partition tables.

TODO:

• Re-add some missing features to sysupgrade (e.g. support for image download via HTTP)
• Add more sanity checks (ensure that the image is in /tmp, that the rootfs has been unmounted, ...)

I will also backport my work to OpenWrt CC and verify that it really fixes this issue, as we need working sysupgrade from CC to LEDE in Gluon.