The previous commit split the module tree out of `kernel` into a new
`kernelModules` argument, but only updated the initrd modules closure.
Two other places still referenced `kernel` for modules:
* `MODULE_DIR` in stage2Init, which backs both the kernel automatic
module loader (/proc/sys/kernel/modprobe) and any explicit modprobe
run inside the VM;
* the `/lib` symlinks in extractFs and extractMTDfs.
Before the split these pointed at the aggregated tree whenever callers
overrode `kernel` with one, so e.g. `modprobe zfs` inside the VM found
the out-of-tree module. Verified by running modprobe of a module
present only in `kernelModules` inside runInLinuxVM: it fails with
"FATAL: Module zfs not found" before this change and succeeds after.
Assisted-by: Claude Code (claude-fable-5)
Commit 31d1d80b3f ("lib/systems: move kernel configuration out of
the platform structure") changed all-packages.nix from
vmTools = callPackage ../build-support/vm {
img = stdenv.hostPlatform.linux-kernel.target;
};
to
vmTools = callPackage ../build-support/vm { };
and changed the function default to `img ? kernel.target`. Since
`pkgs.img` exists, `callPackage` now auto-fills the `img` argument
with that attribute and the default is never used.
Anything going through `runInLinuxVM` (make-disk-image,
nixosTests.bootspec.*, etc.) then fails with:
qemu: could not open kernel file
'/nix/store/...-linux-.../...-img-0.5.11': No such file or directory
Rename `img` to `kernelImage` so it no longer collides with a
top-level package.
The same commit also broke callers that override `kernel` with an
`aggregateModules` tree (the in-tree zfs image builders, disko), since
that has no `.target`. The single `kernel` argument was being used for
two unrelated things: the boot image for `qemu -kernel` and the module
tree for the initrd. Split the latter out into a new `kernelModules`
argument (defaulting to `kernel`), point the zfs image builders at it,
and throw a clear error explaining the migration when `kernel.target`
is missing.
Currently, you need to override `stdenv.hostPlatform` to request a
compressed kernel on AArch64, and the kernel configuration is split
between the central structured configuration and string snippets in
platform definitions. This has consequently made the latter bitrot
terribly. Since the platform‐specific logic is now very limited after
cleaning up the detritus, we can move it into the kernel derivation
and expose the relevant configuration there for anyone who wants to
customize it further or needs to read it out.
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
Adds `ubuntu2604x86_64` to the VM disk image definitions using a
snapshot from 2026-05-15, along with a corresponding test target
`testUbuntu2604x86_64Image` in test.nix.
debsGrouped was a nested array, like `[ [ drv1 drv2 ] [ drv3 ] ... ]`.
that doesn't map to any bash item, so it would live only in the json attrs.
the `for component in "${debsGrouped[@]}"; ...` part of buildCommand
was thus referring to an unset variable... but the default bash behavior
is to treat that as an empty array even with `set -u` so the loop was
just doing nothing.
instead, flatten the array on the nix side. bash gets something like
`("drv1 drv2" "drv3" ...)` and the existing shell code destructures
that as expected.
verify by building a vm (e.g.
`tests.vmTools.buildPatchelfInDebian.diskImage`) and checking the
nix-log before and after for `INSTALLING COMPONENT` messages.
Co-Authored-By: Stefan Frijters <sfrijters@gmail.com>
After __structuredAttrs was enabled in runInLinuxVM, the structure
of 'debs' matters.
The current implementation uses some IFS tricks so we just flatten into a string.
Future improvements could include treating debs as a list in a more
structured way.
Newer kernels do not have a module called `crc32c_generic`, however the
module alias `crc32` points to the right thing on kernels from 5.10 and
onward.
Amazon Linux 2023 uses GUID-based URLs that don't allow directory
listing, making updates non-trivial. Add a comment explaining how to
find the current GUID by either running an AL2023 container or checking
the docker-library/repo-info repository.
Oracle provides versioned URLs for baseos but not appstream. Since we
can't mix versioned baseos with rolling appstream due to package version
dependencies (glibc mismatch), we keep using rolling URLs for both.
Add comment explaining this limitation.
The repo.almalinux.org URLs are rolling and change with each minor
release, causing hash mismatches. Switch to vault.almalinux.org which
provides stable URLs for specific versions.
- alma9x86_64: use vault 9.6
- alma10x86_64: use vault 10.0
The sleep command is not a bash built-in, so when a VM does not have
coreutils in their PATH this script will break. The fix is to refer to
it directly.
Signed-off-by: Marcel Müller <neikos@neikos.email>
SandaruKasa