On 04.05.19 16:51, Christian Lamparter wrote:
On Friday, May 3, 2019 9:38:46 PM CEST Petr Štetiar wrote:
Klaus Kudielka <klaus.kudie...@gmail.com> [2019-05-03 20:16:39]:
Let me remind you that the common one *alone* breaks sysupgrade for those
four targets, as Tomasz already pointed out earlier.
Well, how could I know what was wrong with v1 if you didn't included the
changes between v1 -> v2 in your v2 patch :-)
Anyway, thanks for the explanation, it wasn't that much clear to me from the
commit message, so if you don't mind, I'll include the details there as well
in order to help it better understand to other folks.
Merged into my staging tree
https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=195178f88ee7b3815f9bea66a2454ccfdf2135a5
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.
Just a note here:
The export_bootdevice with it's PARTUUID-02 / sd[a-z]2 handling is not that
great. Ideally the fixed partition should be avoided altogether in favour of
a unique filesystem label or (less ideal) a filesystem UUID.
Trouble is that squashfs does not support either. So that's where the fixed
PARTUUID and sdX/mmcX device names come into play because otherwise the devices
wouldn't boot. Sadly I think changes like this will probably go on until
either squashfs gets these metadata image features or something replaces
squashfs that has it.
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.
True, it would have been great if the commit message included that
export_bootdevice now consistenly works on those devices when the
root= in the cmdline matches that PARTUUID-02, sd[a-z]2 or mmcblk[0-9]p2
and nothing else.
Because there are still a few devices (I think Gemini DIR-685, DIR-313
and SQ201, and a Kirkwood GoFlex Home) that have the root= on sda1 or
sda4 and could be converted to use the export_bootdevice for sysupgrade.
But as of yet, I don't see that any of these devices have sysupgrade support.
So your proposed patch is fine, unless you want to come up with a solution
that can deal with the odd-balls.. Because that would be awesome!
Well, the primary goal of this patch was (and still is) to fix sysupgrade
for Turris Omnia, without inventing yet another workaround for the rather
schizophrenic behaviour.
Personally I would prepare for potential future use cases in a separate
patch. To deal with non-standard partition layouts, it could be as simple
as replacing the trailing "2" with "[1-4]" in the six patterns of the
$rootpart case statement... if this is what you mean?
Regards, Klaus
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
