The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
Configuration option for setting up virtual WLAN interfaces.
If the hardware NIC supports it, then multiple virtual WLAN interfaces can be
configured through the options of the new 'networking.wlanInterfaces' module.
For example, the following configuration transforms the device with the persistent
udev name 'wlp6s0' into a managed and a ad hoc device with the device names
'wlan-managed0' and 'wlan-adhoc0', respectively:
networking.wlanInterfaces = {
"wlan-managed0" = {
type = "managed";
device = "wlp6s0";
};
"wlan-adhoc0" = {
type = "ibss";
device = "wlp6s0";
};
};
Internally, a udev rule is created that matches wlp6s0 and runs a script which adds
the missing virtual interfaces and re-configures the wlp6s0 interface accordingly.
Once the new interfaces are created by the Linux kernel, the configuration of the
interfaces is managed by udev and systemd in the usual way.
The default options for all file systems currently are
"defaults.relatime", which works well on file systems which support the
relatime option.
Unfortunately, this is not the case for the VirtualBox shared folder
filesystem, so until now, you need to set something like:
fileSystems."/foo" = {
device = "foo";
fsType = "vboxsf";
options = "defaults";
};
Otherwise mounting the file system would fail.
Now, we provide only the "defaults" option to the "vboxsf" file system,
so something like this is enough:
fileSystems."/foo" = {
device = "foo";
fsType = "vboxsf";
};
An alternative to that could be to document that you need to set default
options, but we really should do what users expect instead of forcing
them to look up the documentation as to why this has failed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
If you power off your machine frequently, you could miss the execution
of some snapshots.
This is more troublesome the more infrequently the snapshots are
triggered. For example, monthly snapshots only execute at exactly
midnight on the first day of the month. If you only have your
machine powered on at that time with probability 50%, then half the
snapshots won't be triggered.
This means that if you wanted to keep 3 monthly snapshots, then instead
of keeping 3 months' worth of snapshotted data as you expected, you would
end up with snapshots spanning back 6 months.
Adding the "Persistent = yes" option to auto-snapshot timer units makes
a missed snapshot execute when booting up the machine.
Otherwise, in certain cases, snapshots of infrequently-modified
filesystems can be kept for a much longer time than the user would
normally expect, and cause a large amount of extra disk space to be
consumed.
Also added flag to snapshot filesystems in parallel by default.
I've also added a configuration option for zfs-auto-snapshot flags, so
that the user can override them.
For example, the user may want to append --utc to the list of default
options, so that the snapshot names don't cause name conflicts or
apparent time reversals due to daylight savings or timezone changes.
The old boot.spl.hostid option was not working correctly due to an
upstream bug.
Instead, now we will create the /etc/hostid file so that all applications
(including the ZFS kernel modules, ZFS user-space applications and other
unrelated programs) pick-up the same system-wide host id. Note that glibc
(and by extension, the `hostid` program) also respect the host id configured in
/etc/hostid, if it exists.
The hostid option is now mandatory when using ZFS because otherwise, ZFS will
require you to force-import your ZFS pools if you want to use them, which is
undesirable because it disables some of the checks that ZFS does to make sure it
is safe to import a ZFS pool.
The /etc/hostid file must also exist when booting the initrd, before the SPL
kernel module is loaded, so that ZFS picks up the hostid correctly.
The complexity in creating the /etc/hostid file is due to having to
write the host ID as a 32-bit binary value, taking into account the
endianness of the machine, while using only shell commands and/or simple
utilities (to avoid exploding the size of the initrd).
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
Also remove custom zfs services from NixOS. This makes NixOS more aligned with
upstream.
More importantly, it prepares the way for NixOS to use ZED (the ZFS event
daemon). This service will automatically be enabled but it is not possible to
configure it via configuration.nix yet.
I'm not using JFS, but this is to mainly make jfsutils available if you
have defined a JFS filesystem in your configuration.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
