[PATCH test-artifacts v3 00/13] Changes for several CI improvements

[PATCH test-artifacts v3 00/13] Changes for several CI improvements

[Marek Marczykowski-Górecki]

- Alpine update
- Debian trixie
- test arbitrary linux branch
- Linux stubdom

Technically, the last patch isn't strictly required, but it eases debugging.

In v3 I reordered patches a bit, to move Linux tests earlier.

Example pipeline: https://gitlab.com/xen-project/people/marmarek/test-artifacts/-/pipelines/2422090153

Marek Marczykowski-Górecki (13):
  Add Alpine 3.22 containers
  Switch Linux builds to use Alpine 3.22 container
  Add debian rootfs artifact
  Add linux-6.12.79-x86_64
  Enable CONFIG_USB_RTL8152 in kernel for hw12 runner
  Include git in the ARM64 build container too
  Support building arbitrary Linux branch/tag/commit
  Save Linux config to artifacts too
  Add trigger-test job, to run test on a Linux built from a branch/tag
  Add linux-stubdom dependencies
  Prepare grub for booting x86_64 HVM domU from a disk
  Prepare grub for booting x86_64 HVM domU from a cdrom
  Setup ssh access to test systems

 .gitlab-ci.yml                             | 72 +++++++++++++++--
 containerize                               |  4 +-
 images/alpine/3.18-arm64-build.dockerfile  |  1 +-
 images/alpine/3.22-arm64-base.dockerfile   |  6 +-
 images/alpine/3.22-arm64-build.dockerfile  | 31 +++++++-
 images/alpine/3.22-x86_64-base.dockerfile  |  6 +-
 images/alpine/3.22-x86_64-build.dockerfile | 43 ++++++++++-
 images/debian/13-x86_64-base.dockerfile    |  4 +-
 scripts/alpine-rootfs.sh                   | 25 ++++++-
 scripts/build-linux.sh                     | 24 ++++--
 scripts/debian-rootfs.sh                   | 96 +++++++++++++++++++++++-
 11 files changed, 300 insertions(+), 12 deletions(-)
 create mode 100644 images/alpine/3.22-arm64-base.dockerfile
 create mode 100644 images/alpine/3.22-arm64-build.dockerfile
 create mode 100644 images/alpine/3.22-x86_64-base.dockerfile
 create mode 100644 images/alpine/3.22-x86_64-build.dockerfile
 create mode 100644 images/debian/13-x86_64-base.dockerfile
 create mode 100755 scripts/debian-rootfs.sh

base-commit: 76894a5929bc604fb5bdb4aff2f94a6a9df68cdb
-- 
git-series 0.9.1

[PATCH test-artifacts v3 02/13] Switch Linux builds to use Alpine 3.22 container

[Marek Marczykowski-Górecki]

Slowly phase out 3.18 one.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 .gitlab-ci.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 17d25ce0f921..36622c723ce9 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -21,14 +21,14 @@ stages:
   tags:
     - arm64
   variables:
-    CONTAINER: alpine:3.18-arm64-build
+    CONTAINER: alpine:3.22-arm64-build
 
 .x86_64-artifacts:
   extends: .artifacts
   tags:
     - x86_64
   variables:
-    CONTAINER: alpine:3.18-x86_64-build
+    CONTAINER: alpine:3.22-x86_64-build
 
 #
 # ARM64 artifacts
-- 
git-series 0.9.1

Re: [PATCH test-artifacts v3 02/13] Switch Linux builds to use Alpine 3.22 container

[Orzel, Michal]

Why not 3.23 if it's already there?

~Michal

On 01/04/2026 01:21, Marek Marczykowski-Górecki wrote:
> Slowly phase out 3.18 one.
> 
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> ---
>  .gitlab-ci.yml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 17d25ce0f921..36622c723ce9 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -21,14 +21,14 @@ stages:
>    tags:
>      - arm64
>    variables:
> -    CONTAINER: alpine:3.18-arm64-build
> +    CONTAINER: alpine:3.22-arm64-build
>  
>  .x86_64-artifacts:
>    extends: .artifacts
>    tags:
>      - x86_64
>    variables:
> -    CONTAINER: alpine:3.18-x86_64-build
> +    CONTAINER: alpine:3.22-x86_64-build
>  
>  #
>  # ARM64 artifacts

Re: [PATCH test-artifacts v3 02/13] Switch Linux builds to use Alpine 3.22 container

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

On Wed, Apr 01, 2026 at 08:46:02AM +0200, Orzel, Michal wrote:
> Why not 3.23 if it's already there?

Because it wasn't yet when I prepared this patch series :)

I can update again and see if any other changes are needed with 3.23.
Other patches are independent of this change.

> 
> ~Michal
> 
> On 01/04/2026 01:21, Marek Marczykowski-Górecki wrote:
> > Slowly phase out 3.18 one.
> > 
> > Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> > ---
> >  .gitlab-ci.yml | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 17d25ce0f921..36622c723ce9 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -21,14 +21,14 @@ stages:
> >    tags:
> >      - arm64
> >    variables:
> > -    CONTAINER: alpine:3.18-arm64-build
> > +    CONTAINER: alpine:3.22-arm64-build
> >  
> >  .x86_64-artifacts:
> >    extends: .artifacts
> >    tags:
> >      - x86_64
> >    variables:
> > -    CONTAINER: alpine:3.18-x86_64-build
> > +    CONTAINER: alpine:3.22-x86_64-build
> >  
> >  #
> >  # ARM64 artifacts
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH test-artifacts v3 02/13] Switch Linux builds to use Alpine 3.22 container

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Wed, Apr 01, 2026 at 08:58:04AM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 01, 2026 at 08:46:02AM +0200, Orzel, Michal wrote:
> > Why not 3.23 if it's already there?
> 
> Because it wasn't yet when I prepared this patch series :)
> 
> I can update again and see if any other changes are needed with 3.23.
> Other patches are independent of this change.

So, Linux 6.6.56 fails to build there:
https://gitlab.com/xen-project/people/marmarek/test-artifacts/-/jobs/14191260643

This is fixed in Linux 6.6.95, but I can't just drop 6.6.56 as stable
branches still use it. Alternatively, I could keep this one building on
Alpine 3.18, as it needs to stay anyway for the same reason.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH test-artifacts v3 04/13] Add linux-6.12.79-x86_64

[Marek Marczykowski-Górecki]

This is necessary for new Zen4 runner.
Do not include Argo module in this build, as it isn't compatible with
6.12 yet.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
Changes in v2:
- update 6.12.34 to 6.12.60, retaining acks
Changes in v3:
- update 6.12.60 to 6.12.79, retaining acks
---
 .gitlab-ci.yml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index b23040505bf5..58f7571f5366 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -85,6 +85,10 @@ linux-6.6.56-x86_64:
     ARGO_SHA: "cf73819cacc945baca1a7421e5836d1bd481739b"
     ARGOEXEC_SHA: "d900429f6640acc6f68a3d3a4c945d7da60625d8"
 
+linux-6.12.60-x86_64:
+  extends: .x86_64-artifacts
+  script: ./scripts/build-linux.sh "6.12.60"
+
 microcode-x86:
   extends: .x86_64-artifacts
   script: ./scripts/x86-microcode.sh
-- 
git-series 0.9.1

Re: [PATCH test-artifacts v3 04/13] Add linux-6.12.79-x86_64

[Anthony PERARD]

On Wed, Apr 01, 2026 at 01:21:54AM +0200, Marek Marczykowski-Górecki wrote:
> +linux-6.12.60-x86_64:
> +  extends: .x86_64-artifacts
> +  script: ./scripts/build-linux.sh "6.12.60"

I've got:
    $ ./scripts/build-linux.sh "6.12.60"
    LINUX_VERSION must be set

Linux version want's to be in a env variable, not an argument.

Cheers,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH test-artifacts v3 04/13] Add linux-6.12.79-x86_64

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Wed, Apr 15, 2026 at 11:56:53AM +0000, Anthony PERARD wrote:
> On Wed, Apr 01, 2026 at 01:21:54AM +0200, Marek Marczykowski-Górecki wrote:
> > +linux-6.12.60-x86_64:
> > +  extends: .x86_64-artifacts
> > +  script: ./scripts/build-linux.sh "6.12.60"
> 
> I've got:
>     $ ./scripts/build-linux.sh "6.12.60"
>     LINUX_VERSION must be set
> 
> Linux version want's to be in a env variable, not an argument.

Oh, that's patch ordering, after 07/13 it's in argument.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH test-artifacts v3 05/13] Enable CONFIG_USB_RTL8152 in kernel for hw12 runner

[Marek Marczykowski-Górecki]

It uses this USB network interface.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
This was posted before at https://lore.kernel.org/xen-devel/20250411203336.585215-1-marmarek@invisiblethingslab.com/
---
 scripts/build-linux.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/build-linux.sh b/scripts/build-linux.sh
index 441b8721a490..cf0e744bd232 100755
--- a/scripts/build-linux.sh
+++ b/scripts/build-linux.sh
@@ -32,6 +32,7 @@ case $UNAME in
             | grep 'XEN' \
             | grep '=m' \
             | sed 's/=m/=y/g' >> .config
+        ./scripts/config --enable USB_RTL8152
         ;;
 
     aarch64)
-- 
git-series 0.9.1

[PATCH test-artifacts v3 06/13] Include git in the ARM64 build container too

[Marek Marczykowski-Górecki]

It will be used for fetching some Linux versions.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
---
 images/alpine/3.18-arm64-build.dockerfile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/images/alpine/3.18-arm64-build.dockerfile b/images/alpine/3.18-arm64-build.dockerfile
index 25a8dbd1090b..38464c950eae 100644
--- a/images/alpine/3.18-arm64-build.dockerfile
+++ b/images/alpine/3.18-arm64-build.dockerfile
@@ -14,6 +14,7 @@ RUN <<EOF
       DEPS=(# Base environment
             build-base
             curl
+            git
 
             # Linux build deps
             bison
-- 
git-series 0.9.1

[PATCH test-artifacts v3 07/13] Support building arbitrary Linux branch/tag/commit

[Marek Marczykowski-Górecki]

Change how kernel version is given to the script - use arguments, to
avoid confusion between pipeline level variables and job level ones.

The build-linux.sh now can take either just the kernel version (used to be
LINUX_VERSION variable), or git branch/tag/commit name + git URL (new feature).
Go with "git init" + "git fetch" instead of "git clone" to support any
of branch/tag/commit.

This also defines optional linux-git-* jobs which will build the thing
if LINUX_GIT_VERSION and LINUX_GIT_URL variables are provided for the
pipeline.

The idea is to define separate CI schedules for the test-artifacts repo
with LINUX_GIT_URL/LINUX_GIT_VERSION pointing at Linux trees to be
tested (for example linux-next), and then trigger matching pipelines in
the xen repo for testing with that version.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
Changes in v3:
- pass kernel version via script arguments, not variables
---
 .gitlab-ci.yml         | 23 ++++++++++++++++++-----
 scripts/build-linux.sh | 21 ++++++++++++++++-----
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 58f7571f5366..62b2a24e7faf 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,5 +1,9 @@
 variables:
   REGISTRY: registry.gitlab.com/xen-project/hardware/test-artifacts
+  LINUX_GIT_VERSION:
+    description: "branch/tag/commit for the linux-git jobs"
+  LINUX_GIT_URL:
+    description: "git url for the linux-git jobs"
 
 stages:
   - build
@@ -49,9 +53,13 @@ alpine-3.22-arm64-rootfs:
 
 linux-6.6.86-arm64:
   extends: .arm64-artifacts
-  script: ./scripts/build-linux.sh
-  variables:
-    LINUX_VERSION: 6.6.86
+  script: ./scripts/build-linux.sh "6.6.86"
+
+linux-git-arm64:
+  extends: .arm64-artifacts
+  script: ./scripts/build-linux.sh "$LINUX_GIT_VERSION" "$LINUX_GIT_URL"
+  rules:
+  - if: $LINUX_GIT_VERSION && $LINUX_GIT_URL
 
 #
 # x86_64 artifacts
@@ -79,9 +87,8 @@ debian-13-x86_64-rootfs:
 
 linux-6.6.56-x86_64:
   extends: .x86_64-artifacts
-  script: ./scripts/build-linux.sh
+  script: ./scripts/build-linux.sh "6.6.56"
   variables:
-    LINUX_VERSION: 6.6.56
     ARGO_SHA: "cf73819cacc945baca1a7421e5836d1bd481739b"
     ARGOEXEC_SHA: "d900429f6640acc6f68a3d3a4c945d7da60625d8"
 
@@ -89,6 +96,12 @@ linux-6.12.60-x86_64:
   extends: .x86_64-artifacts
   script: ./scripts/build-linux.sh "6.12.60"
 
+linux-git-x86_64:
+  extends: .x86_64-artifacts
+  script: ./scripts/build-linux.sh "$LINUX_GIT_VERSION" "$LINUX_GIT_URL"
+  rules:
+  - if: $LINUX_GIT_VERSION && $LINUX_GIT_URL
+
 microcode-x86:
   extends: .x86_64-artifacts
   script: ./scripts/x86-microcode.sh
diff --git a/scripts/build-linux.sh b/scripts/build-linux.sh
index cf0e744bd232..882bac2189a6 100755
--- a/scripts/build-linux.sh
+++ b/scripts/build-linux.sh
@@ -1,5 +1,8 @@
 #!/usr/bin/env bash
 
+LINUX_VERSION="$1"
+LINUX_GIT_URL="$2"
+
 if test -z "${LINUX_VERSION}"
 then
     >&2 echo "LINUX_VERSION must be set"; exit 1
@@ -12,11 +15,19 @@ COPYDIR="${WORKDIR}/binaries"
 UNAME=$(uname -m)
 
 # Build Linux
-MAJOR=${LINUX_VERSION%%.*}
-curl -fsSLO \
-    https://cdn.kernel.org/pub/linux/kernel/v"${MAJOR}".x/linux-"${LINUX_VERSION}".tar.xz
-tar xf linux-"${LINUX_VERSION}".tar.xz
-cd linux-"${LINUX_VERSION}"
+if [[ -n "${LINUX_GIT_URL}" ]]; then
+    mkdir linux
+    cd linux
+    git init
+    git fetch --depth=1 "${LINUX_GIT_URL}" "${LINUX_VERSION}"
+    git checkout FETCH_HEAD
+else
+    MAJOR=${LINUX_VERSION%%.*}
+    curl -fsSLO \
+        https://cdn.kernel.org/pub/linux/kernel/v"${MAJOR}".x/linux-"${LINUX_VERSION}".tar.xz
+    tar xf linux-"${LINUX_VERSION}".tar.xz
+    cd linux-"${LINUX_VERSION}"
+fi
 
 make defconfig
 ./scripts/config --enable BRIDGE
-- 
git-series 0.9.1

Re: [PATCH test-artifacts v3 07/13] Support building arbitrary Linux branch/tag/commit

[Anthony PERARD]

On Wed, Apr 01, 2026 at 01:21:57AM +0200, Marek Marczykowski-Górecki wrote:
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 58f7571f5366..62b2a24e7faf 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -49,9 +53,13 @@ alpine-3.22-arm64-rootfs:
>
>  linux-6.6.86-arm64:
>    extends: .arm64-artifacts
> -  script: ./scripts/build-linux.sh
> -  variables:
> -    LINUX_VERSION: 6.6.86
> +  script: ./scripts/build-linux.sh "6.6.86"

Is it crazy to think we could grab the linux version from the job name?
:-D

linux-6.6.86-arm64:
  script:
    - linux_version="$CI_JOB_NAME"
    - linux_version="${linux_version#linux-}"
    - linux_version="${linux_version%%-*}"
    - ./scripts/build-linux.sh "$linux_version"

That would avoid having a job building a version of linux that is
different than the expected one, which can happen easly when duplicating
an existing job for building a new version of linux.

> diff --git a/scripts/build-linux.sh b/scripts/build-linux.sh
> index cf0e744bd232..882bac2189a6 100755
> --- a/scripts/build-linux.sh
> +++ b/scripts/build-linux.sh
> @@ -1,5 +1,8 @@
>  #!/usr/bin/env bash
>
> +LINUX_VERSION="$1"
> +LINUX_GIT_URL="$2"
> +
>  if test -z "${LINUX_VERSION}"

With LINUX_VERSION been set just before, this test doesn't make sense
anymore, or the error message is wrong.

>  then
>      >&2 echo "LINUX_VERSION must be set"; exit 1

Thanks,


--
 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

[PATCH test-artifacts v3 08/13] Save Linux config to artifacts too

[Marek Marczykowski-Górecki]

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
 scripts/build-linux.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/build-linux.sh b/scripts/build-linux.sh
index 882bac2189a6..967c63c5effb 100755
--- a/scripts/build-linux.sh
+++ b/scripts/build-linux.sh
@@ -53,6 +53,8 @@ esac
 
 make olddefconfig
 
+cp .config "${COPYDIR}/linux.config"
+
 case $UNAME in
     x86_64)
         make -j$(nproc) bzImage
-- 
git-series 0.9.1

[PATCH test-artifacts v3 09/13] Add trigger-test job, to run test on a Linux built from a branch/tag

[Marek Marczykowski-Górecki]

When scheduling pipeline in test-artifacts repo, it can get also
TEST_TRIGGER_REPO and TEST_TRIGGER_BRANCH variables, to trigger relevant
pipeline to test just built artifacts.
Pass ARTIFACTS_REPO+ARTIFACTS_BRANCH to the child pipeline to ensure it
fetches artifacts from the right job.
For example, to build linux-next and test Xen staging on it, the
pipeline could be triggered with:

    LINUX_GIT_URL=https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
    LINUX_GIT_VERSION=master
    TEST_TRIGGER_REPO=xen-project/hardware/xen
    TEST_TRIGGER_BRANCH=staging

The triggered xen test pipeline will skip most build jobs.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 .gitlab-ci.yml | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 62b2a24e7faf..9d90a8f57ff8 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -4,9 +4,14 @@ variables:
     description: "branch/tag/commit for the linux-git jobs"
   LINUX_GIT_URL:
     description: "git url for the linux-git jobs"
+  TEST_TRIGGER_REPO:
+    description: "gitlab repo on which test just built linux, for example 'xen-project/hardware/xen'"
+  TEST_TRIGGER_BRANCH:
+    description: "branch in TEST_TRIGGER_REPO to test on, for example 'staging'"
 
 stages:
   - build
+  - deploy
 
 .artifacts:
   stage: build
@@ -105,3 +110,18 @@ linux-git-x86_64:
 microcode-x86:
   extends: .x86_64-artifacts
   script: ./scripts/x86-microcode.sh
+
+trigger-test:
+  stage: deploy
+  trigger:
+    project: $TEST_TRIGGER_REPO
+    branch: $TEST_TRIGGER_BRANCH
+    strategy: mirror
+  variables:
+    ARTIFACTS_REPO: $CI_PROJECT_PATH
+    ARTIFACTS_BRANCH: $CI_COMMIT_REF_NAME
+    LINUX_JOB_X86_64: linux-git-x86_64
+    LINUX_JOB_ARM64: linux-git-arm64
+    BUILD_FOR_TESTS_ONLY: 1
+  rules:
+  - if: $TEST_TRIGGER_REPO && $TEST_TRIGGER_BRANCH
-- 
git-series 0.9.1

Re: [PATCH test-artifacts v3 09/13] Add trigger-test job, to run test on a Linux built from a branch/tag

[Anthony PERARD]

On Wed, Apr 01, 2026 at 01:21:59AM +0200, Marek Marczykowski-Górecki wrote:
> When scheduling pipeline in test-artifacts repo, it can get also
> TEST_TRIGGER_REPO and TEST_TRIGGER_BRANCH variables, to trigger relevant
> pipeline to test just built artifacts.
> Pass ARTIFACTS_REPO+ARTIFACTS_BRANCH to the child pipeline to ensure it
> fetches artifacts from the right job.
> For example, to build linux-next and test Xen staging on it, the
> pipeline could be triggered with:
>
>     LINUX_GIT_URL=https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>     LINUX_GIT_VERSION=master
>     TEST_TRIGGER_REPO=xen-project/hardware/xen
>     TEST_TRIGGER_BRANCH=staging
>
> The triggered xen test pipeline will skip most build jobs.
>
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> ---

You might want to add that this depends on two patch for the xen repo,
for the trigger to do the expected tests:
    CI: make test-artifacts repo/branch/job customizable
    ci: introduce BUILD_FOR_TESTS_ONLY

> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 62b2a24e7faf..9d90a8f57ff8 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -105,3 +110,18 @@ linux-git-x86_64:
>  microcode-x86:
>    extends: .x86_64-artifacts
>    script: ./scripts/x86-microcode.sh
> +
> +trigger-test:
> +  stage: deploy
> +  trigger:
> +    project: $TEST_TRIGGER_REPO
> +    branch: $TEST_TRIGGER_BRANCH
> +    strategy: mirror
> +  variables:
> +    ARTIFACTS_REPO: $CI_PROJECT_PATH
> +    ARTIFACTS_BRANCH: $CI_COMMIT_REF_NAME
> +    LINUX_JOB_X86_64: linux-git-x86_64
> +    LINUX_JOB_ARM64: linux-git-arm64
> +    BUILD_FOR_TESTS_ONLY: 1

Can we add this?
  inherit:
    variables: false

Otherwise, as I understand, the triggered pipeline will also use the
global variables, like TEST_TRIGGER_REPO, LINUX_GIT_VERSION, ... Or I
could be wrong because we don't set a default value and the are only
manual/scheduled pipeline variable.

https://docs.gitlab.com/ci/yaml/#trigger
> CI/CD variables defined in a top-level variables section (globally) or
> in the trigger job are forwarded to the downstream pipeline as trigger
> variables.

https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#prevent-default-variables-from-being-passed

I'm not sure if the inherit:variables:false is needed, so:
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Thanks,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH test-artifacts v3 09/13] Add trigger-test job, to run test on a Linux built from a branch/tag

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 3104 bytes --]

On Wed, Apr 15, 2026 at 01:44:47PM +0000, Anthony PERARD wrote:
> On Wed, Apr 01, 2026 at 01:21:59AM +0200, Marek Marczykowski-Górecki wrote:
> > When scheduling pipeline in test-artifacts repo, it can get also
> > TEST_TRIGGER_REPO and TEST_TRIGGER_BRANCH variables, to trigger relevant
> > pipeline to test just built artifacts.
> > Pass ARTIFACTS_REPO+ARTIFACTS_BRANCH to the child pipeline to ensure it
> > fetches artifacts from the right job.
> > For example, to build linux-next and test Xen staging on it, the
> > pipeline could be triggered with:
> >
> >     LINUX_GIT_URL=https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> >     LINUX_GIT_VERSION=master
> >     TEST_TRIGGER_REPO=xen-project/hardware/xen
> >     TEST_TRIGGER_BRANCH=staging
> >
> > The triggered xen test pipeline will skip most build jobs.
> >
> > Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> > ---
> 
> You might want to add that this depends on two patch for the xen repo,
> for the trigger to do the expected tests:
>     CI: make test-artifacts repo/branch/job customizable
>     ci: introduce BUILD_FOR_TESTS_ONLY
> 
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 62b2a24e7faf..9d90a8f57ff8 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -105,3 +110,18 @@ linux-git-x86_64:
> >  microcode-x86:
> >    extends: .x86_64-artifacts
> >    script: ./scripts/x86-microcode.sh
> > +
> > +trigger-test:
> > +  stage: deploy
> > +  trigger:
> > +    project: $TEST_TRIGGER_REPO
> > +    branch: $TEST_TRIGGER_BRANCH
> > +    strategy: mirror
> > +  variables:
> > +    ARTIFACTS_REPO: $CI_PROJECT_PATH
> > +    ARTIFACTS_BRANCH: $CI_COMMIT_REF_NAME
> > +    LINUX_JOB_X86_64: linux-git-x86_64
> > +    LINUX_JOB_ARM64: linux-git-arm64
> > +    BUILD_FOR_TESTS_ONLY: 1
> 
> Can we add this?
>   inherit:
>     variables: false
> 
> Otherwise, as I understand, the triggered pipeline will also use the
> global variables, like TEST_TRIGGER_REPO, LINUX_GIT_VERSION, ... Or I
> could be wrong because we don't set a default value and the are only
> manual/scheduled pipeline variable.
> 
> https://docs.gitlab.com/ci/yaml/#trigger
> > CI/CD variables defined in a top-level variables section (globally) or
> > in the trigger job are forwarded to the downstream pipeline as trigger
> > variables.
> 
> https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#prevent-default-variables-from-being-passed

Hm, yes, inherit:variables:false might be needed if we'd want to avoid
passing those variables. But, TBH I'm not sure if we want to avoid that
- it might be useful at some point to get LINUX_GIT_VERSION there, for
example. 

> I'm not sure if the inherit:variables:false is needed, so:
> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
> 
> Thanks,
> 
> 
> --
> Anthony Perard | Vates XCP-ng Developer
> 
> XCP-ng & Xen Orchestra - Vates solutions
> 
> web: https://vates.tech
> 
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH test-artifacts v3 09/13] Add trigger-test job, to run test on a Linux built from a branch/tag

[Anthony PERARD]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

On Wed, Apr 15, 2026 at 07:40:19PM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 15, 2026 at 01:44:47PM +0000, Anthony PERARD wrote:
> > On Wed, Apr 01, 2026 at 01:21:59AM +0200, Marek Marczykowski-Górecki wrote:
> > > +trigger-test:
> > > +  stage: deploy
> > > +  trigger:
> > > +    project: $TEST_TRIGGER_REPO
> > > +    branch: $TEST_TRIGGER_BRANCH
> > > +    strategy: mirror
> > > +  variables:
> > > +    ARTIFACTS_REPO: $CI_PROJECT_PATH
> > > +    ARTIFACTS_BRANCH: $CI_COMMIT_REF_NAME
> > > +    LINUX_JOB_X86_64: linux-git-x86_64
> > > +    LINUX_JOB_ARM64: linux-git-arm64
> > > +    BUILD_FOR_TESTS_ONLY: 1
> > 
> > Can we add this?
> >   inherit:
> >     variables: false
> > 
> > Otherwise, as I understand, the triggered pipeline will also use the
> > global variables, like TEST_TRIGGER_REPO, LINUX_GIT_VERSION, ... Or I
> > could be wrong because we don't set a default value and the are only
> > manual/scheduled pipeline variable.
> > 
> > https://docs.gitlab.com/ci/yaml/#trigger
> > > CI/CD variables defined in a top-level variables section (globally) or
> > > in the trigger job are forwarded to the downstream pipeline as trigger
> > > variables.
> > 
> > https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#prevent-default-variables-from-being-passed
> 
> Hm, yes, inherit:variables:false might be needed if we'd want to avoid
> passing those variables. But, TBH I'm not sure if we want to avoid that
> - it might be useful at some point to get LINUX_GIT_VERSION there, for
> example. 

I've run a test and I don't see LINUX_GIT_VERSION value in the
trigger pipeline, only the default value.

See https://gitlab.com/xen-project/people/anthonyper/xen/-/jobs/14042314690/viewer

    $ echo triggered by ${LINUX_GIT_URL} and ${LINUX_GIT_VERSION};
    triggered by and
    $ env
    REGISTRY=registry.gitlab.com/xen-project/people/anthonyper/test-artifacts
    XEN_REGISTRY=registry.gitlab.com/xen-project/xen
    LINUX_GIT_VERSION=
    LINUX_GIT_URL=
    TEST_TRIGGER_REPO=
    TEST_TRIGGER_BRANCH=
    ARTIFACTS_REPO=xen-project/people/anthonyper/test-artifacts
    LINUX_JOB_X86_64=linux-git-x86_64
    ...

So, the triggered pipeline got the value of the variable as set in
`.gitlab-ci.yml` `variables` section, and the values of the variables
set in the trigger job. But the value set via push-variable are missing.
So far, the triggered pipeline doesn't get the useful variable values,
beside the needed ones. And my main issue would be with the REGISTRY or
XEN_REGISTRY variables, if we rename one into the other, the triggered
pipeline could fail.

So I think we should use inherit:variables:false, and explicitly
passthrough the variables we want.

Cheers,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

[PATCH test-artifacts v3 10/13] Add linux-stubdom dependencies

[Marek Marczykowski-Górecki]

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 scripts/alpine-rootfs.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
index 3cd3ab90697e..2671ab5662f9 100755
--- a/scripts/alpine-rootfs.sh
+++ b/scripts/alpine-rootfs.sh
@@ -39,6 +39,10 @@ case $UNAME in
 
             # QEMU
             libelf
+
+            # Stubdomain
+            grub-bios
+            libseccomp
             )
         # libdw used to be part of libelf in Alpine 3.18, but it's a separate
         # package in 3.22.
-- 
git-series 0.9.1

[PATCH test-artifacts v3 11/13] Prepare grub for booting x86_64 HVM domU from a disk

[Marek Marczykowski-Górecki]

The stubdomain test will use it

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 scripts/alpine-rootfs.sh | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
index 2671ab5662f9..18f43e6bcd9e 100755
--- a/scripts/alpine-rootfs.sh
+++ b/scripts/alpine-rootfs.sh
@@ -96,5 +96,12 @@ cd /
     echo -ne "dev\0proc\0run\0sys\0"
 } | cpio -0 -R 0:0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
 
+if [ "$UNAME" = "x86_64" ]; then
+    # Prepare boot sector for HVM disk
+    grub-mkimage -o ${COPYDIR}/grub-core.img \
+        -O i386-pc -p '(hd0,msdos1)/boot/grub2' \
+        boot part_msdos ext2 linux biosdisk configfile normal
+fi
+
 # Print the contents for the build log
 zcat "${COPYDIR}/rootfs.cpio.gz" | cpio -tv
-- 
git-series 0.9.1

[PATCH test-artifacts v3 12/13] Prepare grub for booting x86_64 HVM domU from a cdrom

[Marek Marczykowski-Górecki]

The stubdomain test will use it.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 scripts/alpine-rootfs.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
index 18f43e6bcd9e..f649550d80ab 100755
--- a/scripts/alpine-rootfs.sh
+++ b/scripts/alpine-rootfs.sh
@@ -101,6 +101,9 @@ if [ "$UNAME" = "x86_64" ]; then
     grub-mkimage -o ${COPYDIR}/grub-core.img \
         -O i386-pc -p '(hd0,msdos1)/boot/grub2' \
         boot part_msdos ext2 linux biosdisk configfile normal
+    grub-mkimage -o ${COPYDIR}/grub-core-eltorito.img \
+        -O i386-pc-eltorito -p '(cd)/boot/grub2' \
+        boot part_msdos ext2 linux biosdisk configfile normal iso9660
 fi
 
 # Print the contents for the build log
-- 
git-series 0.9.1

[PATCH test-artifacts v3 13/13] Setup ssh access to test systems

[Marek Marczykowski-Górecki]

For this add also bridge package, so xenbr0 can be configured with
/etc/network/interfaces.
This allows extracting more logs out of the test system.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v2:
- do not allow passwordless login
---
 scripts/alpine-rootfs.sh | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
index f649550d80ab..0afae48cfa6b 100755
--- a/scripts/alpine-rootfs.sh
+++ b/scripts/alpine-rootfs.sh
@@ -10,6 +10,8 @@ apk --no-cache upgrade
 
 PKGS=(
     # System
+    bridge
+    dropbear
     libgcc
     openrc
     udev
@@ -72,6 +74,7 @@ rc-update add loopback sysinit
 rc-update add bootmisc boot
 rc-update add devfs sysinit
 rc-update add dmesg sysinit
+rc-update add dropbear boot
 rc-update add hostname boot
 rc-update add hwclock boot
 rc-update add hwdrivers sysinit
@@ -84,7 +87,9 @@ echo "ttyS0" >> /etc/securetty
 echo "hvc0" >> /etc/securetty
 echo "ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100" >> /etc/inittab
 echo "hvc0::respawn:/sbin/getty -L hvc0 115200 vt100" >> /etc/inittab
+echo "DROPBEAR_OPTS=\"-R\"" >> /etc/conf.d/dropbear
 echo "rc_verbose=yes" >> /etc/rc.conf
+touch /etc/network/interfaces
 echo > /etc/modules
 passwd -d "root" root
 
-- 
git-series 0.9.1

Re: [PATCH test-artifacts v3 13/13] Setup ssh access to test systems

[Anthony PERARD]

On Wed, Apr 01, 2026 at 01:22:03AM +0200, Marek Marczykowski-Górecki wrote:
> diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
> index f649550d80ab..0afae48cfa6b 100755
> --- a/scripts/alpine-rootfs.sh
> +++ b/scripts/alpine-rootfs.sh
> @@ -72,6 +74,7 @@ rc-update add loopback sysinit
>  rc-update add bootmisc boot
>  rc-update add devfs sysinit
>  rc-update add dmesg sysinit
> +rc-update add dropbear boot
>  rc-update add hostname boot
>  rc-update add hwclock boot
>  rc-update add hwdrivers sysinit
> @@ -84,7 +87,9 @@ echo "ttyS0" >> /etc/securetty
>  echo "hvc0" >> /etc/securetty
>  echo "ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100" >> /etc/inittab
>  echo "hvc0::respawn:/sbin/getty -L hvc0 115200 vt100" >> /etc/inittab
> +echo "DROPBEAR_OPTS=\"-R\"" >> /etc/conf.d/dropbear

Is this useful somehow? Because the service that start dropbear will
generate the ssh_host keys before starting dropbear.

>  echo "rc_verbose=yes" >> /etc/rc.conf
> +touch /etc/network/interfaces

That the kind of command that I don't understand what it is for on a
first look ...
But looks like it just to allow the "networking" service to start
without error if the test didn't configure networking via this file. A
comment would be nice, here or in the commit message.

Thanks,


--
 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH test-artifacts v3 03/13] Add debian rootfs artifact

[Anthony PERARD]

I'm commenting on changes I found in the branch used by the pipeline
linked in the cover leter, since there's no copy on the mailing list of
the patch :-( (overzealous spam filter).

> diff --git a/scripts/debian-rootfs.sh b/scripts/debian-rootfs.sh
> new file mode 100755
> index 000000000000..7cb8a96e39c0
> --- /dev/null
> +++ b/scripts/debian-rootfs.sh
...
> +PKGS=(
> +    # System
> +    bridge-utils
> +    dropbear
> +    udev
> +    systemd-sysv
> +    iproute2
> +    inetutils-ping
> +    util-linux
> +    cpio

Is `cpio` going to be used in dom0? The alpine rootfs don't have it.

> +# don't need persistent logging, avoid journal flush service
> +rmdir var/log/journal

I think this would better be done with:

    cat >> /etc/systemd/journald.conf.d/storage.conf <<EOF
    [Journal]
    Storage=volatile
    EOF

because I think systemd intend to change the behavior in future release,
and we are more explicit with a config file.

> +# Create rootfs
> +cd /
> +{
> +    PATHS="bin etc home init lib lib64 mnt opt root sbin srv tmp usr var"
> +    find $PATHS -print0
> +    echo -ne "dev\0proc\0run\0sys\0"
> +} | cpio -0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"

You should add "-R0:0" to the `cpio` command, like we do for the alpine
rootfs.

Thanks,


--
 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH test-artifacts v3 03/13] Add debian rootfs artifact

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 3250 bytes --]

On Wed, Apr 15, 2026 at 11:50:38AM +0000, Anthony PERARD wrote:
> I'm commenting on changes I found in the branch used by the pipeline
> linked in the cover leter, since there's no copy on the mailing list of
> the patch :-( (overzealous spam filter).
> 
> > diff --git a/scripts/debian-rootfs.sh b/scripts/debian-rootfs.sh
> > new file mode 100755
> > index 000000000000..7cb8a96e39c0
> > --- /dev/null
> > +++ b/scripts/debian-rootfs.sh
> ...
> > +PKGS=(
> > +    # System
> > +    bridge-utils
> > +    dropbear
> > +    udev
> > +    systemd-sysv
> > +    iproute2
> > +    inetutils-ping
> > +    util-linux
> > +    cpio
> 
> Is `cpio` going to be used in dom0? The alpine rootfs don't have it.

Alpine does have it, via busybox. That said, I don't see it used in any
current test.

> > +# don't need persistent logging, avoid journal flush service
> > +rmdir var/log/journal
> 
> I think this would better be done with:
> 
>     cat >> /etc/systemd/journald.conf.d/storage.conf <<EOF
>     [Journal]
>     Storage=volatile
>     EOF
> 
> because I think systemd intend to change the behavior in future release,
> and we are more explicit with a config file.

+1 

> > +# Create rootfs
> > +cd /
> > +{
> > +    PATHS="bin etc home init lib lib64 mnt opt root sbin srv tmp usr var"
> > +    find $PATHS -print0
> > +    echo -ne "dev\0proc\0run\0sys\0"
> > +} | cpio -0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
> 
> You should add "-R0:0" to the `cpio` command, like we do for the alpine
> rootfs.

Hm, I'm not sure if that's a good idea. There are a few intentionally
non-root files in Debian. Right now that is:

-rw-r-----   1 root     42            496 Apr  1 01:08 etc/gshadow
-rw-r-----   1 root     42            564 Apr  1 01:08 etc/shadow
-rw-r-----   1 root     42            444 Apr  1 01:08 etc/gshadow-
-rw-r-----   1 root     42            565 Apr  1 01:08 etc/shadow-
-rwxr-sr-x   1 root     42          31256 Apr 19  2025 usr/bin/expiry
-rwxr-sr-x   1 root     42         113848 Apr 19  2025 usr/bin/chage
-rwsr-xr--   1 root     printadm    51272 Mar  8  2025 usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwxr-sr-x   1 root     42          43256 Jun 29  2025 usr/sbin/unix_chkpwd
drwxr-xr-x   2 systemd- systemd-        0 Apr  1 01:08 var/lib/systemd/network
drwxr-xr-x   2 42       root            0 Apr  1 01:07 var/lib/apt/lists/auxfiles
drwx------   2 42       root            0 Apr  1 01:07 var/lib/apt/lists/partial
drwxrwsr-x   2 root     mem             0 Sep  8  2025 var/mail
-rw-rw-r--   1 root     43              0 Sep  8  2025 var/log/wtmp
-rw-rw-r--   1 root     43              0 Sep  8  2025 var/log/lastlog
-rw-rw----   1 root     43              0 Sep  8  2025 var/log/btmp
-rw-r-----   1 root     adm         31508 Apr  1 01:08 var/log/apt/term.log
drwx------   2 42       root            0 Apr  1 01:08 var/cache/apt/archives/partial

While it _might_ not explode right now if we reset it to root, it may
cause issues in the future (for example APT likes to run downloads as
unprivileged user, with write access only to
/var/lib/apt/lists/partial).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH test-artifacts v3 03/13] Add debian rootfs artifact

[Anthony PERARD]

[-- Attachment #1: Type: text/plain, Size: 3919 bytes --]

On Wed, Apr 15, 2026 at 07:59:34PM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 15, 2026 at 11:50:38AM +0000, Anthony PERARD wrote:
> > > diff --git a/scripts/debian-rootfs.sh b/scripts/debian-rootfs.sh
> > > new file mode 100755
> > > index 000000000000..7cb8a96e39c0
> > > --- /dev/null
> > > +++ b/scripts/debian-rootfs.sh
> > ...
> > > +PKGS=(
> > > +    # System
> > > +    bridge-utils
> > > +    dropbear
> > > +    udev
> > > +    systemd-sysv
> > > +    iproute2
> > > +    inetutils-ping
> > > +    util-linux
> > > +    cpio
> > 
> > Is `cpio` going to be used in dom0? The alpine rootfs don't have it.
> 
> Alpine does have it, via busybox. That said, I don't see it used in any
> current test.

Turns out I'm actually using `cpio` on the Alpine rootfs. But the only
reason is to work around a very slow download of the rootfs via the UEFI
firmware (and grub) of the machine. I just boot with a smaller rootfs,
then after Linux is started, I download the rootfs that only has the
xentool and extract it with `cpio`. (loading the full rootfs over
netboot takes about 15min on that machine)

> > > +# don't need persistent logging, avoid journal flush service
> > > +rmdir var/log/journal
> > 
> > I think this would better be done with:
> > 
> >     cat >> /etc/systemd/journald.conf.d/storage.conf <<EOF
> >     [Journal]
> >     Storage=volatile
> >     EOF
> > 
> > because I think systemd intend to change the behavior in future release,
> > and we are more explicit with a config file.
> 
> +1 
> 
> > > +# Create rootfs
> > > +cd /
> > > +{
> > > +    PATHS="bin etc home init lib lib64 mnt opt root sbin srv tmp usr var"
> > > +    find $PATHS -print0
> > > +    echo -ne "dev\0proc\0run\0sys\0"
> > > +} | cpio -0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
> > 
> > You should add "-R0:0" to the `cpio` command, like we do for the alpine
> > rootfs.
> 
> Hm, I'm not sure if that's a good idea. There are a few intentionally
> non-root files in Debian. Right now that is:
> 
> -rw-r-----   1 root     42            496 Apr  1 01:08 etc/gshadow
> -rw-r-----   1 root     42            564 Apr  1 01:08 etc/shadow
> -rw-r-----   1 root     42            444 Apr  1 01:08 etc/gshadow-
> -rw-r-----   1 root     42            565 Apr  1 01:08 etc/shadow-
> -rwxr-sr-x   1 root     42          31256 Apr 19  2025 usr/bin/expiry
> -rwxr-sr-x   1 root     42         113848 Apr 19  2025 usr/bin/chage
> -rwsr-xr--   1 root     printadm    51272 Mar  8  2025 usr/lib/dbus-1.0/dbus-daemon-launch-helper
> -rwxr-sr-x   1 root     42          43256 Jun 29  2025 usr/sbin/unix_chkpwd
> drwxr-xr-x   2 systemd- systemd-        0 Apr  1 01:08 var/lib/systemd/network
> drwxr-xr-x   2 42       root            0 Apr  1 01:07 var/lib/apt/lists/auxfiles
> drwx------   2 42       root            0 Apr  1 01:07 var/lib/apt/lists/partial
> drwxrwsr-x   2 root     mem             0 Sep  8  2025 var/mail
> -rw-rw-r--   1 root     43              0 Sep  8  2025 var/log/wtmp
> -rw-rw-r--   1 root     43              0 Sep  8  2025 var/log/lastlog
> -rw-rw----   1 root     43              0 Sep  8  2025 var/log/btmp
> -rw-r-----   1 root     adm         31508 Apr  1 01:08 var/log/apt/term.log
> drwx------   2 42       root            0 Apr  1 01:08 var/cache/apt/archives/partial
> 
> While it _might_ not explode right now if we reset it to root, it may
> cause issues in the future (for example APT likes to run downloads as
> unprivileged user, with write access only to
> /var/lib/apt/lists/partial).

Ah, right, "-R0:0" probably only make sense when we build Xen as a build
user.

So, with the change to journald config:
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Cheers,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech