- added package option to specify which version of redmine
- added themes option back in to allow specifying redmine themes
- added plugins option back in to allow specifying redmine plugins
- added database.socket option to allow mysql unix socket authentication
- added port option to allow specifying the port rails runs on
- cleaned up Gemfile so it is much less hacky
- switched to ruby version 2.4 by default as suggested by documentation http://www.redmine.org/projects/redmine/wiki/redmineinstall#Installing-Redmine
- fixed an annoyance (bug) in the service causing recursive symlinks
- fixed ownership bug on log files generated by redmine
- updates reflecting renames in nixos options
- added a nixos test
Dummy display manager that allows running X as a normal user.
The X server is started manually from a vt using `startx`.
Session startup commands must be provided by the user
in ~/.xinitrc, which is NOT automatically generated.
Previously you either had to set the setuid bit yourself or workaround
`isSystemUser = true` (for a loginable shell) to access the weechat
screen.
`programs.screen` shouldn't do this by default to avoid taking too much
assumptions about the setup, however `services.weechat` explicitly
requires tihs.
See #45728
Included changes:
* upstream repository has moved, URLs changed accordingly
* journaldriver bumped to new upstream release
The new release includes an important workaround for an issue that
could cause log-forwarding to fail after service restarts due to
invalid journal cursors being persisted.
This patch uses the library function `lib.escapeShellArg` to improve
the handling of shell aliases in the NixOS module `bash`, copying the
corresponding change made to the `zsh` module in commit
1e211a70cb (for which GitHub pull
request #47471 was filed).
This patch resolves GitHub issue #16973.
This change presumably also should be copied to the `fish` module, but
I don't know `fish` syntax so that won't be done by me.
GitHub: Close NixOS/nixpkgs#16973.
When logging into a container by using
nixos-container root-login
all nix-related commands in the container would fail, as they
tried to modify the nix db and nix store, which are mounted
read-only in the container. We want nixos-container to not
try to modify the nix store at all, but instead delegate
any build commands to the nix daemon of the host operating system.
This already works for non-root users inside a nixos-container,
as it doesn't 'own' the nix-store, and thus defaults
to talking to the daemon socket at /nix/var/nix/daemon-socket/,
which is bind-mounted to the host daemon-socket, causing all nix
commands to be delegated to the host.
However, when we are the root user inside the container, we have the
same uid as the nix store owner, eventhough it's not actually
the same root user (due to user namespaces). Nix gets confused,
and is convinced it's running in single-user mode, and tries
to modify the nix store directly instead.
By setting `NIX_REMOTE=daemon` in `/etc/profile`, we force nix
to operate in multi-user mode, so that it will talk to the host
daemon instead, which will modify the nix store for the container.
This fixes #40355
Several service definitions used `mkEnableOption` with text starting
with "Whether to", which produced funny option descriptions like
"Whether to enable Whether to run the rspamd daemon..".
This commit corrects this, and adds short descriptions of services
to affected service definitions.
The problem was that the non-fatal warning was not omitted
from the output when constructing a nix expression.
Now it seems OK for me. When return code is OK,
the warnings don't get passed anywhere, but I expect
that won't matter for this utility. Fatal errors are still shown.
as using /var/run now emits a warning by systemd's tmpfiles.d.
As /var/run is already a symlink to /run, this can't break anything, and
data does not need to be migrated.
The autoupgrade service defined in `system.autoUpgrade`
(`nixos/modules/installer/tools/auto-upgrade.nix`) doesn't have `su` in
its path and thus yields a warning during the `daemon-reload`.
Specifying the absolute path fixes the issue.
Fixes #47648
The init script slightly differs depending on which shell is in use.
So for bash it should be in the interactiveShellInit as well.
In this case we don't need a mkIf as `bash` is enabled by default
on NixOS.
We use `127.0.1.1` instead of `127.0.0.1` because some applications will fail if
`127.0.0.1` resolves to something other than `localhost`.
Debian does the same.
See #1248 and #36261.
Since `networking.hosts` is properly typed all of that magic `/etc/hosts` generator
does can be dropped. People that disagree with the value of `networking.hosts` can
simply `mkForce`.
This is necessary when system-wide dconf settings must be configured, i.e. to
disable GDM's auto-suspending of the machine when no user is logged in.
Related to https://github.com/NixOS/nixpkgs/issues/42053.
I think pam_lastlog is the only thing that writes to these files in
practice on a modern Linux system, so in a configuration that doesn't
use that module, we don't need to create these files.
I used tmpfiles.d instead of activation snippets to create the logs.
It's good enough for upstream and other distros; it's probably good
enough for us.
Nix 2.0 no longer uses these directories.
/run/nix/current-load was moved to /nix/var/nix/current-load in 2017
(Nix commit d7653dfc6dea076ecbe00520c6137977e0fced35). Anyway,
src/build-remote/build-remote.cc will create the current-load directory
if it doesn't exist already.
/run/nix/remote-stores seems to have been deprecated since 2014 (Nix
commit b1af336132cfe8a6e4c54912cc512f8c28d4ebf3) when the documentation
for $NIX_OTHER_STORES was removed, and support for it was dropped
entirely in 2016 (Nix commit 4494000e04122f24558e1436e66d20d89028b4bd).
The default value for journald's Storage option is "auto", which
determines whether to log to /var/log/journal based on whether that
directory already exists. So NixOS has been unconditionally creating
that directory in activation scripts.
However, we can get the same behavior by configuring journald.conf to
set Storage to "persistent" instead. In that case, journald will create
the directory itself if necessary.
Previously, the activation script was responsible for ensuring that
/etc/machine-id exists. However, the only time it could not already
exist is during stage-2-init, not while switching configurations,
because one of the first things systemd does when starting up as PID 1
is to create this file. So I've moved the initialization to
stage-2-init.
Furthermore, since systemd will do the equivalent of
systemd-machine-id-setup if /etc/machine-id doesn't have valid contents,
we don't need to do that ourselves.
We _do_, however, want to ensure that the file at least exists, because
systemd also uses the non-existence of this file to guess that this is a
first-boot situation. In that case, systemd tries to create some
symlinks in /etc/systemd/system according to its presets, which it can't
do because we've already populated /etc according to the current NixOS
configuration.
This is not necessary for any other activation script snippets, so it's
okay to do it after stage-2-init runs the activation script. None of
them declare a dependency on the "systemd" snippet. Also, most of them
only create files or directories in ways that obviously don't need the
machine-id set.
environment.sessionVariables cannot refer to the values of env vars,
and as a result this has caused problems in a variety of scenarios.
One use for these is that they're injected into /etc/profile,
elewhere these are used to populate an 'envfile' for pam
(`pam 5 pam_env.conf`) which mentions use of HOME being
potentially problematic.
Anyway if the goal is to make things easier for users,
simply do the NIX_PATH modification as extraInit.
This fixes the annoying problems generated by the current approach
(#40165 and others) while hopefully serving the original goal.
One way to check if things are borked is to try:
$ sudo env | grep NIX_PATH
Which (before this change) prints NIX_PATH variable with
an unexpanded $HOME in the value.
-------
This does mean the following won't contain user channels for 'will':
$ sudo -u will nix-instantiate --eval -E builtins.nixPath
However AFAICT currently they won't be present either,
due to unescaped $HOME. Unsure if similar situation for other users
of sessionVariables (not sudo) work with current situation
(if they exist they will regress after this change AFAIK).
Previously single quotes were used by default for aliases and the module
never warned about possible collisions when having a shell alias which
relies on single quotes.
Adding `escapeShellArg` works around this fixes the issue and ensures that a
properly quoted value is written to `/etc/zshrc`.
The socket activation I added to the rspamd module doesn't actually work
and can't be made to work without changes to rspamd.
See: #47421
See: rspamd/rspamd#2035
Evaluation error introduced in 599c4df46a.
There is only a "platformS" attribute in kexectools.meta, so let's use
this and from the code in the kexec module it operates on a list,
matching the corresponding platforms, so this seems to be the attribute
the original author intended.
Tested by building nixos/tests/kexec.nix on x86_64-linux and while it
evaluates now, the test still fails by timing out shortly after the
kexec:
machine: waiting for the VM to finish booting
machine# Cannot find the ESP partition mount point.
This however seems to be an unrelated issue and was also the case before
the commit mentioned above.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra, @dezgeg
Changes the evaluation order in that it evaluates assertions before
warnings, so that eg. the following would work:
{ config, lib, ... }:
{
options.foo = lib.mkOption {
type = lib.types.bool;
default = true;
description = "...";
};
options.bar = lib.mkOption {
type = lib.types.bool;
default = false;
description = "...";
};
config = lib.mkMerge [
(lib.mkIf config.bar {
system.build.bar = "foobar";
})
(lib.mkIf config.foo {
assertions = lib.singleton {
assertion = config.bar;
message = "Bar needs to be enabled";
};
systemd.services.foo = {
description = "Foo";
serviceConfig.ExecStart = config.system.build.bar;
};
})
];
}
This is because the systemd module includes definitions for warnings
that would trigger evaluation of the config.system.build.bar definition.
The original pull request references a breakage due to the following:
{
services.nixosManual.enable = false;
services.nixosManual.showManual = true;
}
However, changing the eval order between asserts and warnings clearly is
a corner case here and it only happens because of the aforementioned
usage of warnings in the systemd module and needs more discussion.
Nevertheless, this is still useful because it lowers the evaluation time
whenever an assertion is hit, which is a hard failure anyway.
Introduced by 0f3b89bbed.
If services.nixosManual.showManual is enabled and
documentation.nixos.enable is not, there is no
config.system.build.manual available, so evaluation fails. For example
this is the case for the installer tests.
There is however an assertion which should catch exactly this, but it
isn't thrown because the usage of config.system.build.manual is
evaluated earlier than the assertions.
So I split the assertion off into a separate mkIf to make sure it is
shown appropriately and also fixed the installation-device profile to
enable documentation.nixos.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @oxij
- Use socket-activated epmd - that way there won't be any trouble when
more than one erlang system is used within a single host.
- Use new automation-friendly configuration file format
- Use systemd notifications instead of buggy 'rabbitmqctl wait' for
confirming successful server startup.
'wait' bug: https://github.com/rabbitmq/rabbitmq-server/issues/463
- Use 'rabbitmqctl shutdown' instead of 'stop', because it's not
pid-file based
- Use sane systemd unit defaults from RabbitMQ repo:
https://github.com/rabbitmq/rabbitmq-server/blob/master/docs/rabbitmq-server.service.example
- Support for external plugins
This reverts commit f777d2b719.
cc #34409
This breaks evaluation of the tested job:
attribute 'diskInterface' missing, at /nix/store/5k9kk52bv6zsvsyyvpxhm8xmwyn2yjvx-source/pkgs/build-support/vm/default.nix:316:24
Most importantly, this sets PrivateTmp, ProtectHome, and ProtectSystem
so that Chrony flaws are mitigated, should they occur.
Moving to ProtectSystem=full however, requires moving the chrony key
files under /var/lib/chrony -- which should be fine, anyway.
This also ensures ConditionCapability=CAP_SYS_TIME is set, ensuring
that chronyd will only be launched in an environment where such a
capability can be granted.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
or else at least the following config will fail with an evaluation error
instead of an assert
```
{
services.nixosManual.enable = false;
services.nixosManual.showManual = true;
}
```
This reverts commit 67c8c49177.
'nix run nixos.firefox' is *not* supposed to work - the Nix 2.x
interface attempts to standardize on nixpkgs.*, to get rid of the
nixos/nixpkgs confusion that existed with the channels interface. So
let's not bring that confusion back.
When a bridge interface was reconfigured, running containers using
this bridge lost connectivity: restarting network-addresses-brN.service
triggered a restart of network-setup.service via a "partOf" relationship
introduced in 07e0c0e0a2.
This in turn restarted brN-netdev.service.
The bridge was thus destroyed and recreated with the same name but a new
interface id, causing attached veth interfaces to lose their connection.
This change removes the "partOf" relationship between
network-setup.service and network-addresses-brN.service for all bridges.
Because when I see "config.system.build.manual.manual" after I forgot
what it means I ask "Why do I need that second `.manual` there again?".
Doesn't happen with `config.system.build.manual.manualHTML`.
Without this the graphical installer has no way to open the manual.
You can fix it yourself by installing any HTML browser but this might
be unfamiliar to users new to NixOS and without any other way to open
the manual. The downside is it will also increase download sizes.
Fixes #46537
/run/rmilter is set by systemd, and have root:root ownership, which
prevent pid file to write.
This fix suggested to be promoted to 18.09 branch.
(Although rmilter itself is deprecated, and I plan to remove it, after
18.09 would be released)
Add package libratbag and service module ratbagd
Libratbag contains ratbagd daemon and ratbagctl cli to configure
buttons, dpi, leds, etc. of gaming mice.
Add mvnetbiz to maintainers.
Instead of searching `/usr` it should search for the `xkb`,
$XDG_DATA_DIRS will be searched. With this approach we allow compliance
on NixOS and non-NixOS systems to find `symbols` in the `xkb` directory.
The patch has been accepted by upstream, but isn't released yet, so this
is mainly a temporary fix until we can bump ZSH to the next stable version.
The `xserver` module links `/share/X11/xkb` to `/run/current-system` to
make this possible.
The fix can be tested inside the following VM:
```
{
zshtest = {
programs.zsh.enable = true;
users.extraUsers.vm = {
password = "vm";
isNormalUser = true;
};
services.xserver.enable = true;
};
}
```
Fixes #46025
The `pkgs.yabar` package is relatively old (2016-04) and contains
several issues fixed on master. `yabar-unstable` containsa recent master
build with several fixes and a lot of new features (I use
`yabar-unstable` for some time now and had no issues with it).
In the upstream bugtracker some bugs could be fixed on ArchLinux by
simply installing `yabar-git` (an AUR package which builds a recent
master).
To stabilize the module, the option `programs.yabar.package` now
defaults to `pkgs.yabar-unstable` and yields a warning with several
linked issues that are known on `pkgs.yabar`.
The test has been refactored as well to ensure that `yabar` actually
starts (and avoid non-deterministic random success) and takes a
screenshot of a very minimalistic configuration on IceWM.
Fixes #46899
This allows the definition of a custom derivation of Exim,
which can be used to enable custom features such as LDAP and PAM support.
The default behaviour remains unchanged (defaulting to pkgs.exim).
10G is not enough for a desktop installation, and resizing a Virtualbox disk image is a pain.
Let's increase the default disk size to 100G. It does not require more storage space, since the empty bits are left out.
1. Simplify the command by reading directly from /etc/machine-id which
is already a random, lower-case hex string
2. Previously, the command output could be too short because of missing
leading digits. This is now fixed.
* acquire DHCP on the interfaces with networking.interface.$name.useDHCP == true or on all interfaces if networking.useDHCP == true (was only only "eth0")
* respect "mtu" if it was in DHCP answer (it happens in the wild)
* acquire and set up staticroutes (unlike others clients, udhcpc does not do the query by default); this supersedes https://github.com/NixOS/nixpkgs/pull/41829
For update-mime-database to work, you must have to have some mime
packages installed. In some DEs like XFCE this is not guaranteed to
happen. In that case just skip the update-mime-database call.
Fixes #46162
That way the built-in web server is usable by default but users can use
$HOME/web directly (instead of having to use a symlink), if they want to
customize the webpage.
Without a group the gid will default to 65534 (2^16 - 2) which maps to
"nogroup". IMO it makes more sense to explicitly set a valid group.
Adding pkgs.sks to environment.systemPackages is not required (IIRC we
want to avoid bloating environment.systemPackages). Instead it seems
like a better idea to make the relevant binaries available to the user
sks and enable useDefaultShell so that "su -l sks" can be used for
manual interaction (that way the files will always have the correct
owner).
This commit adds the following
* the uucp user
* options for HylaFAX server to control startup and modems
* systemd services for HylaFAX server processes
including faxgettys for modems
* systemd services to maintain the HylaFAX spool area,
including cleanup with faxcron and faxqclean
* default configuration for all server processes
for a minimal working configuration
Some notes:
* HylaFAX configuration cannot be initialized with faxsetup
(as it would be common on other Linux distributions).
The hylafaxplus package contains a template spool area.
* Modems are controlled by faxgetty.
Send-only configuration (modems controlled by faxq)
is not supported by this configuration setup.
* To enable the service, one or more modems must be defined with
config.services.hylafax.modems .
* Sending mail *should* work:
HylaFAX will use whatever is in
config.services.mail.sendmailSetuidWrapper.program
unless overridden with the sendmailPath option.
* The admin has to create a hosts.hfaxd file somewhere
(e.g. in /etc) before enabling HylaFAX.
This file controls access to the server (see hosts.hfaxd(5) ).
Sadly, HylaFAX does not permit account-based access
control as is accepts connections via TCP only.
* Active fax polling should work; I can't test it.
* Passive fax polling is not supported by HylaFAX.
* Pager transmissions (with sendpage) are disabled by default.
I have never tested or used these.
* Incoming data/voice/"extern"al calls
won't be handled by default.
I have never tested or used these.
Take two of #40708 (4fe2898608).
That PR attempted to bidirectionally default `config.nixpkgs.system` and
`config.nixpkgs.localSystem.system` to each be updated by the other. But
this is not possible with the way the module system works. Divergence in
certain cases in inevitable.
This PR is more conservative and just has `system` default `localSystem`
and `localSystem` make the final call as-is. This solves a number of
issues.
- `localSystem` completely overrides `system`, just like with nixpkgs
proper. There is no need to specify `localSystem.system` to clobber the
old system.
- `config.nixpkgs.localSystem` is exactly what is passed to nixpkgs. No
spooky steps.
- `config.nixpkgs.localSystem` is elaborated just as nixpkgs would so
that all attributes are available, not just the ones the user
specified.
The remaining issue is just that `config.nixpkgs.system` doesn't update
based on `config.nixpkgs.localSystem.system`. It should never be
referred to lest it is a bogus stale value because
`config.nixpkgs.localSystem` overwrites it.
Fixes #46320
This adds several improvements the previously introduced
`services.weechat` module:
* Dropped `services.weechat.init` as the initialization script can now
be done on package-level since 2af41719bc using the `configure`
function.
* Added `sessionName` option to explicitly configure a name for the
`screen` session (by default: weechat-screen).
* Added `binary` option to configure the binary name (e.g.
`weechat-headless`).
* Added docs regarding `screen` session and `weechat.service`.
Previously it was only possible to use very simple Riemann config.
For more complicated scenarios you need a directory of clojure
files and the config file that riemann starts with should be in this
directory.
This fixes an issue with shells like fish that are not fully POSIX
compliant. The syntax `ENV=val cmd' doesn't work properly in there.
This issue has been addressed in #45932 and #45945, however it has been
recommended to use a single shell (`stdenv.shell' which is either
`bash' or `sh') to significantly reduce the maintenance overload in the
future.
See https://github.com/NixOS/nixpkgs/issues/45897#issuecomment-417923464
Fixes #45897
/cc @FRidh @xaverdh @etu
Some programs like eog seem to need dconf accessible on dbus.
Without this change I get
(eog:1738): dconf-WARNING **: 21:20:52.770: failed to commit changes to
dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
ca.desrt.dconf was not provided by any .service files
This fixes a regression introduced in commit
700e21d6da
nix needs ssh on path for the SSH substituter functionality,
not only the distributed builds functionality.
Signed-off-by: Niklas Hambüchen <mail@nh2.me>
Although double '/' in paths is not a problem for GRUB supplied with nixpkgs, sometimes NixOS's grub.conf read by external GRUB and there are versions of GRUB which fail
The switch from slim to lightdm in #30890 broke some nixos tests
because lightdm by default doesn't permit auto-login for root.
Override /etc/pam.d/lightdm-autologin to allow it.
The option was added in 1251b34b5b
with type `types.path` but default `null`, so eval failed with
the default setting. This broke the acme and certmgr tests.
cc: @vincentbernat @fpletz
This is the semantics as understood by `xdg-open`. Using these semantics
on a non-colon-separated variable works because it acts as if it was a
one element long list.
This fixes an issue where it would try to exec
`google-chrome-beta:google-chrome:chromium:firefox` on a system
configured with these semantics in mind.
The instructions to install nixos behind a proxy were not clear. While
one could guess that setting http_proxy variables can get the install
rolling, one could end up with an installed system where the proxy
settings for the nix-daemon are not configured.
This commit updates the documentation with
1. steps to install behind a proxy
2. configure the global proxy settings so that nix-daemon can access
internet.
3. Pointers to use nesting.clone in case one has to use different proxy
settings on different networks.
Switch from slim to lightdm as the display-manager.
If plasma5 is used as desktop-manager use sdddm.
If gnome3 is used as desktop-manager use gdm.
Based on #12516
The recommended TLS configuration comes with `ssl_stapling on` and
`ssl_stapling_verify on`. However, this last directive also requires
the use of `ssl_trusted_certificate` to verify the received answer.
When using `enableACME` or similar, we can help the user by providing
the correct value for the directive.
The result can be tested with:
openssl s_client -connect web.example.com:443 -status 2> /dev/null
Without OCSP stapling, we get:
OCSP response: no response sent
After this change, we get:
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Produced At: Aug 30 20:46:00 2018 GMT
A shared exported guard `__NIXOS_SET_ENVIRONMENT_DONE` is introduced that can
be used to prevent child shells from sourcing `system.build.setEnvironment`
the second time.
This fixes e.g. `nix run derivation` when run from e.g. ZSH through the console or
ssh. Before this Bash would resource the common environment resetting the `PATH`
environment variable.
We also export `system.build.setEnvironment` to `/etc/set-environment` making it
easy to reset the common environment with `. /etc/set-environment` when
needed and to grep for environment variables in `/etc` (which was the
motivation of #30418).
This reverts changes made in b00a3fc6fd
(the original #30418).
This allows one to add rules which change a packet's routing table:
iptables -t raw -I PREROUTING 1 -m set --match-set myset src -j MARK --set-mark 2
ip rule add fwmark 2 table 1 priority 1000
ip route add default dev wg0 table 1
to the beginning of raw table PREROUTING chain, and still have rpfilter.
DefaultTimeoutStartSec is normally set to 90 seconds and works fine. But
when running NixOS tests on a very slow machine (like a VM without
nested virtualisation support) this default is to low and causes
systemd units to fail spuriously. One symptom of this issue are tests
at times failing with "timed out waiting for the VM to connect".
Since the VM connect timeout is 300 seconds I also set
DefaultTimeoutStartSec to this which is ridiculously high.
The background color option is self-explanatory.
The mode is either `normal` or `stretch`, they are as defined by GRUB,
where normal will put the image in the top-left corner of the menu, and
stretch is the default, where it stretches the image without
consideration for the aspect ratio.
* https://www.gnu.org/software/grub/manual/grub/grub.html#background_005fimage
The wallpaper used is *structurally compatible* with the other one,
meaning that the logo is at the same location, and not bigger.
It has one drawback: the logo is brighter, which clashes with the grub
usage. This is to be fixed with new options in grub.
- default coreutils is stripped of /share/ (11 -> 2 MiB)
- coreutils-full retains /share/ and adds openssl for faster *sum tools
- NixOS systemPackages contains coreutils-full
- *Support parameter defaults are moved inside
(it seemed confusing to have `? false` and "at once" with `? isLinux`)
Closure considerations:
+ typical build-time closure will get lighter by ~9 MiB
- typical closure of NixOS installation will grow by ~2 MiB,
due to referring to both versions. I think it would be possible to
re-use most of the utils between the two versions, but the expression
would get much more complex.
I considered having stdenv with minimal coreutils and the default
`coreutils` attribute being full, but it turned out there were too many
trivial references in nixpkgs, so it didn't seem easy to keep rebuild
impact of openssl from growing significantly.
The additions are:
- image/svg+xml for SVG images
- application/atom+xml for Atom feeds
These types are also present in mime.types. For better readability,
the list is sorted and formatted with one type per line.
This prevents issues when gitea adds new locales etc. And if they
change locale values in future versions. Or if you rollback to a
previous version of gitea it might be a good idea to use the previous
locale files.
This is a 277K (as of right now) addition that can greatly help in some
last recourse scenarios. The specific rEFInd setup will not be able to
boot the installer image, but this is not why it has been added. It has
been added to make use of its volumes scanning capabilities to boot
existing EFI images on the target computer, which is sometimes necessary
with buggy EFI. While is isn't NixOS's job to fix buggy EFI, shipping
this small bit with the installer will help the unlucky few.
Example scenario: two wildly different EFI implementation I have
encountered have fatal flaws in which they sometimes will lose all the
settings, this includes boot configuration. This is compounded by the
fact that the two specific and distinct implementation do not allow
manually adding ESP paths from their interface. The only recourse is to
let the EFI boot the default paths, EFI/boot/boot{platform}.efi, which
is not a default location used by the NixOS bootloaders. rEFInd is able
to scan the volumes and detect the existing efi bootloaders, and boot
them successfully.
Following up https://github.com/NixOS/nixpkgs/pull/23665
Bootable USB-drives are not limited to ISO-images, there can be "normal" MBR/GPT-partitioned disk connected via USB-rack.
Also, "uas" implies "usb-storage", so there is no need to mention both.
thermald has two modes: zero-config and manual. Sometimes it is useful
to manually configure thermald to achieve better thermal results or to give
thermald a hand when detecting possible cooling options.
I broke it:
in job ‘nixos.iso_graphical.x86_64-linux’:
The option `services.udisks2.enable' has conflicting definitions, in `/nix/store/bwcjw1ddj94q83vbbnq1nnrs5aisaw59-source/nixos/modules/profiles/installation-device.nix' and `/nix/store/bwcjw1ddj94q83vbbnq1nnrs5aisaw59-source/nixos/modules/services/x11/desktop-managers/plasma5.nix'.
And don't need to source the uevent files anymore either since $MAJOR
or $MINOR aren't used elsewhere.
[dezgeg: The reason these are no longer needed is that 0d27df280f
switched /tmp to a devtmpfs which automatically creates such device
nodes]
