- 18 Oct, 2021 2 commits
-
-
Zygmunt Krynicki authored
Experiments with vmdb2 show that the test suite implicitly relies on man-db and strace, without installing them as dependencies. Detect this case and install the missing packages. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
The test stage runs one, non-cross compiled unit test job. The build stage runs ten cross compiled build jobs. If unit tests fail all the cross-building has gone to waste. Swap the order to detect issues earlier. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
- 17 Oct, 2021 2 commits
-
-
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 <zygmunt.krynicki@huawei.com>
-
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 <zygmunt.krynicki@huawei.com>
-
- 13 Oct, 2021 3 commits
-
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
- 09 Oct, 2021 1 commit
-
-
Zygmunt Krynicki authored
Before the first update, the boot system is in a pristine state, exactly as it appears in the boot-assets directory. In that condition we should still respond well to RAUC requests, such as {get,set}-active and {get,set}-state. In this mode slot A is primary (active) and good and slot B is bad. Read requests should return this information, write requests which are not changing that state should be allowed as well. Notably, this makes rauc-mark-good.service work on first boot. Closes: https://git.ostc-eu.org/OSTC/OHOS/components/sysota/-/issues/50 Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
- 07 Oct, 2021 3 commits
-
-
Zygmunt Krynicki authored
The boot package gains the new ErrPristineBootConfig. The boot/piboot package is changed to report an error which is equivalent, in the sense of errors.Is(), so that code outside of the boot package can detect this condition without being aware of a specific bootloader. The new osPrefixError type wraps either errOsPrefixUnset or errOsPrefixEvadesSlot errors, both related to how os_prefix= is set up. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Shuffle the checks so that comments can exceed the line length limit but non-comment declarations are still verified. Closes: https://git.ostc-eu.org/OSTC/OHOS/components/sysota/-/issues/51 Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
The Raspberry Pi firmware has a documented 80-character limit constraining the amount of content which can be expressed per line. It is unclear how this limit applies to comments, as longer comments do not seem to harm correctness of subsequent declarations, but this exception is not explicitly documented. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
- 30 Sep, 2021 1 commit
-
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
- 29 Sep, 2021 8 commits
-
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
In order to make the code more discoverable, all the test suites are being renamed to spread.suite. This will also help with future spread auto-detecting test suites, so that they don't have to be declared manually. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
This allows using a custom Go compiler for the build command. Everything else has already supported this but the primary executable was left out. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
BootProtocolService is very useful for testing but not really needed in production. There was a long standing issue to get it off the set of APIs exposed by default. Extend the introspection test to check both variants. Fix the inert test to enable the flag for itself. Closes: https://git.ostc-eu.org/OSTC/OHOS/components/sysota/-/issues/45 Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
- 28 Sep, 2021 3 commits
-
-
Zygmunt Krynicki authored
This ensures that the install location is correct and automatic. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
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 <zygmunt.krynicki@huawei.com>
-
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 <zygmunt.krynicki@huawei.com>
-
- 24 Sep, 2021 1 commit
-
-
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 <zygmunt.krynicki@huawei.com>
-
- 16 Sep, 2021 13 commits
-
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
The stages are now as follows: - compliance, for DCO and REUSE - static, for spell, format and all go static checks - build, for the parallel matrix cross-build job - test, for the unit test job - integration, for spread Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Move handling of Go cache to the .go job. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
The reuse job depends on dco. The spell and format jobs depend on reuse. The static-checks job depends on spell and format. The unit-tests and cross-build job depends on static-checks. The spread-qemu-hirsute job depends on cross-build and unit-tests. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Split the test job into three jobs: - cross-build - a parallel matrix discussed below - unit-tests - run linux/amd64 unit tests and measure coverage - static-checks - run a collection of static check tools The cross-build job handles Linux, Darwin and Windows, for various CPU architectures each. For Linux, we notably cross-build for riscv64 and arm as well. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Since the three OSes differ only by the name of the environment variable, to make cross-building between the three major platforms work, define the variable name in OS-specific build file, reducing code difference to just that. Tests stay OS-specific in case it is more practical to cover this way. Add Windows version to cover everything that matters right now. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Depending on the OS the exact error message varies a little. Tweak the error regexp to capture all known variants. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
On Darwin, the environment variable providing the path to the system bus is DBUS_LAUNCHD_SESSION_BUS_SOCKET (this is not a mistake!) but otherwise behaves the same as on Linux. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
- 15 Sep, 2021 1 commit
-
-
Zygmunt Krynicki authored
Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
- 14 Sep, 2021 1 commit
-
-
Zygmunt Krynicki authored
The boot protocol is one of the few external interaction protocols, where SystemOTA works with anther software stack. The manual page makes the expectations of the protocol easier to find and understand than the internal Go package documentation. Signed-off-by:
Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
-
- 13 Sep, 2021 1 commit
-
-
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 <zygmunt.krynicki@huawei.com>
-