From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 24 Jul 2025 09:24:06 +0200 Received: from metis.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::104]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1ueqJC-003Ahi-2S for lore@lore.pengutronix.de; Thu, 24 Jul 2025 09:24:06 +0200 Received: from localhost ([127.0.0.1] helo=metis.whiteo.stw.pengutronix.de) by metis.whiteo.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1ueqJC-0002Nn-Er; Thu, 24 Jul 2025 09:24:06 +0200 Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ueqIz-0002Mw-JE; Thu, 24 Jul 2025 09:23:53 +0200 Received: from ptz.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::77]) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1ueqIy-00A17z-1o; Thu, 24 Jul 2025 09:23:52 +0200 Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by ptz.office.stw.pengutronix.de with esmtp (Exim 4.96) (envelope-from ) id 1ueqIy-00DTwf-15; Thu, 24 Jul 2025 09:23:52 +0200 Message-ID: To: =?UTF-8?Q?=E5=A4=A7=E5=8E=9F_=E5=8C=A0=E6=B1=B0?= , Enrico =?ISO-8859-1?Q?J=F6rns?= Date: Thu, 24 Jul 2025 09:23:52 +0200 In-Reply-To: References: <6f35f8dd0d528d2addf4f46d4ba702f3b73a00de.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 Subject: Re: [RAUC] Question about updating using Casync in RAUC v1.8 X-BeenThere: rauc@pengutronix.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: RAUC Project - Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: =?utf-8?q?Jan_L=C3=BCbbe_via_RAUC?= Reply-To: Jan =?ISO-8859-1?Q?L=FCbbe?= Cc: "rauc@pengutronix.de" Sender: "RAUC" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: rauc-bounces@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false On Fri, 2025-07-18 at 08:13 +0000, =E5=A4=A7=E5=8E=9F =E5=8C=A0=E6=B1=B0 vi= a RAUC wrote: > Hi Enrico, > Thank you for your reply the other day. >=20 > > Note that this version of RAUC is already 3 years old and should probab= ly > > not be used for new > > developments. >=20 > I appreciate your advice. >=20 > > The casync seed store is internally realized using symlinks with storag= e > > locations encoded. > > After seeding, when actually reading a chunk from the store, this shoul= d be > > hashed and compared > > again and produce an error internally if the underlying data changed. T= his > > should lead to ignoring > > this seed chunk and to download the chunk from the (remote) chunk store > > instead. > >=20 > > So, yes, in general the seed slot should be read-only. > > But it should also work if some of the data gets corrupted between seed= ing > > and writing. >=20 > Thank you for your answer about Casync. > I will refer to the fact that there is no major problem without ReadOnly. >=20 > 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: >=20 > 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. >=20 > I would like to know if there is a way to verify that the file was writte= n > correctly between 3. and 5. RAUC itself doesn't perform any read-back after writing the image, as you n= eed 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 normall= y 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 a= t any time after the installation. Alternatively, it you specifically need verification in RAUC before trigger= ing 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. >=20 > Regards, > =E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82Ohara > -------------------------------- > OSAKA NDS Co.,Ltd. > Ohara Shota > e-mail: shota.ohara@nds-osk.co.jp > -------------------------------- > =E5=B7=AE=E5=87=BA=E4=BA=BA: Enrico J=C3=B6rns > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2025=E5=B9=B47=E6=9C=882=E6=97=A5 1= 6:28 > =E5=AE=9B=E5=85=88: =E5=A4=A7=E5=8E=9F =E5=8C=A0=E6=B1=B0 ; rauc@pengutronix.de > > =E4=BB=B6=E5=90=8D: Re: [RAUC] Question about updating using Casync in RA= UC v1.8 > =C2=A0 > Hi Ohara, >=20 > Am Mittwoch, dem 02.07.2025 um 02:28 +0000 schrieb =E5=A4=A7=E5=8E=9F =E5= =8C=A0=E6=B1=B0 via RAUC: > > Hi, > > I have a question about updating using Casync in RAUC v1.8. >=20 > Note that this version of RAUC is already 3 years old and should probably= not > be used for new > developments. >=20 > > 1. The documentation says that when updating using Casync, > > the current SLOT in the boot is used as the seed and the differences ar= e > > downloaded. > > https://rauc.readthedocs.io/en/v1.8/advanced.html#rauc-casync-support= =C2=A0 > > If this is the case, will rewriting the current SLOT during the update = cause > > problems? >=20 > What's the use case for rewriting the current slot? > In most cases, this should be the slot the system is currently booted fro= m. >=20 > > 2.If so, is it necessary to set the SLOT to ReadOnly? >=20 > 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. Thi= s > should lead to ignoring > this seed chunk and to download the chunk from the (remote) chunk store > instead. >=20 > So, yes, in general the seed slot should be read-only. > But it should also work if some of the data gets corrupted between seedin= g and > writing. >=20 > Further details on this are probably more a casync-related question. >=20 >=20 > Regards, Enrico >=20 > > 3.If not, or if it is not necessary to set ReadOnly, please tell us why= . > >=20 > > That is all. > >=20 > > Regards, > > =E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82Ohara > > -------------------------------- > > OSAKA NDS Co.,Ltd. > > Ohara Shota > > e-mail: shota.ohara@nds-osk.co.jp > > -------------------------------- > >=20 >=20 --=20 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 |