When installing NixOS on a machine with Windows, the "easiest" solution
to dual-boot is re-using the existing EFI System Partition (ESP), which
allows systemd-boot to detect Windows automatically.
However, if there are multiple ESPs, maybe even on multiple disks,
systemd-boot is unable to detect the other OSes, and you either have to
use Grub and os-prober, or do a tedious manual configuration as
described in the wiki:
https://wiki.nixos.org/w/index.php?title=Dual_Booting_NixOS_and_Windows&redirect=no#EFI_with_multiple_disks
This commit automates and documents this properly so only a single line
like
boot.loader.systemd-boot.windows."10".efiDeviceHandle = "HD0c2";
is required.
In the future, we might want to try automatically detecting this
during installation, but finding the correct device handle while the
kernel is running is tricky.
- use upstream service and scripts
- switch to integrated-vtysh-config, abandon per-daemon config
- use always daemon names in options (e.g. ospf -> ospfd)
- zebra, mgmtd and staticd are always enabled
- abandon vtyListenAddress, vtyListenPort options; use
just "extraOptions" or "options" instead, respectively
- extend test to test staticd
- update release-notes
- pkgs.servers.frr: fix sbindir and remove FHS PATH
- introduce services.frr.openFilesLimit option
There's no point for the intermediate `getPath` function calling
`getLuaPath` with the "lua" argument.
There's also no other nginx test this copies code from.
We always call `getLuaPath` with "lua", so constant-propagate it in.
Also, camel-case `lualibs` to `luaLibs.`
When 757a455dde refactored the zones to go
from a list to a map, this broke the tests/common/resolver helper.
reproduction:
```
let
pkgs = import <nixpkgs> {};
testConfig = {
name = "resolver-repro";
nodes = {
acme = { nodes, ... }: {
imports = [ (pkgs.path + /nixos/tests/common/acme/server) ];
};
};
testScript = ''
'';
};
in pkgs.nixosTest testConfig
```
The test currently fails because we attempt to switch to a NixOS
configuration that is _very_ different from the one we are switching
from (e.g. the new configuration has an entirely empty /etc/fstab,
causing switch-to-configuration to want to start unmounting all
filesystems defined in the old configuration).
