| Message ID | 20240111200015.190376-8-Quirin.Gylstorff@siemens.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Add Bootloader to sw-description | expand |
Am Donnerstag, dem 11.01.2024 um 20:59 +0100 schrieb Quirin Gylstorff: > From: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> > --- > doc/README.swupdate.md | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md > index 00359c7..1c94699 100644 > --- a/doc/README.swupdate.md > +++ b/doc/README.swupdate.md > @@ -7,6 +7,19 @@ Start with cloning the isar-cip-core repository: > ``` > host$ git clone > https://gitlab.com/cip-project/cip-core/isar-cip-core.git > ``` > +## SWUpdate Efibootguard update > + > +:warning: **If the efibootguard binary is corrupted the system can > no longer boot** > + > +If you build a CIP Core image with SWUpdate support an additional > swu will -----^ ... swu file will be generated > +be generated. This swu ends on `*-ebg.swu` and contains a sw- > description to > +update only efibootguard. SWUpdate will copy the file to a temporary > location Does this mean, the -ebg.swu is always generated and only contains the update of the ebg loader? Only if the variable SWU_EBG_UPDATE=1 is set, the ebg update is included in the "normal" swu that also updates the kernel and the rootfs? > +and rename the binary in place to reduce the time the system can be > destroyed > +by a power failure. As FAT partitions have **no** atomic operations FAT partitions do not support an atomic file replace. The atomic file creation is supported, AFAIK. Best regards, Felix > a small error > +window is still possible. > + > +If the variable `SWU_EBG_UPDATE` is set to `"1"` the update is also > stored in > +the `*.swu` file. > > # Building and testing the CIP Core image >
On 1/12/24 15:12, Moessbauer, Felix (T CED OES-DE) wrote: > Am Donnerstag, dem 11.01.2024 um 20:59 +0100 schrieb Quirin Gylstorff: >> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> >> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> --- >> doc/README.swupdate.md | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md >> index 00359c7..1c94699 100644 >> --- a/doc/README.swupdate.md >> +++ b/doc/README.swupdate.md >> @@ -7,6 +7,19 @@ Start with cloning the isar-cip-core repository: >> ``` >> host$ git clone >> https://gitlab.com/cip-project/cip-core/isar-cip-core.git >> ``` >> +## SWUpdate Efibootguard update >> + >> +:warning: **If the efibootguard binary is corrupted the system can >> no longer boot** >> + >> +If you build a CIP Core image with SWUpdate support an additional >> swu will > -----^ ... swu file will be generated > >> +be generated. This swu ends on `*-ebg.swu` and contains a sw- >> description to >> +update only efibootguard. SWUpdate will copy the file to a temporary >> location > > Does this mean, the -ebg.swu is always generated and only contains the > update of the ebg loader? Only if the variable SWU_EBG_UPDATE=1 is set, > the ebg update is included in the "normal" swu that also updates the > kernel and the rootfs? Yes this is the current behavior. > >> +and rename the binary in place to reduce the time the system can be >> destroyed >> +by a power failure. As FAT partitions have **no** atomic operations > > FAT partitions do not support an atomic file replace. The atomic file > creation is supported, AFAIK From [1] only the driver locks against dataraces: " But looking at vfat source code (file namei_vfat.c), both rename and lookup operation are locked by mutex, so during rename operation there should not be access to read directory and therefore race condition should not be there (which would cause reading inconsistent directory during rename operation). If you want atomic rename of two files independently of filesystem, you can use RENAME_EXCHANGE flag. It exchanges that two specified files atomically, so there would not be that race condition like in rename() that in some period of time both "foo" and "bar" would point to same inode. But... if you are asking for consistency and atomicity at filesystem level (e.g. you turn off disk / power supply during rename operation) then this is not atomic and probably it cannot be implemented. When FAT filesystem is mounted (either by Windows or Linux kernel) it is marked by "dirty" flag and later when doing unmount, "dirty" flag is cleared. This is there to ensure that operations like rename were finished and were not stopped/killed in between. So future when you read from FAT filesystem you would know if it is in consistent state or not. " [1]: https://lore.kernel.org/linux-fsdevel/20191022105413.pj6i3ydetnfgnkzh@pali/ Quirin > > Best regards, > Felix > >> a small error >> +window is still possible. >> + >> +If the variable `SWU_EBG_UPDATE` is set to `"1"` the update is also >> stored in >> +the `*.swu` file. >> >> # Building and testing the CIP Core image >> >
diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md index 00359c7..1c94699 100644 --- a/doc/README.swupdate.md +++ b/doc/README.swupdate.md @@ -7,6 +7,19 @@ Start with cloning the isar-cip-core repository: ``` host$ git clone https://gitlab.com/cip-project/cip-core/isar-cip-core.git ``` +## SWUpdate Efibootguard update + +:warning: **If the efibootguard binary is corrupted the system can no longer boot** + +If you build a CIP Core image with SWUpdate support an additional swu will +be generated. This swu ends on `*-ebg.swu` and contains a sw-description to +update only efibootguard. SWUpdate will copy the file to a temporary location +and rename the binary in place to reduce the time the system can be destroyed +by a power failure. As FAT partitions have **no** atomic operations a small error +window is still possible. + +If the variable `SWU_EBG_UPDATE` is set to `"1"` the update is also stored in +the `*.swu` file. # Building and testing the CIP Core image