This shuts up this error from dbus:
May 11 13:52:16 machine dbus-daemon[259]: Unknown username "systemd-network" in message bus configuration file
May 11 13:52:16 machine dbus-daemon[259]: Unknown username "systemd-resolve" in message bus configuration file
which happens because the D-Bus config for networkd/resolved is
enabled unconditionally, and we don't have an easy way to turn it off.
(cherry picked from commit f19b58fb6a)
Some filesystems like fat32 don't support symlinking and need to be
supported on /boot as an efi system partition. Instead of creating the symlink directly in boot, create the symlink in
a temporary directory which has to support symlinking.
This solves the problem that modprobe does not know about $MODULE_DIR
when run via sudo, and instead wrongly tries to read /lib/modules/:
$ sudo strace -efile modprobe foo |& grep modules
open("/lib/modules/3.14.37/modules.softdep", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/modules/3.14.37/modules.dep.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/modules/3.14.37/modules.dep.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/modules/3.14.37/modules.alias.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Without this patch, one would have to use sudo -E (preserves environment
vars). But that option is reserved for sudo users with extra rights
(SETENV), so it's not a solution.
environment.sessionVariables are set by PAM, so they are included in the
environment used by sudo.
This module generates a /boot/extlinux/extlinux.conf bootloader
configuration file that is supported by e.g. U-Boot:
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.distro;hb=refs/heads/master
With this, all ARM boards supported by U-Boot can be booted in a common
way (a single boot file generator, all boards booting via initrd like
x86) and with same boot menu functionality as GRUB has.
-- sample extlinux.conf file --
# Generated file, all changes will be lost on nixos-rebuild!
# Change this to e.g. nixos-42 to temporarily boot to an older configuration.
DEFAULT nixos-default
TIMEOUT 50
LABEL nixos-default
MENU LABEL NixOS - Default
LINUX ../nixos/n7vxfk60nb5h0mcbhkwwxhcz2q2nvxzv-linux-4.1.0-rc3-cpufreq-zImage
INITRD ../nixos/0ss2zs8sb6d1qn4gblxpwlxkfjsgs5f0-initrd-initrd
FDTDIR ../nixos/n7vxfk60nb5h0mcbhkwwxhcz2q2nvxzv-linux-4.1.0-rc3-cpufreq-dtbs
APPEND systemConfig=/nix/store/469qvr43ln8bfsnk5lzcz6m6jfcgdd4r-nixos-15.06.git.0b7a7a6M init=/nix/store/469qvr43ln8bfsnk5lzcz6m6jfcgdd4r-nixos-15.06.git.0b7a7a6M/init loglevel=8 console=ttyS0,115200n8 drm.debug=0xf
LABEL nixos-71
MENU LABEL NixOS - Configuration 71 (2015-05-17 21:32 - 15.06.git.0b7a7a6M)
LINUX ../nixos/n7vxfk60nb5h0mcbhkwwxhcz2q2nvxzv-linux-4.1.0-rc3-cpufreq-zImage
INITRD ../nixos/0ss2zs8sb6d1qn4gblxpwlxkfjsgs5f0-initrd-initrd
FDTDIR ../nixos/n7vxfk60nb5h0mcbhkwwxhcz2q2nvxzv-linux-4.1.0-rc3-cpufreq-dtbs
APPEND systemConfig=/nix/store/469qvr43ln8bfsnk5lzcz6m6jfcgdd4r-nixos-15.06.git.0b7a7a6M init=/nix/store/469qvr43ln8bfsnk5lzcz6m6jfcgdd4r-nixos-15.06.git.0b7a7a6M/init loglevel=8 console=ttyS0,115200n8 drm.debug=0xf
This reverts commit d170c98d13.
niksnut argues that we need smaller system closures, not bigger.
So users facing the trouble of getting gcc rebuilds after nix-collect-garbage
for any minimal nixos configuration change should use other means of
not losing the stdenv output.
One way is to keep one somewhere: nix-build -A stdenv -o stdenv '<nixpkgs>'.
Another may be to use nix.conf options like gc-keep-outputs, gc-keep-derivations
or env-keep-derivations.
This will help a lot on ARM, where nix-collect-garbage erases gcc; then, any
change to a small system config file requires rebuilding gcc again.
I don't know why it does not happen on x86. Maybe it just pulls the gcc from
hydra, if garbage is collected.
It boots, but some things still don't work:
1) Installation of DTBs
2) Boot of initrd
Booting still needs a proper config.txt in /boot, which could probably be
managed by NixOS.
During the refactor of the networkd stuff in f8dbe5f, a lot of the
options are now needed by systemd.nix as well as networkd.nix but
weren't moved by that commit as well.
For now, this fixes all networkd VM tests except for the macvlan one and
thus it should fix#7505 for at least DHCP-based configuration.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
In f8dbe5f, the default value for networking unit "enabled" option
suddenly flipped to false. I have no idea of whether this happened by
accident, but I'm setting it to true again, because it essentially
breaks systemd networking support and we have systemd.network.enable to
have a "turn the world off" switch.
And of course, because the mentioned commit obviously wasn't done with
even a run of the simplest run of one of the network VM tests, we now
get an evaluation error if we switch useNetworkd to true.
Fixes the core issue of #7505.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Otherwise, the enabled -> disabled transition won't be handled
correctly (switch-to-configuration currently assumes that if a unit is
running and exists, it should be restarted).
Many bus clients get hopelessly confused when dbus-daemon is
restarted. So let's not do that.
Of course, this is not ideal either, because we end up stuck with a
possibly outdated dbus-daemon. But that issue will become irrelevant
in the glorious kdbus-based future.
Hopefully this also gets rid of systemd getting stuck after
dbus-daemon is restarted:
Apr 01 15:37:50 mandark systemd[1]: Failed to register match for Disconnected message: Connection timed out
Apr 01 15:37:50 mandark systemd[1]: Looping too fast. Throttling execution a little.
Apr 01 15:37:51 mandark systemd[1]: Looping too fast. Throttling execution a little.
...
