On 03.05.19 19:05, Petr Štetiar wrote:
Klaus Kudielka <klaus.kudie...@gmail.com> [2019-04-24 21:14:38]:
Hi Klaus,
Remove workarounds for the old, inconsistent behaviour from the following
targets: apm821xx, brcm2708, omap, sunxi.
I'm willing to push the fix for mvebu (which the patch series is about), so
please don't touch other targets. This should go into separate patch(es) and
in order to push it, I would need some Tested-by, Reviewed-by or Acked-by for
every platform separately.
Petr, do I understand correctly, I should split this single patch into
the common.sh one, and four additional ones (one per target)?
--
Let me remind you that the common one *alone* breaks sysupgrade for those
four targets, as Tomasz already pointed out earlier.
In more detail:
The root of the problem is that the *existing* export_bootdevice in
/lib/upgrade/common.sh behaves differently, if the kernel is booted with
root=/dev/..., or if it is booted with root=PARTUUID=...
In the former case, it reports back major/minor of the root partition,
in the latter case it reports back major/minor of the complete boot disk.
The targets mentioned above have added workarounds to this behaviour, by
specifying *negative* increments to the export_partdevice function.
And then came the mvebu target to use export_bootdevice /
export_partdevice as well. Now, different subtargets boot differently,
and the workaround would be even more complex.
I think now is the time to make export_bootdevice behave consistently,
and to report major/minor of the boot disk, period.
Consequently, those targets, which boot with root=/dev/... *and* use
export_bootdevice / export_partdevice, have to be adapted to use
positive increments, otherwise they are broken by the change
to export_bootdevice.
The targets affected were easy to spot with find & grep.
Fixes: 4e8345ff68 ("mvebu: base-files: autodetect upgrade device")
Signed-off-by: Klaus Kudielka <klaus.kudie...@gmail.com>
Acked-by: Tomasz Maciej Nowak <tome...@o2.pl>
Tomasz, you seem pretty confident about this changes, how is that? :-)
-- ynezz
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
