[OpenWrt-Devel] [PATCH v2 1/2] base-files: improve lib/upgrade/common.sh

[Christian Lamparter]

On Friday, May 3, 2019 9:38:46 PM CEST Petr Štetiar wrote:
> Klaus Kudielka <klaus.kudielka at 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! 

Cheers,
Christian



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel