[RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed?

[RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed?

[Brian Hutchinson via RAUC]

Hi,

Since it's common to produce boards with pre-programmed flash etc., is
it possible to change the [system]compatible= string when hardware
changes happen and the compatible string needs to be updated when it
has already been set previously?

I know that hooks could be used to key in on bundle version
information to implement things like downgrade barriers etc., but it
just feels more elegant to update the compatible string to describe
hardware changes that are human readable than to keep up with a eye
chart truth table of version number combinations to determine what is
safe to downgrade, upgrade etc.

I was thinking if maybe [system]variant-file was used in system.conf,
then a pre-install hook could easily manipulate the compatible string,
but not sure that would work.

This almost feels like the intermediate update that's necessary with
changing rauc versions ... but I searched the mail archives and
couldn't find anyone wondering about this sort of thing so thought I'd
ask Jan, Enrico & Co. their thoughts.

Regards,

Brian

Re: [RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed?

[Jan Lübbe via RAUC]

On Thu, 2024-12-05 at 22:38 -0500, Brian Hutchinson via RAUC wrote:
> Hi,
> 
> Since it's common to produce boards with pre-programmed flash etc., is
> it possible to change the [system]compatible= string when hardware
> changes happen and the compatible string needs to be updated when it
> has already been set previously?
> 
> I know that hooks could be used to key in on bundle version
> information to implement things like downgrade barriers etc., but it
> just feels more elegant to update the compatible string to describe
> hardware changes that are human readable than to keep up with a eye
> chart truth table of version number combinations to determine what is
> safe to downgrade, upgrade etc.
> 
> I was thinking if maybe [system]variant-file was used in system.conf,
> then a pre-install hook could easily manipulate the compatible string,
> but not sure that would work.
> 
> This almost feels like the intermediate update that's necessary with
> changing rauc versions ... but I searched the mail archives and
> couldn't find anyone wondering about this sort of thing so thought I'd
> ask Jan, Enrico & Co. their thoughts.

You can use a 'install-check' hook [1] in the bundle to override the normal
compatible check. 

Also, the variant handling is built in a way so that you can start setting the
system variant in new systems that behave differently and you can target the
different images correctly.

Regards,
Jan

[1] https://rauc.readthedocs.io/en/latest/using.html#install-hooks

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed?

[Jan Lübbe via RAUC]

Hi again,

On Thu, 2024-12-05 at 22:38 -0500, Brian Hutchinson via RAUC wrote:
> This almost feels like the intermediate update that's necessary with
> changing rauc versions ...

Enrico pointed me to this part.

Updating RAUC versions normally does *not* require an intermediate
update. An intermediate update is only needed if you explicitly create
bundles which use new features:
https://rauc.readthedocs.io/en/latest/basic.html#forward-and-backward-compatibility

Regards,
Jan
-- 
Pengutronix e.K.                        |                             |
Steuerwalder Str. 21                    | https://www.pengutronix.de/ |
31137 Hildesheim, Germany               | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686        | Fax:   +49-5121-206917-5555 |

Re: [RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed?

[Brian Hutchinson via RAUC]

On Mon, Dec 9, 2024 at 3:43 AM Jan Lübbe <jlu@pengutronix.de> wrote:
>
> Hi again,
>
> On Thu, 2024-12-05 at 22:38 -0500, Brian Hutchinson via RAUC wrote:
> > This almost feels like the intermediate update that's necessary with
> > changing rauc versions ...
>
> Enrico pointed me to this part.
>
> Updating RAUC versions normally does *not* require an intermediate
> update. An intermediate update is only needed if you explicitly create
> bundles which use new features:
> https://rauc.readthedocs.io/en/latest/basic.html#forward-and-backward-compatibility

Thanks!

I should probably start another thread, but now I'm running into a
chicken & egg problem.

I need to add downgrade protection due to newer hardware and I
discovered pre-install handler doesn't have access to bundle version
(RAUC_MF_VERSION), only a hook has that environment variable.  Well,
if I create a hook that can compare bundle version to current version
to do some hardware checks ... that hook won't be in older bundles, so
wondering how pre-install handler (which lives in the current version
file system) can figure out the bundle version attempting to be
installed if it can't see RAUC_MF_VERSION to implement downgrade
protection if that makes any sense.

Regards,

Brian

Re: [RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed?

[Jan Lübbe via RAUC]

On Tue, 2025-01-14 at 10:38 -0500, Brian Hutchinson via RAUC wrote:
> On Mon, Dec 9, 2024 at 3:43 AM Jan Lübbe <jlu@pengutronix.de> wrote:
> > 
> > Hi again,
> > 
> > On Thu, 2024-12-05 at 22:38 -0500, Brian Hutchinson via RAUC wrote:
> > > This almost feels like the intermediate update that's necessary with
> > > changing rauc versions ...
> > 
> > Enrico pointed me to this part.
> > 
> > Updating RAUC versions normally does *not* require an intermediate
> > update. An intermediate update is only needed if you explicitly create
> > bundles which use new features:
> > https://rauc.readthedocs.io/en/latest/basic.html#forward-and-backward-compatibility
> 
> Thanks!
> 
> I should probably start another thread, but now I'm running into a
> chicken & egg problem.
> 
> I need to add downgrade protection due to newer hardware

Just to clarify: You want to prevent installation of an old bundle on the new
hardware, as the old software would not work on the new hardware?

> and I
> discovered pre-install handler doesn't have access to bundle version
> (RAUC_MF_VERSION), only a hook has that environment variable.  Well,
> if I create a hook that can compare bundle version to current version
> to do some hardware checks ... that hook won't be in older bundles, so
> wondering how pre-install handler (which lives in the current version
> file system) can figure out the bundle version attempting to be
> installed if it can't see RAUC_MF_VERSION to implement downgrade
> protection if that makes any sense.

Take a look at the "min-bundle-version" option in the system.conf:
https://rauc.readthedocs.io/en/latest/reference.html#system-section 

You'd set that in the factory image of your new hardware. That way, old bundles
cannot be installed.

Regards,
Jan
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed?

[Brian Hutchinson via RAUC]

Hey Jan,

On Tue, Jan 14, 2025 at 10:52 AM Jan Lübbe <jlu@pengutronix.de> wrote:
>
> On Tue, 2025-01-14 at 10:38 -0500, Brian Hutchinson via RAUC wrote:
> > On Mon, Dec 9, 2024 at 3:43 AM Jan Lübbe <jlu@pengutronix.de> wrote:
> > >
> > > Hi again,
> > >
> > > On Thu, 2024-12-05 at 22:38 -0500, Brian Hutchinson via RAUC wrote:
> > > > This almost feels like the intermediate update that's necessary with
> > > > changing rauc versions ...
> > >
> > > Enrico pointed me to this part.
> > >
> > > Updating RAUC versions normally does *not* require an intermediate
> > > update. An intermediate update is only needed if you explicitly create
> > > bundles which use new features:
> > > https://rauc.readthedocs.io/en/latest/basic.html#forward-and-backward-compatibility
> >
> > Thanks!
> >
> > I should probably start another thread, but now I'm running into a
> > chicken & egg problem.
> >
> > I need to add downgrade protection due to newer hardware
>
> Just to clarify: You want to prevent installation of an old bundle on the new
> hardware, as the old software would not work on the new hardware?

Yes, but not based on version alone, version and some hardware checks.

>
> > and I
> > discovered pre-install handler doesn't have access to bundle version
> > (RAUC_MF_VERSION), only a hook has that environment variable.  Well,
> > if I create a hook that can compare bundle version to current version
> > to do some hardware checks ... that hook won't be in older bundles, so
> > wondering how pre-install handler (which lives in the current version
> > file system) can figure out the bundle version attempting to be
> > installed if it can't see RAUC_MF_VERSION to implement downgrade
> > protection if that makes any sense.
>
> Take a look at the "min-bundle-version" option in the system.conf:
> https://rauc.readthedocs.io/en/latest/reference.html#system-section
>
> You'd set that in the factory image of your new hardware. That way, old bundles
> cannot be installed.

Yeah, looked at that and won't help me.  If pre-install handler can
get to the bundle version attempting to be installed I'd be ok.
Currently looking at RAUC_META_.  Looks like pre-install hook can
access the bundle manifest.

So I might allow a downgrade if the hardware is compatible, but if the
hardware is not compatible then I have to deny the downgrade.  So it's
got to be pre-install handler since that lives in current version
rootfs ... but I need to figure out how to access the version of
bundle attempting to be installed.  That's where I'm stuck.

Regards,

Brian

Re: [RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed?

[Brian Hutchinson via RAUC]

Hi,

On Tue, Jan 14, 2025 at 11:04 AM Brian Hutchinson <b.hutchman@gmail.com> wrote:
>
> Hey Jan,
>
> On Tue, Jan 14, 2025 at 10:52 AM Jan Lübbe <jlu@pengutronix.de> wrote:
> >
> > On Tue, 2025-01-14 at 10:38 -0500, Brian Hutchinson via RAUC wrote:
> > > On Mon, Dec 9, 2024 at 3:43 AM Jan Lübbe <jlu@pengutronix.de> wrote:
> > > >
> > > > Hi again,
> > > >
> > > > On Thu, 2024-12-05 at 22:38 -0500, Brian Hutchinson via RAUC wrote:
> > > > > This almost feels like the intermediate update that's necessary with
> > > > > changing rauc versions ...
> > > >
> > > > Enrico pointed me to this part.
> > > >
> > > > Updating RAUC versions normally does *not* require an intermediate
> > > > update. An intermediate update is only needed if you explicitly create
> > > > bundles which use new features:
> > > > https://rauc.readthedocs.io/en/latest/basic.html#forward-and-backward-compatibility
> > >
> > > Thanks!
> > >
> > > I should probably start another thread, but now I'm running into a
> > > chicken & egg problem.
> > >
> > > I need to add downgrade protection due to newer hardware
> >
> > Just to clarify: You want to prevent installation of an old bundle on the new
> > hardware, as the old software would not work on the new hardware?
>
> Yes, but not based on version alone, version and some hardware checks.
>
> >
> > > and I
> > > discovered pre-install handler doesn't have access to bundle version
> > > (RAUC_MF_VERSION), only a hook has that environment variable.  Well,
> > > if I create a hook that can compare bundle version to current version
> > > to do some hardware checks ... that hook won't be in older bundles, so
> > > wondering how pre-install handler (which lives in the current version
> > > file system) can figure out the bundle version attempting to be
> > > installed if it can't see RAUC_MF_VERSION to implement downgrade
> > > protection if that makes any sense.
> >
> > Take a look at the "min-bundle-version" option in the system.conf:
> > https://rauc.readthedocs.io/en/latest/reference.html#system-section
> >
> > You'd set that in the factory image of your new hardware. That way, old bundles
> > cannot be installed.
>
> Yeah, looked at that and won't help me.  If pre-install handler can
> get to the bundle version attempting to be installed I'd be ok.
> Currently looking at RAUC_META_.  Looks like pre-install hook can
> access the bundle manifest.
>
> So I might allow a downgrade if the hardware is compatible, but if the
> hardware is not compatible then I have to deny the downgrade.  So it's
> got to be pre-install handler since that lives in current version
> rootfs ... but I need to figure out how to access the version of
> bundle attempting to be installed.  That's where I'm stuck.

I made my pre-install handler get the rauc bundle version thru brute
force using $RAUC_BUNDLE_MOUNT_POINT/manifest.raucm.

If there's a more elegant way for a handler to get the bundle version
from bundle manifest, please let me know so I'm not a bull in a china
shop ;).

Regards,

Brian