When we initially applied the openembedded patchset to make systemd
build with musl, these options had to be disabled for it to work.
Now they seem to work fine, so re-enabling.
The NixOS systemd module has to include some upstream unit files
depending on if the systemd package was built with utmp support.
This makes it possible for the NixOS systemd module to detect if the
systemd package was built with utmp support.
So far, we have been building Systemd without `BPF_FRAMEWORK`. As a
result, some Systemd features like `RestrictNetworkInterfaces=` cannot
work. To make things worse, Systemd doesn't even complain when using a
feature which requires `+BPF_FRAMEWORK`; yet, the option has no effect:
# systemctl --version | grep -o "\-BPF_FRAMEWORK"
-BPF_FRAMEWORK
# systemd-run -t -p RestrictNetworkInterfaces="lo" ping -c 1 8.8.8.8
This commit enables `BPF_FRAMEWORK` by default. This is in line with
other distros (e.g., Fedora). Also note that BPF does not support stack
protector: https://lkml.org/lkml/2020/2/21/1000. To that end, I added a
small `CFLAGS` patch to the BPF building to keep using stack protector
as a default.
I also added an appropriate NixOS test.
The ConditionFileNotEmpty override patch wasn't correct for stage1, which
does have the modules in /lib. So, remove the patch and set
the right path with overrides in the final system.
Also, make sure systemd-tmpfiles-setup-dev is pulled in to create
all the necessary symlinks.
patchShebangs was writing a build platform bash shebang to
systemd-update-helper, which ends up in the output. To fix this, this patch
restricts patchShebangs to only run on certain directories.
Also, remove a comment stating that patchShebangs will no longer be necessary
after the next systemd release. This is not the case because /usr/bin/env
doesn't exist within the sandbox and will still need to be patched.
Account for all `with*` options causing their respective unit files to
not be built, just like the current code `withCryptsetup` already does.
This fixes build errors like the following:
```
missing /nix/store/5fafsfms64fn3ywv274ky7arhm9yq2if-systemd-250.4/example/systemd/system/systemd-importd.service
error: builder for '/nix/store/67rdli5q5akzwmqgf8q0a1yp76jgr0px-system-units.drv' failed with exit code 1
```
Found by using a customised systemd package as follows:
```
systemd.package = pkgs.systemd-small;
nixpkgs.config.packageOverrides = pkgs: {
"systemd-small" = pkgs.systemd.override {
withImportd = false;
withMachined = false;
...
};
};
```
In Issue #169693 we found out that systemd-bootaa64.efi does not have
required `#### LoaderInfo: systemd-boot 250.4 ####` marking.
It is destroyed by `nixpkgs`'s `_doStrip` hook (part of `fixupOutputHooks`).
It makes sense as PE32+ is a bit different from ELF where `.sdmagic` section
is inserted.
The change avoids stripping EFI files altogether by moving them out
of default strip directories of _doStrip for the time while `fixupPhase`
is running.
Closes: https://github.com/NixOS/nixpkgs/issues/169693
- Fix the name of the env
- Add the correct kmod to the initrd
- Add `less` to make journalctl usable
- Fix SYSTEMD_SULOGIN_FORCe for rescue.target
- Add some missing binaries
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
As reported in
https://github.com/NixOS/nixpkgs/pull/156096#pullrequestreview-900986176,
this fails to build on EFI enabled RISC-V because the requested EFI
linker (efi-ld=gold) is unsupported. According to Wikipedia gold only
supports x86, x86-64, ARM, PowerPC, TileGX.
Removing this option alltogether will cause meson to figure out the
default linker by itself.
This helps systemd during runtime to make decisions about the sanity of
the system clock. See the references news article for more details on
the matter.
We don't have to do that as we already set all the feature flags to
null. Setting individual libraries to null instead of disabling their
feature flag will lead with bad example that will cause each of the
features to be disabled with multiple flags in the systemdMinimal
variant.
If a dependency is pulled in via another feature we should disable that
rather than setting it to null. Overriding a given package should be the
last resort.
