After linux 5.14.11 FB_SIMPLE conflicts with DRM_SIMPLEDRM, which
will fail configuration, when DRM_SIMPLEDRM is configured as a module
and FB_SIMPLE gets requested as builtin.
Do not enable DRM_SIMPLEDRM as a temporary workaround, until good
enough migration path is found.
Initrd loader is not enabled by default in some aarch64 kernels,
which makes systemd-boot booted kernels fail by default, add this
everywhere, since this is a sane default even when it's already in
some kernel defaults.
BTF is a new, lightweight debug information format tailored specifically
for the needs of eBPF, allowing eBPF programs to be portable across
various kernel versions, configurations and distributions. This is used
by bpftrace and lots of new eBPF-based tooling to avoid a dependency
on LLVM on the host.
BTF debug information is enabled on all major distributions: Fedora 31+,
RHEL 8.2+, Ubuntu 20.10, Debian 11 and ArchLinux all have enabled it.
Enabling BTF debug information requires adding two new dependencies to
the kernel build: Python3 and pahole. Those will be used to generate the
BTF debugging information.
They were enabled in 5.4 but then removed. Let's enable them explicitly
here. To keep the version constraints simple, we match kernel >5.4 even
though some of them are available since 4.x.
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.
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
This option allows to use portions of the system RAM as block devices.
It was configured to 'y' (built-in, therefore not unloadable or
reconfigurable) and configured 16 4MB RAM disks which, to my knowledge,
currently have no purpose in NixOS.
Removing the option restores it to it's default value of 'm', which
enables it to be loaded at runtime (which is also required to be able to
change it's configuration without rebuilding the kernel).
Nixpkgs hasn't supported grsecurity kernels since 2017, so unless
anybody is manually enabling the grsecurity feature to make these
small kernel tweaks this is dead code.
This means we don't actually support any "features" in the kernel
common-config any more, but I've left the argument there because it's
conceivable we could have some again in future.
I don't think there's any reason to have a seperate kernel variant
because of this, with all the maintenance burden that imposes. Debian
and Fedora both enable all these options on their normal kernels.
Alias the Linux Xen attributes, so this change should be seemless for
people who were using the Xen kernels up to now.
All the Xen options are marked as optional anyway, so it should be
fine to try to enable them on non-x86 platforms as well.
Fixes: https://github.com/NixOS/nixpkgs/issues/115182
The parent commit forbids conflicting kernel config options.
Fix the hardened kernels by allowing options in common-config.nix to
be overridden by conflicting ones in hardened/config.nix.
I'm explicitly avoiding using a higher priority (e.g. using mkForce)
in hardened/config.nix so that the user can easily override the
options in that file.
Since 2020, Mesa requires the kcmp() system call to be available for
some of its functionality. At the moment, this system call is enabled
when CHECKPOINT_RESTORE is enabled in the Linux kernel. This option is
also enabled by default in Fedora and Debian.
This patch enables CHECKPOINT_RESTORE by default on all kernel
versions where it is not marked as EXPERT, i.e. everything after and
including 4.19.
Fixes#112082.
The kernel config parameter `DRM_AMD_DC_DCN3_0` is required to enable
the RX 6000 series GPUs, and is supported on kernels at least `5.9.12`.
Source: https://wiki.gentoo.org/wiki/AMDGPU#Installation
Starting from Linx 5.6, there is partial upstream support for the Multipath TCP
protocol. There are no downsides to enabling it afaict, since
applications need to opt-in when creating a socket.
From https://github.com/multipath-tcp/mptcp_net-next/wiki:
"[...] users of regular TCP continue to get the same type of connection and
performance unless MPTCP is requested."
As per the in-line comment, this is where distros should configure it.
Not via kernel command line parameters.
As found by looking at the implementation, while exploring the cause of
a bug on the Raspberry Pi 4, it was found that `cma=` on the command
line parameters will overwrite the values a device tree will have
configured for a given platform.
With this, the more recent 5.4 vendor kernel boots just fine on the
Raspberry Pi 4 using our common configuration.
Without this, the kernel would generate a random one for us which obviously
isn't reproducible.
`nix-build -A linux --check` succeeds now!
(Tested at different times with different kernel)
We currently build CONFIG_IPV6=m.
This seems to be not really well-supported in mainline kernels - see
https://lore.kernel.org/netdev/20201115224509.2020651-1-flokli@flokli.de/T/#u
Compiling it as a module doesn't give too much benefit - even for people
who did explicitly set `enableIPv6` to false, the `ipv6` module was
still loaded, as soon as another module was loaded that requires it
(bridge,br_netfilter,wireguard,ip6table_mangle,sctp,…).
By compiling it in, we only loose the possibility to not add it to
`boot.kernelModules` anymore (as it's part of the kernel directly). The
space savings are negligible.
People wanting to disable IPv6 still get the appropriate sysctls and
options set (while having the kernel code loaded), nothing is really
changing here.
This config value ensures that when booting through e.g. UEFI, the
existing framebuffer contents stay put until the first character is
printed. As the default NixOS stage-1 immediately outputs a welcome
message on init, this does not impact it, but it will allow for a cleaner boot when
configured as such.
With the fix in kernel configuration merging, some kernel configuration items
marked as mandatory now correctly trigger an error when unused (while they
previously were unused).
Since we select everything as a module, snd_hda_codec_ca0132 is built as
well. DSP loading is not enabled by default, but without it the
soundcard produces timeouts within ALSA and does not emit sound.
Explicitly enable the firmware loading to ensure Soundblaster
Z/Zx/ZxR/Recon devices can be used with NixOS.
The patch to enable this by default in the kernel is staged for 5.8.
This will switch the default TCP congestion control algorithm from
new Reno to CUBIC. CUBIC is the default since Linux kernel 2.6.19
(see 597811ec167fa) and most (all?) distributions keep this default
(e.g. Debian and Ubuntu). On NixOS the default was still new Reno
because generate-config.pl changes TCP_CONG_CUBIC from y to m (since we
try to build everything as a module by default).
To check the active and available algorithms:
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
$ sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = cubic reno
Note: E.g. x86_64_defconfig sets TCP_CONG_CUBIC=y indirectly via
CONFIG_TCP_CONG_ADVANCED=y (but CUBIC is also the default if set to no,
see net/ipv4/Kconfig).
CONFIG_IP_MULTIPLE_TABLES is part of the default x86 kernel config but
absent from the Aarch64 one. Adding explicitely this flag together
with its dependency IP_ADVANCED_ROUTER.
Both of these config flags are needed to use the routing policy
facilities.
This reverts a small bit of af808bd82 from PR #73328. Fixes#79304:
tests.installer.simpleUefiSystemdBoot.x86_64-linux
I still don't know why the regression happened, but this feature doesn't
seem important enough to block channel now, though it reportedly helps
to mitigate spectre 2 attack CVE-2017-5715.
