particle-os/debian-forge
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
debian-forge/test/data
History
Michael Vogt f4f0c8f004 tests: remove lvm2 from the fedora-boot test manifest 
With lvm2 the generated fedora fc38 boot image boots in degraded
mode with the following error:
```
[root@localhost ~]# journalctl -u lvm2-monitor.service|more
Nov 13 12:52:04 localhost.localdomain lvm[431]:   Failed to create /etc/lvm/devi
ces 2
Nov 13 12:52:04 localhost.localdomain lvm[431]:   Failed to set up devices.
Nov 13 12:52:04 localhost.localdomain systemd[1]: lvm2-monitor.service: Main pro
cess exited, code=exited, status=5/NOTINSTALLED
Nov 13 12:52:04 localhost.localdomain systemd[1]: lvm2-monitor.service: Failed w
ith result 'exit-code'.
Nov 13 12:52:04 localhost.localdomain systemd[1]: Failed to start lvm2-monitor.s
ervice - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress p
olling.
```
This breaks the `test_boot.py` which expects the system after booting
in `running` state  (from `systemd is-system-running`).

It looks like this is some sort of race with our generated image,
potentially related to selinux, see
https://github.com/lvmteam/lvm2/blob/v2_03_18/lib/device/dev-cache.c#L1842
and note the lines around dm_prepare_selinux_context(). Note
also that `lvm2-monitor.service` runs with `DefaultDependencies=no`
(c.f.
https://github.com/lvmteam/lvm2/blob/v2_03_18/scripts/lvm2_monitoring_systemd_red_hat.service.in#L7)

Given that the official fc38 cloud image does not use lvm2 and that
it's not needed for the boot test this commit simply removes it
from the fedora-boot manifest. This fixes the test.
2023-11-14 10:45:44 -08:00
..
assemblers test/run/assemblers: convert to a v2 manifest 2023-11-14 10:45:44 -08:00
manifests tests: remove lvm2 from the fedora-boot test manifest 2023-11-14 10:45:44 -08:00
os-release test: update test manifests to use Fedora 34 2021-06-07 12:15:26 +02:00
scripts osbuild: run isort on all files 2022-09-12 13:32:51 +02:00
sources sources/ostree: set contenturl when pulling from remote 2022-10-14 12:04:54 +02:00
stages tests: update diff for authselect stage to use "null" content 2023-11-14 10:45:44 -08:00
README.md rename all .mpp.json files to .mpp.yaml 2023-08-08 12:41:17 +02:00
v2 test: Add skopeo tests 2022-02-10 14:43:17 +01:00

README.md

OSBuild Test Data

This directory contains data used by the osbuild test-suite. Since many formats do not allow comments, this file shortly describes their purpose.

Directories

  • ./os-release/: This directory is consumed by the unit-tests of the os-release parser. The directory contains example os-release files (see os-release(5)). Their directory name is the expected output of the parser.

  • ./manifests/: This directory contains osbuild manifests used throughout the test-suite.

    Manifests prefixed with f30, f31, etc. are manifests that produce fedora images. If they have base as part of their name, they include a base set of packages which we very loosely define as @core plus the packages our test-suite needs. If they have build as part of their name, they have a very restricted package set which includes just what is needed in a build-root for osbuild. The fedora prefix is used for manifests that are kept up to date to the newest fedora release, and thus do not expose a specific f30, f32, etc. behavior.

    The rhel prefix is used for Red Hat Enterprise Linux images. Since they are not available publicly, the test-suite usually skips them.

    The filesystem manifest is used to test assemblers. These tests doesn't need a big filesystem tree representing a whole operating system. Instead, this manifest's tree is constructed just from the filesystem package and is marked using the selinux stage.

    Manifests ending on .mpp.yaml are fed through the ManifestPreProcessors and then stored in the same directory with an .json extension (replacing .mpp.yaml). generated files are committed to the repository. Nevertheless, if you need to regenerate them, use make test-data.

  • ./sources/: This directory contains test-data for runtime tests of the source-engines. It contains a directory that is served via HTTP in the tests, and a directory of test-cases what to expect when using the attached sources.json.

  • scripts: This directory contains scripts used from other tests, i.e. although they are executables they are at the same time test-data to the actual (unit) tests.