Skip to content

Commit ec37401

Browse files
lkml-likexuLike Xu
lkml-likexu
and
Like Xu
authored
deploy/pvm: fix PVM kernel build on modern distros & make pvm_setup.sh re-runnable / single-sided (#112)
* deploy: fix "lz4c: command not found" when building PVM kernels The pvm_host config enables CONFIG_KERNEL_LZ4=y, and both pvm_host and pvm_guest enable CONFIG_RD_LZ4=y / CONFIG_HAVE_KERNEL_LZ4=y, which makes the kernel build invoke `lz4c` at link/packaging time. Modern distributions (recent Debian/Ubuntu, TencentOS/OpenCloudOS, etc.) ship only the `lz4` binary in their `lz4` package and no longer provide the legacy `lz4c` alias, so `build-pvm-host-kernel-pkg.sh` and `build-pvm-guest-vmlinux.sh` fail with: /bin/sh: lz4c: command not found Teach deploy/pvm/common.sh to guarantee `lz4c` availability: - Add the `lz4` package to install_deps_rpm / install_deps_deb and to the ensure_build_tools bootstrap lists (dnf/yum, apt-get, zypper), so normal runs pick it up automatically. - Introduce ensure_lz4c(): if `lz4c` is still missing after the package install (or when SKIP_DEPS=1), fall back to installing the `lz4` package directly and, as a last resort, drop a tiny /usr/local/bin/lz4c shim that execs the modern `lz4` binary. The shim keeps the kernel Makefiles working without patching the upstream source tree. - Call ensure_lz4c() at the end of ensure_build_tools() so both entry-point scripts (host package build and guest vmlinux build) pick up the fix with no changes of their own. Assisted-by: Anthropic:claude-opus-4-7 Signed-off-by: Like Xu <likexu@tencent.com> * deploy/pvm: install python3 so kernel libbpf builds don't fail with Error 127 Fresh RPM/DEB minimal environments (TencentOS Server 3.x, Debian 12 cloud, etc.) do not ship a python3 interpreter by default. When pvm_setup.sh drives the host/guest kernel builds on such a machine, the kernel's tools/bpf build aborts very early with a misleading error: fi; install -m 644 libbpf_legacy.h '...'/include/bpf' make[8]: *** [Makefile:160: .../libbpf/bpf_helper_defs.h] Error 127 make[7]: *** [Makefile:63: .../libbpf/libbpf.a] Error 2 make[6]: *** [Makefile:77: bpf/resolve_btfids] Error 2 make[5]: *** [Makefile:1376: tools/bpf/resolve_btfids] Error 2 make[3]: *** [debian/rules:25: build-arch] Error 2 The failing rule is tools/lib/bpf/Makefile:160, which generates bpf_helper_defs.h by invoking scripts/bpf_doc.py (shebang: "#!/usr/bin/env python3"). Error 127 means "command not found" and refers to the python3 interpreter, not to the `install` line that make happens to print right before it. Missing python3 then cascades into libbpf.a -> resolve_btfids -> vmlinux -> bindeb-pkg failures. Add python3 to every path that provisions build dependencies so the issue is fixed automatically on a fresh run, and also recovered from when users bypass the top-level installer with SKIP_DEPS=1: - common.sh: add python3 to install_deps_rpm / install_deps_deb. - common.sh: ensure_build_tools() now detects a missing python3 (with a comment explaining the misleading Error 127) and adds it to the dnf/yum, apt-get and zypper package lists used to bootstrap the toolchain. - pvm_setup.sh: add python3 to install_common_build_deps() for both the RPM and DEB branches, so the one-shot setup pre-installs it before the host and guest builds fan out in parallel. No other behaviour changes; existing callers, env overrides and the lz4/lz4c shim handling are untouched. Assisted-by: Anthropic:claude-opus-4-7 Signed-off-by: Like Xu <likexu@tencent.com> * deploy/pvm: make re-runs robust when BRANCH is a tag or a commit SHA clone_source() in deploy/pvm/common.sh silently assumes BRANCH is a branch name: after fetching, it dereferences origin/<BRANCH>. Since the kernel baseline was pinned to a release tag, a shallow tag fetch only advances FETCH_HEAD and creates no origin/<tag> ref, so the second (and every subsequent) run of pvm_setup.sh aborts inside the reset step, leaving the source tree in an indeterminate state for the rest of the build. The first run usually succeeds, so the failure only shows up on re-runs and looks like flaky behaviour. Make the update path treat BRANCH as an opaque git ref -- branch, tag, or bare commit SHA -- so re-runs always converge to the same commit regardless of what kind of ref the caller configured, and fail loudly with an actionable message when the ref cannot be resolved at all. Known limitations: - The fresh-clone path still goes through `git clone --branch`, which does not accept a bare commit SHA. BRANCH must therefore resolve to a named ref (branch or tag) on the first run; bare SHAs are only supported for subsequent updates of an existing tree. - The update path re-shallows on top of the existing clone. History older than the pinned commit is not reachable locally, which is intentional for build speed but means `git log` / `git bisect` inside ${SRC_DIR} are of limited use. - Switching REPO_URL between runs rewrites `origin` in place; any local changes or untracked files under ${SRC_DIR} are discarded by design to guarantee the tree matches the requested ref. Assisted-by: Anthropic:claude-opus-4-7 Signed-off-by: Like Xu <likexu@tencent.com> * deploy/pvm: let pvm_setup.sh build only the guest or only the host pvm_setup.sh has been strictly all-or-nothing: it always rebuilds both the pvm-host package and the pvm-guest vmlinux, then installs the host package, touches GRUB, wires up kvm_pvm auto-load and nudges the user to reboot. That shape is correct for a first-time bring-up but wrong for two common day-2 scenarios: * Refresh only the guest vmlinux on a node that is already running the desired pvm-host kernel. Rebuilding and reinstalling the host kernel in that case is at best noise and at worst dangerous, since the trailing REBOOT banner can trick an operator into rebooting a production node unnecessarily. * Rebuild only the pvm-host package on a node whose guest vmlinux is pinned and must not be overwritten, e.g. when validating a host-side kernel fix against a fixed guest image. Add first-class support for both modes through symmetric env vars and CLI flags, keeping the default (build both sides in parallel, install, place, prompt reboot) bit-for-bit unchanged. The end-of-run summary also adapts to the guest-only case so the reboot / GRUB cmdline reminder is suppressed when the running kernel was not touched. Per-side build logs are appended rather than overwritten, and single-sided runs additionally tee pvm_setup.sh's own output into the matching log so the file is a faithful transcript of the run; a per-run banner makes successive runs easy to tell apart. Known limitations: - The two skip knobs are mutually exclusive in practice: asking to skip both sides is accepted but degenerates into a no-op warning, since there is nothing left to do. - Guest-only runs deliberately do not touch GRUB_DEFAULT or /etc/modules-load.d/kvm_pvm.conf. A node that has never had the pvm-host package installed cannot be brought up with --guest-only alone; a prior full or --host-only run is required. - Host-only runs skip the placement step entirely, so the in-repo assets/ and cubetoolbox runtime vmlinux are left at whatever version a previous run (or manual copy) put there. Callers that need a matching guest image must run the guest side explicitly. - Log files are append-only from this script; there is no built-in rotation. Long-lived development hosts should rotate or truncate pvm-setup-{host,guest}-build.log out of band. - The redirect that captures pvm_setup.sh's own output into the per-side log is only installed for single-sided runs. A default (parallel) run still prints to the terminal only; its per-side build logs continue to live in the two build-dir log files as before. Assisted-by: Anthropic:claude-opus-4-7 Signed-off-by: Like Xu <likexu@tencent.com> * deploy/pvm: pin OpenCloudOS kernel builds to tag 6.6.69-1.cubesandbox The host/guest kernel build scripts currently clone the OpenCloudOS kernel tree at the moving branch linux-6.6/cube/pvm. Because that branch advances over time, consecutive runs of build-pvm-host-kernel-pkg.sh or build-pvm-guest-vmlinux.sh can pick up different source trees and produce non-reproducible artifacts; it also makes it harder to reason about which exact kernel a given CubeSandbox release was built against, and to match the in-tree pvm_host / pvm_guest .config files (which were derived from a specific snapshot) to the sources they were generated from. Pin both scripts, and the configs/README.md pointer that documents their provenance, to the released tag 6.6.69-1.cubesandbox instead of the branch. The default REPO_URL is unchanged, and BRANCH is still overridable via the environment for developers who need to track the tip of linux-6.6/cube/pvm. - build-pvm-host-kernel-pkg.sh: default BRANCH -> 6.6.69-1.cubesandbox - build-pvm-guest-vmlinux.sh: default BRANCH -> 6.6.69-1.cubesandbox - configs/README.md: document the tag as the config provenance Signed-off-by: Like Xu <likexu@tencent.com> --------- Signed-off-by: Like Xu <likexu@tencent.com> Co-authored-by: Like Xu <likexu@tencent.com>
1 parent 92d668c commit ec37401

5 files changed

Lines changed: 409 additions & 32 deletions

File tree

‎deploy/pvm/build-pvm-guest-vmlinux.sh‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
# ============================================================================
33
# build-pvm-guest-vmlinux.sh
44
#
5-
# Clone https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git (branch: linux-6.6/cube/pvm),
5+
# Clone https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git (tag: 6.6.69-1.cubesandbox),
66
# apply the pvm-guest kernel .config, and build only the vmlinux target
77
# (no RPM/DEB packaging, no kernel modules).
88
#
@@ -34,7 +34,7 @@ PVM_DEPS_LABEL="vmlinux only"
3434
PVM_TARGET_DESC="target system"
3535

3636
REPO_URL="${REPO_URL:-https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git}"
37-
BRANCH="${BRANCH:-linux-6.6/cube/pvm}"
37+
BRANCH="${BRANCH:-6.6.69-1.cubesandbox}"
3838
CONFIG_URL="${CONFIG_URL:-https://raw.githubusercontent.com/virt-pvm/misc/refs/heads/main/pvm-guest-6.12.33.config}"
3939
CONFIG_SHA256="${CONFIG_SHA256:-8e579bea756b6dadeff1203a5e4f3bba851a7426e4e50abd436575eddfa019f4}"
4040

‎deploy/pvm/build-pvm-host-kernel-pkg.sh‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
# build-pvm-host-kernel-pkg.sh
44
#
55
# Build the pvm-host kernel installation package:
6-
# - Clone https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git (branch: linux-6.6/cube/pvm)
6+
# - Clone https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git (tag: 6.6.69-1.cubesandbox)
77
# - Apply the pvm-host kernel .config
88
# - Build an RPM or DEB package depending on the host distribution family
99
#
@@ -34,7 +34,7 @@ PVM_CONFIG_NAME="pvm_host"
3434
PVM_TARGET_DESC="target host"
3535

3636
REPO_URL="${REPO_URL:-https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git}"
37-
BRANCH="${BRANCH:-linux-6.6/cube/pvm}"
37+
BRANCH="${BRANCH:-6.6.69-1.cubesandbox}"
3838
CONFIG_URL="${CONFIG_URL:-https://raw.githubusercontent.com/virt-pvm/misc/refs/heads/main/pvm-host-6.12.33.config}"
3939
CONFIG_SHA256="${CONFIG_SHA256:-edc1965a48fbe972ee6eb3d1be96de3d0fd00c1edfe665974330dea819545e00}"
4040

‎deploy/pvm/common.sh‎

Lines changed: 160 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -86,6 +86,65 @@ dnf_install_with_retry() {
8686
return 1
8787
}
8888

89+
# Some kernel configs (e.g. CONFIG_KERNEL_LZ4=y, CONFIG_RD_LZ4=y,
90+
# CONFIG_HAVE_KERNEL_LZ4=y in our pvm_host / pvm_guest) make the build invoke
91+
# `lz4c` at link/packaging time. Modern distros often only ship the `lz4`
92+
# command (in the `lz4` package) and no longer create the `lz4c` alias, which
93+
# causes the kernel build to fail with: "lz4c: command not found".
94+
#
95+
# This helper makes sure:
96+
# 1. The `lz4` package is installed (so that an `lz4` / `lz4c` binary exists).
97+
# 2. If only `lz4` is available, a thin `lz4c` shim is created in
98+
# /usr/local/bin that forwards to `lz4`, keeping the kernel Makefiles
99+
# happy without patching the source tree.
100+
ensure_lz4c() {
101+
if command -v lz4c >/dev/null 2>&1; then
102+
return 0
103+
fi
104+
105+
if ! command -v lz4 >/dev/null 2>&1; then
106+
log "Installing 'lz4' package to provide lz4c/lz4 (required by CONFIG_KERNEL_LZ4 / CONFIG_RD_LZ4)"
107+
if command -v dnf >/dev/null 2>&1; then
108+
${SUDO} dnf install -y lz4 || warn "dnf failed to install lz4"
109+
elif command -v yum >/dev/null 2>&1; then
110+
${SUDO} yum install -y lz4 || warn "yum failed to install lz4"
111+
elif command -v apt-get >/dev/null 2>&1; then
112+
${SUDO} apt-get update -y || true
113+
${SUDO} apt-get install -y lz4 || warn "apt-get failed to install lz4"
114+
elif command -v zypper >/dev/null 2>&1; then
115+
${SUDO} zypper --non-interactive install lz4 || warn "zypper failed to install lz4"
116+
else
117+
warn "No supported package manager found to install 'lz4'; build may fail with 'lz4c: command not found'"
118+
fi
119+
fi
120+
121+
if command -v lz4c >/dev/null 2>&1; then
122+
return 0
123+
fi
124+
125+
if command -v lz4 >/dev/null 2>&1; then
126+
local lz4_bin shim="/usr/local/bin/lz4c"
127+
lz4_bin="$(command -v lz4)"
128+
log "Creating lz4c -> ${lz4_bin} compatibility shim at ${shim}"
129+
${SUDO} mkdir -p /usr/local/bin
130+
if ${SUDO} bash -c "cat > '${shim}' <<'EOS'
131+
#!/bin/sh
132+
# Auto-generated by deploy/pvm/common.sh: ensure_lz4c()
133+
# Forward all arguments to the modern 'lz4' binary, which understands the
134+
# same CLI flags that the kernel build uses (-l / -c0 / -c1 / -c9 ...).
135+
exec '${lz4_bin}' \"\$@\"
136+
EOS"; then
137+
${SUDO} chmod +x "${shim}"
138+
else
139+
warn "Failed to create ${shim}; kernel build may still fail with 'lz4c: command not found'"
140+
fi
141+
fi
142+
143+
if ! command -v lz4c >/dev/null 2>&1; then
144+
warn "lz4c is still not available; kernels with CONFIG_KERNEL_LZ4=y may fail to build"
145+
fi
146+
}
147+
89148
ensure_build_tools() {
90149
local need_pkgs=()
91150
command -v make >/dev/null 2>&1 || need_pkgs+=(make)
@@ -95,8 +154,24 @@ ensure_build_tools() {
95154
command -v bc >/dev/null 2>&1 || need_pkgs+=(bc)
96155
command -v bison >/dev/null 2>&1 || need_pkgs+=(bison)
97156
command -v flex >/dev/null 2>&1 || need_pkgs+=(flex)
157+
if ! command -v lz4c >/dev/null 2>&1 && ! command -v lz4 >/dev/null 2>&1; then
158+
need_pkgs+=(lz4)
159+
fi
160+
# The kernel's libbpf / tools/bpf build invokes scripts/bpf_doc.py
161+
# (shebang: /usr/bin/env python3) to generate bpf_helper_defs.h. Without
162+
# python3 this fails with a very misleading:
163+
# install -m 644 libbpf_legacy.h ...
164+
# make[8]: *** [Makefile:160: .../libbpf/bpf_helper_defs.h] Error 127
165+
# (Error 127 = command not found, referring to the python3 interpreter
166+
# that runs bpf_doc.py, not to `install`.)
167+
if ! command -v python3 >/dev/null 2>&1; then
168+
need_pkgs+=(python3)
169+
fi
98170

99-
[[ ${#need_pkgs[@]} -eq 0 ]] && return 0
171+
if [[ ${#need_pkgs[@]} -eq 0 ]]; then
172+
ensure_lz4c
173+
return 0
174+
fi
100175

101176
log "Bootstrapping missing build tools (commands): ${need_pkgs[*]}"
102177

@@ -107,7 +182,8 @@ ensure_build_tools() {
107182
make gcc gcc-c++ bc bison flex
108183
elfutils-libelf-devel openssl-devel
109184
perl-core ncurses-devel
110-
dwarves cpio tar xz which findutils hostname
185+
dwarves cpio tar xz which findutils hostname lz4
186+
python3
111187
)
112188
if [[ "${PVM_BUILD_PROFILE:-}" == "host" ]]; then
113189
rpm_pkgs+=(rpm-build rsync)
@@ -119,7 +195,8 @@ ensure_build_tools() {
119195
local deb_pkgs=(
120196
build-essential make bc bison flex
121197
libelf-dev libssl-dev libncurses-dev
122-
dwarves cpio kmod
198+
dwarves cpio kmod lz4
199+
python3
123200
)
124201
if [[ "${PVM_BUILD_PROFILE:-}" == "host" ]]; then
125202
deb_pkgs+=(fakeroot rsync dpkg-dev debhelper)
@@ -130,7 +207,8 @@ ensure_build_tools() {
130207
local zypper_pkgs=(
131208
make gcc gcc-c++ bc bison flex
132209
libelf-devel libopenssl-devel ncurses-devel
133-
dwarves cpio
210+
dwarves cpio lz4
211+
python3
134212
)
135213
if [[ "${PVM_BUILD_PROFILE:-}" == "host" ]]; then
136214
zypper_pkgs+=(rpm-build rsync)
@@ -148,6 +226,11 @@ ensure_build_tools() {
148226
exit 1
149227
fi
150228
done
229+
230+
# Kernels with CONFIG_KERNEL_LZ4 / CONFIG_RD_LZ4 enabled need the `lz4c`
231+
# command at build time; make sure it's available (installing `lz4` and
232+
# falling back to a shim if the distro only ships `lz4`).
233+
ensure_lz4c
151234
}
152235

153236
detect_family() {
@@ -204,7 +287,8 @@ install_deps_rpm() {
204287
elfutils-libelf-devel openssl-devel
205288
perl-core ncurses-devel
206289
dwarves cpio tar xz which findutils
207-
hostname wget rsync
290+
hostname wget rsync lz4
291+
python3
208292
)
209293
if [[ "${PVM_BUILD_PROFILE:-}" == "host" ]]; then
210294
pkgs+=(rpm-build)
@@ -220,7 +304,8 @@ install_deps_deb() {
220304
git build-essential bc bison flex
221305
libelf-dev libssl-dev libncurses-dev
222306
dwarves cpio kmod
223-
wget ca-certificates
307+
wget ca-certificates lz4
308+
python3
224309
)
225310
if [[ "${PVM_BUILD_PROFILE:-}" == "host" ]]; then
226311
pkgs+=(fakeroot rsync dpkg-dev debhelper)
@@ -245,13 +330,77 @@ install_deps() {
245330

246331
clone_source() {
247332
mkdir -p "${WORK_DIR}"
333+
334+
# BRANCH can be any of: a branch name, a tag name, or a commit SHA.
335+
# The previous implementation assumed a branch name and referenced
336+
# `origin/${BRANCH}` after fetch, which breaks on a second run when
337+
# BRANCH is actually a tag: `git fetch --depth=1 origin <tag>` only
338+
# updates FETCH_HEAD and does NOT create a remote-tracking ref
339+
# `refs/remotes/origin/<tag>`, so `git reset --hard origin/<tag>`
340+
# fails with
341+
# fatal: ambiguous argument 'origin/<tag>': unknown revision ...
342+
#
343+
# Instead, fetch and then pin to the concrete SHA resolved via
344+
# FETCH_HEAD. That works uniformly for branches, tags and commit
345+
# SHAs, and is also correct on shallow clones.
248346
if [[ -d "${SRC_DIR}/.git" ]]; then
249-
log "Source tree already exists at ${SRC_DIR}; updating..."
250-
git -C "${SRC_DIR}" fetch --depth=1 origin "${BRANCH}"
251-
git -C "${SRC_DIR}" checkout "${BRANCH}"
252-
git -C "${SRC_DIR}" reset --hard "origin/${BRANCH}"
347+
log "Source tree already exists at ${SRC_DIR}; updating to ${BRANCH} ..."
348+
349+
# Make sure we're pointing at the configured remote; if someone
350+
# hand-edited .git/config or re-ran with a different REPO_URL,
351+
# update it so we don't silently fetch from the wrong place.
352+
local current_url=""
353+
current_url="$(git -C "${SRC_DIR}" remote get-url origin 2>/dev/null || true)"
354+
if [[ -z "${current_url}" ]]; then
355+
git -C "${SRC_DIR}" remote add origin "${REPO_URL}"
356+
elif [[ "${current_url}" != "${REPO_URL}" ]]; then
357+
warn "origin URL differs (${current_url} -> ${REPO_URL}); updating."
358+
git -C "${SRC_DIR}" remote set-url origin "${REPO_URL}"
359+
fi
360+
361+
# Fetch the requested ref together with its tags. --depth=1 keeps
362+
# things cheap; if a previous run left a deeper history behind,
363+
# this will simply shallow-fetch on top of it (harmless).
364+
if ! git -C "${SRC_DIR}" fetch --depth=1 --tags --force origin "${BRANCH}"; then
365+
# Some remotes won't accept a direct SHA in refspec position
366+
# on a shallow clone; fall back to fetching everything the
367+
# remote advertises and resolving locally.
368+
warn "Targeted fetch of '${BRANCH}' failed; retrying with a generic fetch."
369+
git -C "${SRC_DIR}" fetch --depth=1 --tags --force origin
370+
fi
371+
372+
# Resolve BRANCH to a concrete commit SHA without relying on
373+
# refs/remotes/origin/<name> existing.
374+
local target_sha=""
375+
if target_sha="$(git -C "${SRC_DIR}" rev-parse --verify -q FETCH_HEAD)"; then
376+
:
377+
elif target_sha="$(git -C "${SRC_DIR}" rev-parse --verify -q "refs/tags/${BRANCH}")"; then
378+
:
379+
elif target_sha="$(git -C "${SRC_DIR}" rev-parse --verify -q "refs/remotes/origin/${BRANCH}")"; then
380+
:
381+
elif target_sha="$(git -C "${SRC_DIR}" rev-parse --verify -q "${BRANCH}^{commit}")"; then
382+
:
383+
else
384+
err "Could not resolve '${BRANCH}' to a commit in ${SRC_DIR}."
385+
err "Tried: FETCH_HEAD, refs/tags/${BRANCH}, refs/remotes/origin/${BRANCH}, ${BRANCH}."
386+
exit 1
387+
fi
388+
389+
log "Resolved '${BRANCH}' to ${target_sha}; checking out."
390+
# Detach to the SHA: idempotent for branches/tags/SHAs alike, and
391+
# never fails because of a pre-existing local branch with the
392+
# same name pointing elsewhere.
393+
git -C "${SRC_DIR}" checkout --detach --quiet "${target_sha}"
394+
git -C "${SRC_DIR}" reset --hard "${target_sha}"
395+
# Drop any untracked leftovers from a previous, possibly failed
396+
# build so the tree really is at `${target_sha}` and nothing else.
397+
git -C "${SRC_DIR}" clean -fdx
253398
else
254-
log "Cloning ${REPO_URL} (branch ${BRANCH}) into ${SRC_DIR} ..."
399+
log "Cloning ${REPO_URL} (ref ${BRANCH}) into ${SRC_DIR} ..."
400+
# `git clone --branch` accepts either a branch or a tag name, so
401+
# this single line handles both; it does not accept bare commit
402+
# SHAs, but REPO_URL+BRANCH combos consumed by this script always
403+
# resolve to a named ref.
255404
git clone --depth=1 --branch "${BRANCH}" "${REPO_URL}" "${SRC_DIR}"
256405
fi
257406
}

‎deploy/pvm/configs/README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@ build scripts:
1111
The configs are kept in-tree so the default build path is reproducible and
1212
works in offline or air-gapped environments. They are derived from the PVM
1313
kernel tree used by these scripts (`https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git`,
14-
branch `linux-6.6/cube/pvm`) and the upstream reference configs published by
14+
tag `6.6.69-1.cubesandbox`) and the upstream reference configs published by
1515
the virt-pvm project:
1616

1717
- `https://raw.githubusercontent.com/virt-pvm/misc/refs/heads/main/pvm-host-6.12.33.config`

0 commit comments

Comments
 (0)