* Re: [RAUC] Question about updating using Casync in RAUC v1.8
[not found] ` <OS9PR01MB140764AE9F1C1693E3AD1AE6DF550A@OS9PR01MB14076.jpnprd01.prod.outlook.com>
@ 2025-07-24 7:23 ` Jan Lübbe via RAUC
0 siblings, 0 replies; 2+ messages in thread
From: Jan Lübbe via RAUC @ 2025-07-24 7:23 UTC (permalink / raw)
To: 大原 匠汰, Enrico Jörns; +Cc: rauc
On Fri, 2025-07-18 at 08:13 +0000, 大原 匠汰 via RAUC wrote:
> Hi Enrico,
> Thank you for your reply the other day.
>
> > Note that this version of RAUC is already 3 years old and should probably
> > not be used for new
> > developments.
>
> I appreciate your advice.
>
> > The casync seed store is internally realized using symlinks with storage
> > locations encoded.
> > After seeding, when actually reading a chunk from the store, this should be
> > hashed and compared
> > again and produce an error internally if the underlying data changed. This
> > should lead to ignoring
> > this seed chunk and to download the chunk from the (remote) chunk store
> > instead.
> >
> > So, yes, in general the seed slot should be read-only.
> > But it should also work if some of the data gets corrupted between seeding
> > and writing.
>
> Thank you for your answer about Casync.
> I will refer to the fact that there is no major problem without ReadOnly.
>
> I have another question today.
> Is there a mechanism to verify that the bundle was written correctly from the
> time the update is started until it is rebooted?
> I now understand the update process as follows:
>
> 1. Start the installation process.
> 2. Verify that the bundle file is correct.
> 3. Bundle file is written to the non-initial surface.
> 4. The installation process is completed.
> 5. Restart the system.
> 6. If the system starts correctly, it is successful.
>
> I would like to know if there is a way to verify that the file was written
> correctly between 3. and 5.
RAUC itself doesn't perform any read-back after writing the image, as you need
to rely on properly working IO anyway for any other writes to your storage (e.g.
configuration data). For example eMMCs have CRC protection on the interface and
ECC for storage, so the return value of write/sync system calls can normally be
trusted.
If you need more integrity protection, it's usually better to use dm-verity
below your filesystem(s), as this also allows you to detect modifications at any
time after the installation.
Alternatively, it you specifically need verification in RAUC before triggering
the reboot, we can implement and upstream that as commercial support
(https://rauc.io/pages/support.html). Or you could submit it as a PR.
Regards,
Jan
> Thank you in advance.
>
> Regards,
> Ohara
> --------------------------------
> OSAKA NDS Co.,Ltd.
> Ohara Shota
> e-mail: shota.ohara@nds-osk.co.jp
> --------------------------------
> 差出人: Enrico Jörns <ejo@pengutronix.de>
> 送信日時: 2025年7月2日 16:28
> 宛先: 大原 匠汰 <shota.ohara@nds-osk.co.jp>; rauc@pengutronix.de
> <rauc@pengutronix.de>
> 件名: Re: [RAUC] Question about updating using Casync in RAUC v1.8
>
> Hi Ohara,
>
> Am Mittwoch, dem 02.07.2025 um 02:28 +0000 schrieb 大原 匠汰 via RAUC:
> > Hi,
> > I have a question about updating using Casync in RAUC v1.8.
>
> Note that this version of RAUC is already 3 years old and should probably not
> be used for new
> developments.
>
> > 1. The documentation says that when updating using Casync,
> > the current SLOT in the boot is used as the seed and the differences are
> > downloaded.
> > https://rauc.readthedocs.io/en/v1.8/advanced.html#rauc-casync-support
> > If this is the case, will rewriting the current SLOT during the update cause
> > problems?
>
> What's the use case for rewriting the current slot?
> In most cases, this should be the slot the system is currently booted from.
>
> > 2.If so, is it necessary to set the SLOT to ReadOnly?
>
> The casync seed store is internally realized using symlinks with storage
> locations encoded.
> After seeding, when actually reading a chunk from the store, this should be
> hashed and compared
> again and produce an error internally if the underlying data changed. This
> should lead to ignoring
> this seed chunk and to download the chunk from the (remote) chunk store
> instead.
>
> So, yes, in general the seed slot should be read-only.
> But it should also work if some of the data gets corrupted between seeding and
> writing.
>
> Further details on this are probably more a casync-related question.
>
>
> Regards, Enrico
>
> > 3.If not, or if it is not necessary to set ReadOnly, please tell us why.
> >
> > That is all.
> >
> > Regards,
> > Ohara
> > --------------------------------
> > OSAKA NDS Co.,Ltd.
> > Ohara Shota
> > e-mail: shota.ohara@nds-osk.co.jp
> > --------------------------------
> >
>
--
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 |
^ permalink raw reply [flat|nested] 2+ messages in thread