nvidia 470.57.02 changed the path of `nvidia-sleep.sh` and systemd
scripts, making `builder.sh` miss them and suspend-to-ram on systems
where `hardware.nvidia.powerManagement.enable = true` is set fail.
Previously when doing a nixos-rebuild build-vm we see a message saying how to
run the VM, but with nixos-rebuild build-vm-with-bootloader we did not. We
now show it in both cases.
LPAE was enabled to support native armv7l builders running in QEMU on aarch64,
but this option disables support for processors which don't support LPAE, which
are still relatively common. In particular, Beaglebones use the Cortex-A8, which
doesn't support LPAE.
Also, if you attempt to boot an LPAE kernel on a CPU that doesn't support it,
it fails before even earlycon is initialized. This makes the problem difficult
to debug without enabling CONFIG_DEBUG_LL or using a hardware debugger.
thin-provisioning-tools has a _huge_ closure size (hundreds of
megabytes) and the only reference in the output of the lvm2 package is a
_comment_ in the etc/lvm.conf
The lvm2 package thus does not seem to depend on thin-provisoning-tools
in any way.
Reverts 9326a89910
thin provisoning is broken with or without this change:
https://github.com/NixOS/nixpkgs/issues/15516
A proper fix is here:
https://github.com/NixOS/nixpkgs/pull/46541
References:
$ nix why-depends nixpkgs#lvm2 nixpkgs#thin-provisioning-tools
/nix/store/n7zwwxi0ihjks7qk9bq5lbkniligfcqc-lvm2-2.03.11
└───etc/lvm.conf: …_check_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-prov>
→ /nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0
$ ag thin-provisioning-tools --search-binary
etc/lvm.conf
1093: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1095: # thin_check_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/thin_check"
1100: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1102: # thin_dump_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/thin_dump"
1108: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1110: # thin_repair_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/thin_repair"
1155: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1157: # cache_check_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/cache_check"
1162: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1164: # cache_dump_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/cache_dump"
1170: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1172: # cache_repair_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/cache_repair"
Without this, failure of nixBuild() and nixFlakeBuild() was ignored
(since bash doesn't inherit 'set -e' in subshells by default), so the
script would proceed with a bogus ./result link, e.g.
++ readlink -f /tmp/nixos-rebuild.NfHKxx/result
+ pathToConfig='/nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix
/tmp/nixos-rebuild.NfHKxx/result'
+ '[' test = switch -o test = boot ']'
+ copyToTarget '/nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix
/tmp/nixos-rebuild.NfHKxx/result'
+ '[' '' = '' ']'
+ '[' test = switch -o test = boot -o test = test -o test = dry-activate ']'
+ targetHostCmd /nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix /tmp/nixos-rebuild.NfHKxx/result/bin/switch-to-configuration test
+ '[' -z '' ']'
+ sudo -- /nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix /tmp/nixos-rebuild.NfHKxx/result/bin/switch-to-configuration test
error: '/tmp/nixos-rebuild.NfHKxx/result/bin/switch-to-configuration' is not a recognised command
Try '/nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix --help' for more information.
+ echo 'warning: error(s) occurred while switching to the new configuration'
warning: error(s) occurred while switching to the new configuration
Also make various improvements and fixes:
- Rename pname from lsiutils to lsiutil since that is the actual name
- Update the URL since the old one was broken
- Inline the call to fetchurl
- Use the installPhase to install instead of installing in the buildPhase
- Replace a call to the modprobe binary with the absolute path to the binary
- Properly determine the absolute path of the mknod binary
- Update the description with text from the source code header
- Declare that this only works on Linux
- Add myself as maintainer
Turns VMware guest mouse support on in the kernel. This is needed for running Wayland and non-root X in a VMWare guest. In a pre-Wayland world the `xf86-input-vmmouse` userspace driver would have handled this for us. This allows the mouse to properly work in a vmware guest (for example it can now leave the vmware window).
See: https://github.com/vmware/open-vm-tools/issues/528
We should be using the _same_ buildPackages when we generate the
configuration (which happens in buildLinux) as when we actually build
the kernel (which happens in linuxManualConfig).
This change enforces that when we callPackage `manual-config.nix` we
pass on whatever `buildPackages` that `buildLinux` itself was called
with.
I assume it broke with python 3.8 -> 3.9.
Updating would be another way, but that would require also updating some
dependencies, and I'm not a selinux person so I chose a simple patch.
I suspect that some of the stdenv changes (PR #127736 maybe?)
affected how the newline was handled. Anyway, it was ugly,
so let's use a more standard approach.
This is just for practicity, as it allows users of buildLinux to pass
along extra flags they need in the kernel's make invocation. This makes,
for example, supporting LLVM _much_ easier, and could enable us in the
future to provide clang-built kernels.
This enforces that the configuration generated will obey any/all flags
set in the platform/stdenv configuration. This is crucial, for example,
if you'd like to build a kernel using clang.
Without this patch, anything you set in
`stdenv.hostPlatform.linux-kernel.makeFlags` is wholly ignored during
config generation, causing (for example) any changes in the desired
toolchain (e.g. `LLVM`, `LLVM_IAS`) to not be reflected in the generated
config, and for the subsequent build to fail.
There are many scripts in `scripts/` which may be called by the build,
depending on how the user chooses to configure the kernel. For example,
`scripts/jobserver-exec` is called whenever the kernel is being built
with LLVM tooling, and without this patch that build will fail due to
the broken shebang.
This patch makes us fix _all_ scripts, as well as add a dependency on
python3Minimal, since a lot of the aforementioned scripts are written in
Python3 instead of shell.
