1. 18 Oct, 2021 2 commits
  2. 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
  3. 13 Oct, 2021 3 commits
  4. 09 Oct, 2021 1 commit
  5. 07 Oct, 2021 3 commits
  6. 30 Sep, 2021 1 commit
  7. 29 Sep, 2021 8 commits
  8. 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
  9. 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
  10. 16 Sep, 2021 13 commits
  11. 15 Sep, 2021 1 commit
  12. 14 Sep, 2021 1 commit
  13. 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