Issue with sysupgrade when root is also mounted elsewhere

For Developers
1

For specific preposes I mount / into directory somewhere in /tmp/ without any special options. When I perform sysupgrade -n:

  • With older system 21.02 with root in ubi volume sysupgrade fails completely saying that volume is busy and not writing new image;
  • With newer system (~1 year old) it upgrades, but still complains that it can't delete volumes from the boot storage device.

Any idea how to cope with it? Is there any user (supruser) script sysupgrade runs where I can put FS unmount command? Or maybe I can mount / with specific options - I need it in read-only mode.

Edit: and by the way, I didn't get it with newer system: why it wants to repartition the boot device, it must only upgrade/touch its boot partition, why it wants to remove data partitions? I recall someone here told me that sysupgrade deliberately leaves other partitions on the same media alone so that users may save the data into there, but here I explicitly see it tries to do otherwise.

Edit: and yes, on newer system it really deletes data from data volume! Root FS is in eMMC p2, data is in p3, and p3 loses its contents after sysupgrade. However I use -n option to perform full image replacement, but why the device layout? Help for sysupgrade says '-n' for "do not save configuration over reflash", but what's the "configuration"?

Edit: on older system another ubi volume, which contains the data, is not removed during sysupgrade, and data stays intact.

So we have two problems: (1) issue with sysupgrade when root is mounted elsewhere, and (2) newer system loses its contents of the data volume.

Edit: well first problem is mentioned in the tech page for susupgrade

Easily broken by open files on storage devices (e.g., for swap, or explicitly opened), as these can prevent unmounting /overlay

probably there is a way to tun script on start of sysupgrade, maybe in platform.sh, but not sure.

2

Use -o bind mount option

3

I read several explanations on how bind mount works, and the current effect without -o bind seems to be the same explained when having this flag - if I just perform mount / /tmp/rootmount I can see all the contents of the root file system, including those shadowed by the mount points in the root e.g. /root/anothermnountpoint.
Therefore I am not sure if that I currently do is NOT resulting in a bind mount, or I did not get the purpose of the bind mount properly.

4

Just dont mount it, or perform sydupgrade in failsafe mode, openwrt can not cover all fafo cases users invent.

5

I do not ask for standard tool to cover all the cases. I am ready to make an effort and help it - and asking here for advice. I should do that mount because I will use that location, and the only exception for my case is when sysupgrade runs.

And the second question - can you help with that - what to tell to sysupgrade to NOT erase whole media with partition table and all volumes but just write new kernel to kernel volume and write new rootfs to the root volume? I can't figure out that from description of how it works.

6

Regarding the second issue: the root cause it located in the /lib/upgrade/platform.sh (platform_do_upgrade). The platform I use is NanoPi neo core. The script cleans the boot disk involved and tries to write everything from the upgrade file onto the boot disk in the set of partitions as laid out in the upgrade file. Thus I probably need to redesign this section of the script.

7

The problem seems to be even more complicated - I use minimal rootfs image to have minimal sysupgrade file to transfer, and after writing it I extend the rootfs and create another volume after it. Sysupgrade seems does not support this workflow - if new partition table differs, sysupgrade erases everything and makes volume per sysupgrade file layout. Who said that separate volume for data on the same storage media is a safe and viable solution?!

8

See

https://openwrt.org/docs/techref/flash.layout

The wiki article goes into some detail why sysupgrade does what it does. It needs to keep some data and move it around on some systems, it was clearly written in a general manner for simple flash memory. Some devices may be capable of more, but it's not designed for that.

The advice to run it from fallback seems sensible, since it is starting from a known point.

If you are worried about your own configs, why not just tar up the config directories (assuming the build in sysupgrade make a backup does not work in your case), copy them off and then copy them back?

9

Thanks everyone for the help. I decided to change the architecture, fortunately it is possible - to omit the original problem with mounted root fs.