`rngd` seems to be the root cause for slow boot issues, and its functionality is
redundant since kernel v3.17 (2014), which introduced a `krngd` task (in kernel
space) that takes care of pulling in data from hardware RNGs:
> commit be4000bc4644d027c519b6361f5ae3bbfc52c347
> Author: Torsten Duwe <duwe@lst.de>
> Date: Sat Jun 14 23:46:03 2014 -0400
>
> hwrng: create filler thread
>
> This can be viewed as the in-kernel equivalent of hwrngd;
> like FUSE it is a good thing to have a mechanism in user land,
> but for some reasons (simplicity, secrecy, integrity, speed)
> it may be better to have it in kernel space.
>
> This patch creates a thread once a hwrng registers, and uses
> the previously established add_hwgenerator_randomness() to feed
> its data to the input pool as long as needed. A derating factor
> is used to bias the entropy estimation and to disable this
> mechanism entirely when set to zero.
Closes: #96067
Now allows applying external overlays either in form of
.dts file, literal dts context added to store or precompiled .dtbo.
If overlays are defined, kernel device-trees are compiled with '-@'
so the .dtb files contain symbols which we can reference in our
overlays.
Since `fdtoverlay` doesn't respect `/ compatible` by itself
we query compatible strings of both `dtb` and `dtbo(verlay)`
and apply only if latter is substring of the former.
Also adds support for filtering .dtb files (as there are now nearly 1k
dtbs).
Co-authored-by: georgewhewell <georgerw@gmail.com>
Co-authored-by: Kai Wohlfahrt <kai.wohlfahrt@gmail.com>
The commit enforces buildPackages in the builder but neglects
the fact that the builder is intended to run on the target system.
Because of that, the builder will fail when remotely building a
configuration eg. with nixops or nix-copy-closure.
This reverts commit a6ac6d00f9.
Following changes in https://github.com/NixOS/nixpkgs/pull/91092 the `path` attribute is now a list
instead of being a string. This resulted resulted in the following evaluation error:
"cannot coerce a list to a string, at [...]/nixos/modules/services/networking/openvpn.nix:16:18"
so we now need to convert it to the right type ourselves.
Closes https://github.com/NixOS/nixpkgs/issues/97360.
Add the option `environmentFile` to allow passing secrets to the service
without adding them to the Nix store, while keeping the current
configuration via the existing environment file intact.
Right now the UX for installing NixOS on a headless system is very bad.
To enable sshd without physical steps users have to have either physical
access or need to be very knowledge-able to figure out how to modify the
installation image by hand to put an `sshd.service` symlink in the
right directory in /nix/store. This is in particular a problem on ARM
SBCs (single board computer) but also other hardware where network is
the only meaningful way to access the hardware.
This commit enables sshd by default. This does not give anyone access to
the NixOS installer since by default. There is no user with a non-empty
password or key. It makes it easy however to add ssh keys to the
installation image (usb stick, sd-card on arm boards) by simply mounting
it and adding a keys to `/root/.ssh/authorized_keys`.
Importantly this should not require nix/nixos on the machine that
prepare the installation device and even feasiable on non-linux systems
by using ext4 third party drivers.
Potential new threats: Since this enables sshd by default a
potential bug in openssh could lead to remote code execution. Openssh
has a very good track-record over the last 20 years, which makes it
far more likely that Linux itself would have a remote code execution
vulnerability. It is trusted by millions of servers on many operating
systems to be exposed to the internet by default.
Co-authored-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
readd perl (used in shell scripts), rsync (needed for NixOps) and strace (common debugging tool)
they where previously removed in https://github.com/NixOS/nixpkgs/pull/91213
Co-authored-by: Timo Kaufmann <timokau@zoho.com>
Co-authored-by: 8573 <8573@users.noreply.github.com>
