Gluon: no sysupgrade on x86 using sdcard storage

[rotanid]

when using gluon on x86 devices booting from storage, that doesn't appear like /dev/[sh]d[a-z] or similar, sysupgrade is broken as it doesn't recognize the correct partition.

[rotanid]

fixed by 1f080744387a90dd325bdac9ef32875ba9f96bf3 in master branch

[Adorfer]

Will there be a backport to the 2016.2 release?
(otherwise we would have to build from master or go into the hell of cherrypicking. since we have several S900 futro with USB-Key/SD-reader.)

[rotanid]

did you just not try to update so far or did it work before?
this doesn't have to affect you, just look at the block devies name.
@NeoRaider said he will backport it after a while if there are no problems. i would also welcome this, as this doesn't look like an easy cherry-pick :D

EDIT:
@Adorfer please not that this fix won't help you for already deployed devices, you will probably have to re-flash them manually, not via ssh.

[Adorfer]

@rotanid From where you get your conclusion "fix will not help"? I understand that https://github.com/freifunk-gluon/gluon/commit/1f080744387a90dd325bdac9ef32875ba9f96bf3 would resolve the issue for new build firmware.

This is broken since when? (i am pretty muche sure that it was functional in 2016.1)

[rotanid]

@Adorfer it's possible that 2016.1 was working, but i don't know, as my device isn't working at all with 2016.1 - maybe @NeoRaider can tell you that.
the patches that were backported know went into openwrt in March 2016: https://git.lede-project.org/?p=source.git;a=history;f=target/linux/x86/base-files/lib/upgrade/platform.sh;h=c8bc3f7f608fc82ee3afc049b64af3a740fd2c37;hb=HEAD (the last 3 in this link)

regarding "will not help": i meant that if you have devices, where sysupgrade is broken because of this issue, you can't update via sysupgrade (and therefore of course autoupdater, too). a new build doesn't solve the problem in your already installed software, you will have to flash it some other way like tftp or "dd" to the sdcard.

[Adorfer]

@rotanid Regression-testing from canidate towards "virtual next candidate" is a best practise.
this has not been done yet and therefore the is not deployment of 2016.2 yet here.
So i assume, that my satement is corret, that i would need this backported (or to cherrypick) in order to deploy 2016.2.2.

[rotanid]

yes, even if the issue is already there in 2016.1, which i don't know, it is best to not deploy v2016.2.x without the fix.

[Adorfer]

@rotanid off course not.
But my reasoning was just to explain why i consider that this fix is "helping" for the routers deployed here.
and to make sure that i do not overlook a race condition, because you said, "this fix will not help me".

(under the assumption that without the fix a futro S900 "with sd reader" on current 2016.2.2release will be blocked from further autoupdate and that this fix is curing that)

[rotanid]

@NeoRaider it seems we forgot the backport - noticed that today on 2016.2.3 unfortunately :-(

[NeoRaider]

Backport to v2016.2.x done.

[rotanid]

zur Dokumentation hier noch der Verweis auf die relevanten commits:
https://github.com/freifunk-gluon/gluon/commit/41fd50d20ba31d73c4796c5b2d4eb44ad2258b90
https://github.com/freifunk-gluon/gluon/commit/ad37e2b6b43b2c3389356d892b04f3873d8f6b93