Skip to content

GitLab

Switch branch/tag
  1. 18 Oct, 2021 2 commits
  3. 17 Oct, 2021 2 commits
    • Zygmunt Krynicki's avatar
      .gitlab-ci.yml: make REUSE and DCO jobs independent · ea6f1fad
      Zygmunt Krynicki authored 
      

DCO makes sense only in a delta context, as it checks a range of patches
for valid DCO markers. REUSE can run at any instance. The jobs were
connected by the "needs" relation to make GitLab graphs nicer but this
had an unintended consequence - DCO doesn't run on a "branch" event
(such as push), which makes REUSE fail to start on missing dependency,
making the main branch fail CI.
Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      ea6f1fad
    • Zygmunt Krynicki's avatar
      boot/piboot: handle ErrPristineBootConfig in PreInstallHandler · c74371de
      Zygmunt Krynicki authored 
      Tests on early Oniro builds show that SystemOTA doesn't handle pristine
boot environment, where os_prefix= is unset and slot directories do not
exist.

One specific aspect is the PreInstallHandler which calls QueryActive
to know which slot is active and which is inactive, so that the
slot-specific boot directories can be prepared. In pristine boot
configuration QueryActive fails with a specific error. This error is now
handled, and slot A is assumed to be active.

Unit tests are modified to check the post install handler in three
distinct cases. Where slot A is pristine, when slot B is active and when
slot A is active. Those cover all the possible states so far.

Closes: https://git.ostc-eu.org/OSTC/OHOS/components/sysota/-/issues/52

Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      c74371de
  5. 13 Oct, 2021 3 commits
  7. 09 Oct, 2021 1 commit
  9. 07 Oct, 2021 3 commits
  11. 30 Sep, 2021 1 commit
  13. 29 Sep, 2021 8 commits
  15. 28 Sep, 2021 3 commits
    • Zygmunt Krynicki's avatar
      Makefile: use SystemdUnit template for systemd units · 345b5118
      Zygmunt Krynicki authored 
      

This ensures that the install location is correct and automatic.
Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      345b5118
    • Zygmunt Krynicki's avatar
      .zmk-modules: add template for installing systemd units · a579b52e
      Zygmunt Krynicki authored 
      

Systemd units are a thin wrapper to the InstallUninstall template. Units
can be either system-wide (default) or user-session (by setting
$(unit).IsUser to non-empty value). The InstallDir is set to the
appropriate location for the unit type and is obtained by querying
pkg-config systemd module.
Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      a579b52e
    • Zygmunt Krynicki's avatar
      .zmk-modules: add template for using pkg-config · 2731bf9a
      Zygmunt Krynicki authored 
      

The new PkgConfig template uses PkgConfig.Cmd, by default the
pkg-config executable found on PATH, to check availability of
pkg-config modules.

Each module must have the $(module).AtLeastVersion variable defined, the version
check is checked at compile time but is not enforced. The outcome of the
check is stored in PkgConfig.Modules.$(module).Status and is one of
"sufficient", "outdated" or "missing".

Each module that is not missing will have a number of standard variables
populated under the PkgConfig.Modules.$(module) namespace, those are
.Version, .Cflags, .CflagsOnlyI, .CflagsOnlyOther, .Libs,
.LibsOnlyLowerL, .LibsOnlyL and .LibsOnlyOther.

In addition a module may also have any number of module variable names
listed in $(module).Variables. Those are resolved using pkg-config
--variable= and are available under the namespace
PkgConfig.Modules.$(module).Variables.$(variable).
Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      2731bf9a
  17. 24 Sep, 2021 1 commit
    • Zygmunt Krynicki's avatar
      boot/piboot: use $(system)/usr/lib/sysota/boot-assets · a4f73996
      Zygmunt Krynicki authored 
      The effective change is from $(system)/boot to
$(system)/usr/lib/sysota/boot-assets. A small slice of code and tests
are affected.

After discussing the boot asset location with Andrei we've decided to
switch away from $(system)/boot - namely the boot directory in the
system partition to the aforementioned new location under
SystemOTA-specific directory.

The rationale for that is comprised of several observations:

1) The /boot directory is not synonymous to the $(boot) partition.

The contents of the boot partition are what SystemOTA needs but the
content of the /boot directory is platform specific and, in fact, there
are already platforms where those are not identical. By choosing a new,
explicit location, that is specific to SystemOTA update process, we
avoid this problem entirely.

2) SystemOTA uses a custom slot-{a,b}/ directory structure in $(boot).

The exact details of how SystemOTA manages the boot partition may change
over time but in any case, are a custom extension that is not widely
recognized.

We had an existing design problem that $(boot), as it came out of the
build system, was not really representative of the $(boot) partition
after several (or even the first) updates. Most clearly, the slot
structure is not represented there at all.

There are several ways we could have addressed that: by teaching the
build system about SystemOTA specific (and perhaps platform specific)
layout, by creating a tool which encapsulates that knowledge and build
out of SystemOTA tree or by ignoring it.

We had the same problem with boot assets inside the image, should it
have the slot structure? Should it be identical to the boot assets on a
vanilla system on first boot?

The solution we chose is to avoid the problem entirely and avoid the
need for special tooling. This is how it works.

The build system produces regular boot partition without any special
sauce. The build system has a small SystemOTA specific logic, to copy
everything present in the $(boot) partition to the $(system) partition,
as explained above. This is also implemented in meta-ohos by [1].

Most importantly this has the following property: there is no more need
to pre-process the image or have a special, and perhaps fragile, first
boot which re-organizes the critical boot partition.

Instead, on the first update, the boot protocol can remove up assets
that underwent slotted duplication (like the kernel) and leave
everything else (like firmware files) intact. In other words, on the
first update, after it succeeds and we start to clean up, we can remove
files that we are certain not to be needed anymore. This is also an
entirely *optional* step. It can be skipped or aborted mid-way without
any consequences.

3) Using a generic location like /usr/lib/boot-assets is risky

While it is tempting to offer standardization, we believe this step is
premature. Using a directory specific to the OTA project allows us to
experiment and make mistakes at a smaller scope.

[1] https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/merge_requests/268

Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      a4f73996
  19. 16 Sep, 2021 13 commits
  21. 15 Sep, 2021 1 commit
  23. 14 Sep, 2021 1 commit
  25. 13 Sep, 2021 1 commit
    • Zygmunt Krynicki's avatar
      ota/statehandler: test successful and degraded boots scenarios · 7cb7235b
      Zygmunt Krynicki authored 
      

In the successful case, the boot-complete.target is reached. In the
failing case it is not reached. The existing test-sysota-bless-boot test
is extended to cover both.

Writing this test made me realize that we need to react to failure
by rebooting to ensure the system rolls back. In addition the service
which takes the data backup should react sensibly to failure to create
the backup. One thing which must be prevented is for the update process
to continue without a backup in place.
Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      7cb7235b

| Privacy policy | Cookies policy |