Repository navigation
virtio-linux-detonation: 6.18.36 -> 6.18.42 (six LTS releases of fixes) - #583
Merged
Merged
Conversation
This package was UPDATE-DARK until yesterday: no source_provenance, no
repology_project, and it was missing from the kernel-LTS override arm, so
`check` reported "no upstream source found" and SKIPPED it. It could never be
offered a bump and nothing said so. supply-chain#391 routed it; this is the
bump that was waiting behind it.
Six point releases behind (6.18.42 shipped 2026-08-03).
## Not 7.x, deliberately
The instinct to move to the newest series is reasonable and wrong here:
kernel.org lists 7.1.6 as `stable` and marks exactly six lines `longterm` —
6.18, 6.12, 6.6, 6.1, 5.15, 5.10. **6.18 IS the newest longterm**, i.e. the line
this package is already on. Moving to 7.1 would leave LTS for a line that dies
when 7.2 ships (7.2-rc6 tagged 2026-08-02), buying a newer BPF verifier the
observer has no demonstrated need for in exchange for a two-arch config + boot
revalidation every ~9 weeks. Revisit when a 7.x line is marked longterm —
historically the last release of the calendar year.
## Risk read
sha256 read from kernel.org's SIGNED sha256sums.asc; the currently-pinned
6.18.36 digest matches that same file exactly, which validates the read.
Diffed the six incremental patches (36->42, 141k lines) against what this build
actually depends on:
- the four files the build starts from are UNTOUCHED:
arch/x86/configs/{x86_64_,}defconfig, arch/arm64/configs/defconfig,
kernel/configs/kvm_guest.config
- NONE of the 14 CONFIG_ symbols the build sets or asserts was removed or
renamed — this matters because `scripts/config --enable` on an unknown
symbol is a SILENT no-op
- the LSM hook table did change, but purely ADDITIVELY: new
backing_file_alloc / backing_file_free / mmap_backing_file hooks and BTF
plumbing in kernel/bpf/bpf_lsm.c. No removals or renames of file_open /
bprm_* / socket_*, and no change to BPF_MAP_TYPE_RINGBUF — the surface the
in-VM observer attaches through is intact.
build.ncl only. No build.sh change, no CONFIG_ change.
## Verification
Built in a clean session (arm64: BTFIDS + Image.gz produced, so pahole handled
BTF against the new tree) and `min check`: 15/15 Pass.
Note that `standalone tests...Pass` is worth nothing for this package — it has
NO tests. The real gate is build.sh:219, which fails the build outright if any
of BPF_LSM / DEBUG_INFO_BTF / AUDIT / DYNAMIC_FTRACE_WITH_ARGS /
FTRACE_SYSCALLS fails to survive olddefconfig. That assertion passing IS the
evidence the observability config landed on 6.18.42.
Left for separate PRs, deliberately:
- four dead CONFIG names in build.sh (VIRTIO_SCSI/VIRTIO_GPU should be
SCSI_VIRTIO/DRM_VIRTIO_GPU) — that CHANGES the arm64 kernel's contents and
must not ride a version bump
- the missing tests
Contributor
📝 WalkthroughWalkthroughThe virtio Linux package updates its kernel baseline from 6.18.36 to 6.18.42, replaces the source archive checksum, and revises the longterm-status comments. ChangesKernel update
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/virtio-linux-detonation/build.ncl (1)
17-18: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winKeep the kernel baseline documentation consistent.
packages/virtio-linux-detonation/build.shstill says that this package uses the same6.12.43source asvirtio-linux. This declaration now targets the6.18line. Update the companion comment or remove the stale fixed version.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/virtio-linux-detonation/build.ncl` around lines 17 - 18, Update the kernel baseline comment in build.ncl to document the 6.18 line consistently with the package’s current target, or remove the stale fixed 6.12.43 reference; keep the surrounding BPF verifier and longterm-kernel context accurate.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/virtio-linux-detonation/build.ncl`:
- Around line 17-18: Update the kernel baseline comment in build.ncl to document
the 6.18 line consistently with the package’s current target, or remove the
stale fixed 6.12.43 reference; keep the surrounding BPF verifier and
longterm-kernel context accurate.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 5ac307e8-1058-41d7-bbb9-1a33513a49d3
📒 Files selected for processing (1)
packages/virtio-linux-detonation/build.ncl
twitchyliquid64
approved these changes
Aug 7, 2026
8000
motdotla
pushed a commit
to motdotla/pkgs
that referenced
this pull request
Aug 27, 2026
…tpoint (gominimal#365) * microvm-rootfs: ship e2fsprogs + util-linux and /var/lib/minimal mountpoint Unblocks Unit 1 of the per-VM writable ext4 volume spec (gominimal/minimal gominimal#583, PR gominimal#658 R1.7). The guest minimald mounts a per-VM writable volume (/dev/vdb) at /var/lib/minimal, formats it with mkfs.ext4 on first boot, and reclaims space via discard/fstrim. The rootfs was missing all three pieces: - Promote e2fsprogs from a build-only dep (its files were stripped from the image) to the runtime closure, so mkfs.ext4/mke2fs ship in the guest. mke2fs stays on the build PATH via the injected runtime closure, so it still packs the image — the separate build_deps entry is now redundant and removed. - Add util-linux to the runtime closure for fstrim (space reclaim). - Stage /var/lib/minimal as an empty directory. The root is mounted read-only, so minimald cannot mkdir the mountpoint at runtime; it must ship in the image or the mount fails with ENOENT/EROFS. Image stays raw ext4 (rootfs.img); size grows ~26 MiB (from ~444 MB to ~472 MB). Verified in the built image: /var/lib/minimal is empty, mkfs.ext4 -V and fstrim --help resolve, filesystem TYPE=ext4. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * microvm-rootfs: canonicalize libblkid/libuuid to util-linux's versioned libs e2fsprogs and util-linux both ship a libblkid.so.1 and libuuid.so.1 with the same soname; the staging composition resolved them to e2fsprogs's older, unversioned forks. util-linux's libmount then loaded those and warned "libblkid.so.1: no version information available" on every fstrim/mount/blkid. Repoint both sonames at util-linux's versioned libs (an ABI superset — e2fsprogs's own mke2fs/e2fsck link them fine, verified by running a real mkfs.ext4 format) and drop the e2fsprogs forks. A guard fails the build if a package bump renames the util-linux targets so this can't silently regress. Verified in the rebuilt image: fstrim --help and mount -V emit zero stderr lines, mkfs.ext4 -V still resolves. Net image size drops ~175 KB. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
motdotla
pushed a commit
to motdotla/pkgs
that referenced
this pull request
Aug 27, 2026
…ominimal#366) * microvm-rootfs: ship e2fsprogs + util-linux and /var/lib/minimal mountpoint Unblocks Unit 1 of the per-VM writable ext4 volume spec (gominimal/minimal gominimal#583, PR gominimal#658 R1.7). The guest minimald mounts a per-VM writable volume (/dev/vdb) at /var/lib/minimal, formats it with mkfs.ext4 on first boot, and reclaims space via discard/fstrim. The rootfs was missing all three pieces: - Promote e2fsprogs from a build-only dep (its files were stripped from the image) to the runtime closure, so mkfs.ext4/mke2fs ship in the guest. mke2fs stays on the build PATH via the injected runtime closure, so it still packs the image — the separate build_deps entry is now redundant and removed. - Add util-linux to the runtime closure for fstrim (space reclaim). - Stage /var/lib/minimal as an empty directory. The root is mounted read-only, so minimald cannot mkdir the mountpoint at runtime; it must ship in the image or the mount fails with ENOENT/EROFS. Image stays raw ext4 (rootfs.img); size grows ~26 MiB (from ~444 MB to ~472 MB). Verified in the built image: /var/lib/minimal is empty, mkfs.ext4 -V and fstrim --help resolve, filesystem TYPE=ext4. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * microvm-rootfs: canonicalize libblkid/libuuid to util-linux's versioned libs e2fsprogs and util-linux both ship a libblkid.so.1 and libuuid.so.1 with the same soname; the staging composition resolved them to e2fsprogs's older, unversioned forks. util-linux's libmount then loaded those and warned "libblkid.so.1: no version information available" on every fstrim/mount/blkid. Repoint both sonames at util-linux's versioned libs (an ABI superset — e2fsprogs's own mke2fs/e2fsck link them fine, verified by running a real mkfs.ext4 format) and drop the e2fsprogs forks. A guard fails the build if a package bump renames the util-linux targets so this can't silently regress. Verified in the rebuilt image: fstrim --help and mount -V emit zero stderr lines, mkfs.ext4 -V still resolves. Net image size drops ~175 KB. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * e2fsprogs: defer libblkid/libuuid to util-linux (drop bundled forks) e2fsprogs bundles its own older forks of libblkid and libuuid with the same soname (libblkid.so.1, libuuid.so.1) as util-linux's maintained, symbol- versioned libraries. Any image that ships both — like microvm-rootfs — has the dynamic loader resolve util-linux's libmount against the wrong libblkid, warning "libblkid.so.1: no version information available" on every fstrim/mount/blkid. Configure e2fsprogs with --disable-libblkid --disable-libuuid --disable-uuidd (the standard distro config) so its tools link util-linux's libs — an ABI superset, verified by building and running a real mkfs.ext4 format + fsck.ext4 against them. e2fsprogs now builds no libblkid/libuuid/blkid/findfs/uuidgen; util-linux is the sole provider. pkgconf is added to build_deps because configure locates the system libs via pkg-config, and util-linux to build+ runtime deps. Cycle-safe: microvm-rootfs is the only importer of e2fsprogs, so nothing in util-linux's closure can reach it. This makes the microvm-rootfs libblkid/libuuid symlink-repointing hack from the previous commit redundant, so it's removed — the guest now gets a single, correct libblkid/libuuid and util-linux's modern blkid binary with no build.sh fixups. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * e2fsprogs: subset util-linux to libblkid/libuuid in runtime_deps Address CodeRabbit review on gominimal#366: e2fsprogs's tools only DT_NEED libblkid.so.1 and libuuid.so.1 from util-linux at runtime, so pull just those two outputs via subsetOf instead of the whole ~18 MB toolset — consumers of e2fsprogs no longer transitively inherit all of util-linux. build_deps keeps the full util-linux: configure detects the libs via pkg-config and needs the headers + .pc files (OutputData outputs, which subsetOf does not support), and build_deps do not propagate to consumers' runtime closures. Verified: min check missing_runtime_deps passes (DT_NEEDED satisfied by the subset), and the microvm-rootfs guest still has a single util-linux libblkid/libuuid, modern blkid, and a clean mkfs.ext4 + fsck.ext4. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This package was update-dark until yesterday: no
source_provenance, norepology_project, and missing from the kernel-LTS override arm — socheckreported "no upstream source found" and skipped it. It could never be offered a bump and nothing said so. gominimal/minimal-supply-chain#391 routed it; this is the bump that was waiting behind it.Six point releases behind — 6.18.42 shipped 2026-08-03.
Not 7.x, deliberately
Moving to the newest series is a reasonable instinct and wrong here. kernel.org lists 7.1.6 as
stableand marks exactly six lineslongterm: 6.18, 6.12, 6.6, 6.1, 5.15, 5.10.6.18 IS the newest longterm — the line this package is already on. Moving to 7.1 would leave LTS for a line that dies when 7.2 ships (7.2-rc6 tagged 2026-08-02), buying a newer BPF verifier the observer has no demonstrated need for, in exchange for a two-arch config + boot revalidation every ~9 weeks. Revisit when a 7.x line is marked longterm — historically the last release of the calendar year.
Risk read
sha256 read from kernel.org's signed
sha256sums.asc. The currently-pinned 6.18.36 digest matches that same file exactly, which validates the read.Diffed all six incremental patches (36→42, 141k lines) against what this build actually depends on:
arch/x86/configs/{x86_64_,}defconfig,arch/arm64/configs/defconfig,kernel/configs/kvm_guest.configscripts/config --enableon an unknown symbol is a silent no-op — a rename would produce an observability-blind kernel that builds perfectly.backing_file_alloc/backing_file_free/mmap_backing_filehooks plus BTF plumbing inkernel/bpf/bpf_lsm.c. No removals or renames offile_open/bprm_*/socket_*, and no change toBPF_MAP_TYPE_RINGBUF— the surface the in-VM observer attaches through is intact.build.ncl only. No build.sh change, no CONFIG_ change.
Verification
Built in a clean session — arm64 produced
BTFIDS+Image.gz, so pahole handled BTF against the new tree — andmin check: 15/15 Pass.Worth being explicit:
standalone tests...Passis worth nothing here, because this package has no tests. The real gate isbuild.sh:219, which fails the build outright if any ofBPF_LSM/DEBUG_INFO_BTF/AUDIT/DYNAMIC_FTRACE_WITH_ARGS/FTRACE_SYSCALLSfails to surviveolddefconfig. That assertion passing is the actual evidence the observability config landed on 6.18.42.Deliberately left for separate PRs
VIRTIO_SCSI/VIRTIO_GPUshould beSCSI_VIRTIO/DRM_VIRTIO_GPU, so arm64 currently ships without virtio-scsi and virtio-gpu (x86 masks it becausex86_64_defconfigsets both independently). Fixing that changes the arm64 kernel's contents and must not ride a version bump.Summary by CodeRabbit