Among other things fixes build failure on linux-headers-5.17:
../src/basic/meson.build:389:8: ERROR: Problem encountered: found unknown filesystem(s) defined in kernel headers:
Filesystem found in kernel header but not in filesystems-gperf.gperf: CIFS_SUPER_MAGIC
Filesystem found in kernel header but not in filesystems-gperf.gperf: SMB2_SUPER_MAGIC
> Some bootloaders can provide entropy to increase the kernel's initial device randomness.
This allows, for example, EFI to provide 64 bytes. In general my opinion is an attacker
who can manipulate the random seed sufficiently to cause problems likely has other,
more direct approaches at their disposal as well.
When a NixOS system uses flakes, i.e., /etc/nixos/flake.nix exists, it
is impossible to use nixos-rebuild to build a pre-flake
configuration.nix. Of course, one can directly use nix command to
build the configuration, but not everybody remembers the correct nix
options to do that.
With the new option, it is possible to build a pre-flake configuration
with command like this:
nixos-rebuild build-vm -I nixos-config=./vm.nix --no-flake
The option might be useful for people following older pre-flake
tutorials on a flake-based system.
--quiet decreases the logging verbosity level (inverse of -v)
--print-build-logs prints build logs on stderr (same as -L)
Also reordered and grouped some options for consistency
Like with other morrownr modules, the 8821cu repo now links to
the 8821cu-20210118 repository as the place to get the driver code. I
kept the homepage as 8821cu though, because in future if a new version
of the driver is created, that's where the link will be posted.
Fixes the build with Linux 5.17.
When something changes in nixos-rebuild, we must make sure the
installers still work, otherwise it might break existing setups.
The installer tests check whether nixos-rebuild works, so they are a
good lithmus test.
nixos-rebuild would forward all verbose flags to nix, but not actually
increase its own verbosity.
Which would make it hard to see what’s going on without resorting to
tools like strace or adding `set -x` to the script.
We add a simple exec wrapper around the most “interesting” commands,
that is nix tool invocations. If any verbosity flag is given, it will
set the verbosity flag of the nixos-rebuild script all commands
wrapped into `runCmd` will start logging their invocation.
This is done via a `logVerbose` function, which can also be used to
print logging messages when in verbose mode, to aid debugging why
nixos-rebuild does what it does. A few messages are added, but
potentially we could log a lot more details.
Now, testing all of the changed code paths turns out to be rather
hard, so I am unsure how to verify that for all changed commands
behaviour stays indeed the same.
To support this theoretically, the configure script upstream would need
to a) stop using PATH for finding python-config exclusively and allow
passing an absolute path to it and b) cease using the distutils module
for configuration purposes which of course requires running the host
python interpreter which is not possible in the cross case.
Conflict in pkgs/development/libraries/libvirt/default.nix
required manual adjustments. The fetched patch is already in src.
I checked that libvirt builds.
Using `with` in such a high up scope makes it very easy to
accidentally forget to update function arguments and introduce typos
because of the lack of any editor support and static analysis.
It's better to explicitly inherit the small number of things we need
from `lib` into scope so that editors can know of scoped variables.
This reduces closure sizes by making the libraries not depend on the
binaries, which is good for dynamic builds, and (when statically
linked) making the binaries not depend on the libraries, which is good
for static builds.
When static building, we additionally have to disable loading LUKS
plugins from $lib to avoid a reference, which probably wouldn't have
worked anyway.
generate-config.pl's auto modules feature answers "m" to any Kconfig
question it thinks supports being a module. It detected this by
seeing if the help shown by make config (called "alts" by the script)
contained the string "/m", which it would in the case of e.g a
tristate option, where alts would be "N/m/y/?".
But then along came CONFIG_MODPROBE_PATH in Linux 5.13, with a default
value, shown in the make config help, of "/sbin/modprobe".
generate-config.pl would see the "/m" substring, and answer "m" to the
question, meaning (I think) that the built kernel would expect the
modprobe binary to be at /m. This broke the (non-NixOS) VM images I
build with Nix. NixOS was unaffected because it uses a different
mechanism to set the modprobe path.
With the current architecture, we can't 100% determine whether a
Kconfig option is a string or a tristate, but we can get a lot closer
by using a better regex. My new regex only accepts single word
characters, separated by slashes, with a "/?" at the end. This is
much less likely to ever end up as the default value of a string
option.
Tested by building linux_latest.configfile before and after my
changes, and checking the only difference is the correct default for
CONFIG_MODPROBE_PATH.
While it’s unlikely, it’s possible that different MoltenVK versions
could require their own compatability patches. Support that by making
the `moltenvk` derivation provide the patch via `passthru`. There is no
package with the patch applied because the patch should never be used by
anything other than DXVK.
5bc5462213
attempts to fix the need to patch the redfish test ourselves.
But it is actually not sufficient since we install the installed tests
into a separate prefix, so we need to adjust the installed tests patch.
