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)
As of commit b49b623a ("discord: use distro layout for stable on Linux", PR #515876),
Discord's launch script runs a `discord-stage-modules` script defined in `linux.nix`,
which creates symlinks from `~/.config/discord/<version>/modules/<module_name>`
to the corresponding Nix store paths so Discord can find them.
It checks whether this has already been done by looking for `installed.json` in the same dir,
which it also creates, and skips link creation if so.
However, since the dir is indexed by Discord version number,
the links are not refreshed when opening a new build of Discord with the same version number as an older build.
If the old build is then GC'd, the links break and Discord fails to start
with an error such as `Cannot find module 'discord_desktop_core'`.
Deleting the module folder entirely allows for it to be recreated and for Discord to start without issue.
This problem and solution are attested on the wiki, albeit with less explanation:
https://wiki.nixos.org/wiki/Discord#Crash_on_start-up.
The package fix is to delete and recreate the `modules` folder on each launch,
as it is small and does not contain any data meant to persist between launches:
it has only the module links, `installed.json`, and a `pending/` download directory
recreated by Discord's updater on startup.
The fix ensures that the links always point to the Nix store of the build of Discord being run,
so they will not be broken by GC.
Assisted-by: Claude Fable 5 in Claude Code
In 0.101 & on non-macOS builds, Factor added a .out extension to
deployments. The current Nix derivation is built with path assumptions
in mind. Rather than running switch-cases on versions+OS or relying on
globbing in the shell scripts, the deploy script has been modified to
print its resolved deploy path to a file so that the build can continue
knowing exactly where the files are / should go. This handles both with
& without .out extension as the tests pass on 0.99, 0.100, & 0.101.
tree-sitter can highlight these (& more depending on editor setup), &
for the rest of users, it’s still an annotation that helps keep track of
what language we are working in.
Commit 88cfc54552 ("nix-prefetch-git: disable maintenance mode via
environment variables") disabled maintenance.auto (git's new
auto-maintenance) via GIT_CONFIG_*, which propagates to submodules. But
the legacy auto-gc path (gc.auto plus detached gc.autoDetach) is still
enabled, and it keeps repacking .git/modules/<sub>/objects after a nested
submodule reports "checked out", racing the later `rm -rf .git`:
- rm empties objects/pack, the detached gc drops a fresh pack in, and
rmdir fails with "Directory not empty" (exit 123); or
- removal partially completes, leaving varying .git remnants, yielding a
non-deterministic NAR hash.
Disable gc.auto/gc.autoDetach alongside maintenance.auto, using the same
GIT_CONFIG_* mechanism so the settings reach every git invocation and its
children (including nested submodule fetches). Fold the repeated
boilerplate into a small git_config_env helper.
The successful output is unchanged (.git is removed either way), so
pinned fetchgit hashes stay valid; this only makes removal deterministic.
Fixes#524215.
Assisted-by: Claude Code (claude-opus-4-8)
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.
Philip Taron