Mechanism for finding active partition

[Aditya Purohit]

Hi Stefano,

I am using Swupdate with Hawkbit integration. While creating the update bundle, in my sw-description file, I have to mention the name of the device name e.g /dev/mmcblk0pX while sending the update images. This is causing a problem as in A/B approach, I cannot tell which is the active partition on my device right now and which partition the update must be installed.

Does / Will Swupdate provide a mechanism wherein I can simply give a tag eg root, application etc. and Swupdate will check for the active partition and automatically install the update image to the inactive partition.

P.S. : This feature would be useful for group updates using hawkbit wherein the same update bundle can be used for all devices.

--

Thanks

Aditya Purohit

[Diego Rondini]

Hi Aditya,

On Mon, Oct 16, 2017 at 9:36 AM, Aditya Purohit
<adityapur...@gmail.com> wrote:
> Hi Stefano,
> I am using Swupdate with Hawkbit integration. While creating the update
> bundle, in my sw-description file, I have to mention the name of the device
> name e.g /dev/mmcblk0pX while sending the update images. This is causing a
> problem as in A/B approach, I cannot tell which is the active partition on
> my device right now and which partition the update must be installed.

See the "-e" option of SWUpdate:
https://sbabic.github.io/swupdate/swupdate.html#configuring-swupdate

Another alternative option is:
1. specify a non-existent device name in the update file, like "/dev/root"
2. in the preinst script identify you current passive partition, and
create a link to it called "/dev/root". For example "ln -s
/dev/mmcblk0pX /dev/root"
3. in the postinst script remove the link

You can find an example of this technique used by Gary Bisson here:
https://boundarydevices.com/using-swupdate-upgrade-system/
https://storage.googleapis.com/boundarydevices.com/swupdate/update.sh

>
> Does / Will Swupdate provide a mechanism wherein I can simply give a tag eg
> root, application etc. and Swupdate will check for the active partition and
> automatically install the update image to the inactive partition.
>
> P.S. : This feature would be useful for group updates using hawkbit wherein
> the same update bundle can be used for all devices.
>

I too feel sometimes specifying device name is limiting, for example
when using the same image for eMMC or microSD.
Maybe using Persistent device naming:
https://wiki.archlinux.org/index.php/Persistent_block_device_naming
could give some help / provide additional options. Unfortunately it
requires udev (not to take as a given in small ramdisks). Additionally
it would not solve the problem for the files handler as the mount
command line tool support using e.g. labels, but the C call doesn't.

Bests,
Diego Rondini
Sr. Embedded Engineer

Kynetics
www.kynetics.com

[Diego Rondini]

On Mon, Oct 16, 2017 at 11:25 AM, Diego Rondini
<diego....@kynetics.com> wrote:
> <snip>

>
> See the "-e" option of SWUpdate:
> https://sbabic.github.io/swupdate/swupdate.html#configuring-swupdate
>

Sorry, should have been:
https://sbabic.github.io/swupdate/swupdate.html#command-line-parameters

> <snip>

[ali...@peloton-tech.com]

On Monday, October 16, 2017 at 12:36:04 AM UTC-7, Aditya Purohit wrote:

[ . .  .]

Does / Will Swupdate provide a mechanism wherein I can simply give a tag eg root, application etc. and Swupdate will check for the active partition and automatically install the update image to the inactive partition.

We solved this problem by reading the active partition from the kernel cmdline in another application and then programmatically passing in the right partition string as an argument when invoking swupdate.   /bin/findmnt will, for example, return the currently booted partition.   In order for this scheme to work, the downloaded SWU file must contain a sw-description manifest that lists each image twice, once for each possible partition on which it might be installed.   In other words, if your sw-description file lists 'KernelA' and 'KernelB' for the same kernel update, but with two different device paths, then a shell script that starts swupdate after reading the output of 'findmnt' can perform the desired action.

Hope this helps,
Alison Chaiken
Peloton Technology

[Christian Storm]

Hi,

> > [...]

> >
> > Does / Will Swupdate provide a mechanism wherein I can simply give a tag
> > eg root, application etc. and Swupdate will check for the active partition
> > and automatically install the update image to the inactive partition.
> >
>
> We solved this problem by reading the active partition from the kernel
> cmdline in another application and then programmatically passing in the
> right partition string as an argument when invoking swupdate.
> /bin/findmnt will, for example, return the currently booted partition. In
> order for this scheme to work, the downloaded SWU file must contain a
> sw-description manifest that lists each image twice, once for each possible
> partition on which it might be installed. In other words, if your
> sw-description file lists 'KernelA' and 'KernelB' for the same kernel
> update, but with two different device paths, then a shell script that
> starts swupdate after reading the output of 'findmnt' can perform the
> desired action.

Another solution is to solve this programmatically from within SWUpdate
without the need for external input/helpers by using Lua hooks like the
following:
```
software =
{
version = "0.0.1";
images: (
{
filename = "dummy.root";
device = "/dev/mmcblk0p3";
compressed = false;
hook = "deviceswitch";
}
);
embedded-script = "
function deviceswitch(image)
<find out what device to flash>
image['device'] = <found_device>
end";
}
```
Within the Lua function deviceswitch you're free to use the power of Lua
(or LuaJIT for that matter if you need FFI) to find the partition to
flash to. Implementing, e.g., a round-robin flashing scheme becomes
quite easy this way.


Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany

[Stefano Babic]

Hi,

Both mechanisms are fully correct - I know from someone else that they
implemented a further mechanism, resolving rootfs and providing a link
into /dev for it. Something like "/dev/update" ==> correct device, and
then using /dev/update in sw-description. This is not my preferred way,
but it is also possible and I write down for completeness.

Personally, I use often the way proposed by Alison, passing the
selection (-e ) when I start SWUpdate. But it is just for historical
reasons, embedded script in sw-description is quite recent in SWUpdate.

Best regards,
Stefano Babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================