Re: [Nix-dev] Help wanted with Nixos on ZFS in an encrypted LUKS volume
Hi Vince, NixOS does support ZFS on top of an encrypted LUKS volume (I've been using this configuration myself for years), but I'm not 100% sure it will work fine in your particular situation. The error you are seeing is because ZFS is detecting 2 (or more) ZFS pools with the same name in your system. This usually happens when you're fiddling with ZFS pool creation using different partition layouts and do not properly destroy a pool before creating another one with the same name. As specified in the error message, this can be solved by specifying the ZFS pool by its ID number instead of by name, e.g., by changing all instances of the string "zroot" in your NixOS configuration to the ID number of the pool. That said, I've never seen a NixOS configuration like this, so I'm not 100% sure it will work correctly (feel free to file a new bug if this type of configuration doesn't work). To find out the ID number of the correct ZFS pool, you will have to run (possibly in a LiveCD environment) the "zpool import" command and look at the ID number of the correct ZFS pool (where "correct" is the one that is located in your LUKS partition, and both the pool state and all its devices are in the "ONLINE" state). See below for a sample output of the "zpool import" command when 2 ZFS pools have the same name [1]. That said, the easiest way to fix your issue, and my recommendation, is for you to perform a new installation but this time create the ZFS pool only once, on top of your LUKS volume, with a new name (such as "rpool" instead of "zroot", for example). This will avoid any ambiguities as to where your ZFS pool is located. I hope this helps! [1] $ zpool import pool: test id: 18056344713568302535 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: test ONLINE /tmp/test2.tmp ONLINE pool: test id: 12658723009881072891 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: test ONLINE /tmp/test1.tmp ONLINE On Sun, Apr 2, 2017 at 9:06 PM, wrote: > Hi fellow Nix enthusiasts, > > I'm trying to install Nixos on a ZFS root filesystem which in turn resides > in an encrypted volume (using LUKS). > I already succeeded in a minimal ZFS install on an unencrypted partition, > and I also succeeded in installing in an encrypted LUKS volume with ext4 as > root fs. > But with the combination I get errors during stage 1; the zpool that > contains the root dataset cannot be imported. This occurs after I enter the > correct LUKS passphrase. > This made me question if this is at all possible (it should, shouldn't > it?). Could some of you please take a look? I documented most of it in the > gist here: https://gist.github.com/awesomefireduck/ > ffea6517042af87b8b7ef6ea1c7d50e3 . If you need more information I'd be > happy to supply it. > > Sincerely, > Vince > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] d9ae88: nixos.openntpd: don't spam systemd journal
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: d9ae88694695c21d599790c4fdebc3fa062ddaa1 https://github.com/NixOS/nixpkgs/commit/d9ae88694695c21d599790c4fdebc3fa062ddaa1 Author: Ricardo M. Correia Date: 2017-02-20 (Mon, 20 Feb 2017) Changed paths: M nixos/modules/services/networking/openntpd.nix Log Message: --- nixos.openntpd: don't spam systemd journal Starting `ntpd` with the `-d` option spams the systemd journal. Instead, let the server fork. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] fca091: pycurl: 7.19.5 -> 7.19.5.1
Branch: refs/heads/staging Home: https://github.com/NixOS/nixpkgs Commit: fca09185d0021256a28b1a2cb710b197e3a08bd6 https://github.com/NixOS/nixpkgs/commit/fca09185d0021256a28b1a2cb710b197e3a08bd6 Author: Ricardo M. Correia Date: 2017-02-18 (Sat, 18 Feb 2017) Changed paths: M pkgs/top-level/python-packages.nix Log Message: --- pycurl: 7.19.5 -> 7.19.5.1 Fixes import error when curl was built with LibreSSL. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] f78f20: nixos.samba: add enableNmbd and enableWinbindd opt...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: f78f207f1775fbf37c67e546b77ba206c107da36 https://github.com/NixOS/nixpkgs/commit/f78f207f1775fbf37c67e546b77ba206c107da36 Author: Ricardo M. Correia Date: 2017-02-18 (Sat, 18 Feb 2017) Changed paths: M nixos/modules/services/network-filesystems/samba.nix Log Message: --- nixos.samba: add enableNmbd and enableWinbindd options This allows for disabling these services, in case they are not needed. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Python 3 as default
On Tue, Feb 14, 2017 at 2:34 PM, Profpatsch wrote: > On 17-02-14 01:18pm, Peter Simons wrote: > > I hardly ever use nix-shell and I don't want to, to > > be honest > > Completely off-discussion: Why is that? > Convenience? nix-shell does too many strange things? > > Personally I use nix-shell for nearly everything I do > nowadays because it’s so convenient. > Even a buildFHSUserEnv is quickly set up for strange software. > Personally, I try to avoid using "nix-shell" as much as possible because I want "nixos-rebuild switch" to atomically install (and upgrade) all the software that I usually need, including development packages. With nix-shell, I risk having the packages I need become outdated (without me noticing) and/or become garbage collected (which I do every day automatically) and unavailable if I lose Internet access (e.g. because I'm traveling). ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] c19b17: raspberryPi boot loader: fix booting Raspberry Pi ...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: c19b17d14ff25a86bc4b563999bfa3569344d16a https://github.com/NixOS/nixpkgs/commit/c19b17d14ff25a86bc4b563999bfa3569344d16a Author: Ricardo M. Correia Date: 2017-02-12 (Sun, 12 Feb 2017) Changed paths: M nixos/modules/system/boot/loader/raspberrypi/builder.sh M nixos/modules/system/boot/loader/raspberrypi/raspberrypi.nix Log Message: --- raspberryPi boot loader: fix booting Raspberry Pi 3 The Raspberry Pi 3 seems to need the .DTB file when booting the kernel, so we must copy it to /boot when installing a new kernel. Commit: 123cbd40c244c84a1caebce9082aa3704be7f57c https://github.com/NixOS/nixpkgs/commit/123cbd40c244c84a1caebce9082aa3704be7f57c Author: Ricardo M. Correia Date: 2017-02-12 (Sun, 12 Feb 2017) Changed paths: M nixos/modules/system/boot/loader/raspberrypi/builder.sh Log Message: --- raspberryPi boot loader: don't remove xx-initrd files The Raspberry Pi boot loader was deleting all xx-initrd text files (which simply contain the path to the actual initrd files) just after having created them. The code was actually trying to delete real, obsolete initrd files, which are named -initrd-initrd (after path cleaning), but the glob was catching the other files as well. Compare: https://github.com/NixOS/nixpkgs/compare/0045f932bba0...123cbd40c244___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 30c3fd: mkpasswd: make the package high priority
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 30c3fdedfefb2ad991f9dc827f282718e4180e3b https://github.com/NixOS/nixpkgs/commit/30c3fdedfefb2ad991f9dc827f282718e4180e3b Author: Ricardo M. Correia Date: 2017-01-25 (Wed, 25 Jan 2017) Changed paths: M pkgs/top-level/all-packages.nix Log Message: --- mkpasswd: make the package high priority Otherwise, if you have the `expect` package installed, its `mkpasswd` program can override the one from the `mkpasswd` package. If that happens, the NixOS documentation instructions for generating a hashed password to put into `configuration.nix` will not work. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 1b7984: ocamlPackages.containers: 0.20 -> 0.22
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 1b79847e75847686d04f135aaf6dac8cf797d080 https://github.com/NixOS/nixpkgs/commit/1b79847e75847686d04f135aaf6dac8cf797d080 Author: Vincent Laporte Date: 2016-12-20 (Tue, 20 Dec 2016) Changed paths: M pkgs/development/ocaml-modules/containers/default.nix Log Message: --- ocamlPackages.containers: 0.20 -> 0.22 Commit: 04a9e07bbd18c83047dd2dbe405367aac4d6e057 https://github.com/NixOS/nixpkgs/commit/04a9e07bbd18c83047dd2dbe405367aac4d6e057 Author: Ricardo M. Correia Date: 2016-12-21 (Wed, 21 Dec 2016) Changed paths: M pkgs/development/ocaml-modules/containers/default.nix Log Message: --- Merge pull request #21295 from vbgl/containers-0.22 ocamlPackages.containers: 0.20 -> 0.22 Compare: https://github.com/NixOS/nixpkgs/compare/48fa032aae01...04a9e07bbd18___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] cda472: rustRegistry: 2016-12-03 -> 2016-12-16
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: cda47275f4c40064907ca08c9d7beabd496859b5 https://github.com/NixOS/nixpkgs/commit/cda47275f4c40064907ca08c9d7beabd496859b5 Author: mimadrid Date: 2016-12-17 (Sat, 17 Dec 2016) Changed paths: M pkgs/top-level/rust-packages.nix Log Message: --- rustRegistry: 2016-12-03 -> 2016-12-16 Commit: 2077a60c2f179afa7d608adac4a9248cff86a80f https://github.com/NixOS/nixpkgs/commit/2077a60c2f179afa7d608adac4a9248cff86a80f Author: mimadrid Date: 2016-12-17 (Sat, 17 Dec 2016) Changed paths: M pkgs/tools/text/ripgrep/default.nix Log Message: --- ripgrep: 0.2.1 -> 0.3.2 Commit: 096e8ab45f817db41bd5d50352c901c73843af2e https://github.com/NixOS/nixpkgs/commit/096e8ab45f817db41bd5d50352c901c73843af2e Author: Ricardo M. Correia Date: 2016-12-17 (Sat, 17 Dec 2016) Changed paths: M pkgs/tools/text/ripgrep/default.nix M pkgs/top-level/rust-packages.nix Log Message: --- Merge pull request #21218 from mimadrid/update/ripgrep-0.3.2 ripgrep: 0.2.1 -> 0.3.2 Compare: https://github.com/NixOS/nixpkgs/compare/9a5002039844...096e8ab45f81___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] dcee42: ponyc: 0.9.0 -> 0.10.0
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: dcee4214b9fb29f42e69da27a4c6069f75c9e6f1 https://github.com/NixOS/nixpkgs/commit/dcee4214b9fb29f42e69da27a4c6069f75c9e6f1 Author: Kamil Chmielewski Date: 2016-12-13 (Tue, 13 Dec 2016) Changed paths: M pkgs/development/compilers/ponyc/default.nix Log Message: --- ponyc: 0.9.0 -> 0.10.0 Commit: 6b89121c209c6aa44ef0268ed9462ed89f585393 https://github.com/NixOS/nixpkgs/commit/6b89121c209c6aa44ef0268ed9462ed89f585393 Author: Ricardo M. Correia Date: 2016-12-13 (Tue, 13 Dec 2016) Changed paths: M pkgs/development/compilers/ponyc/default.nix Log Message: --- Merge pull request #21126 from kamilchm/ponyc ponyc: 0.9.0 -> 0.10.0 Compare: https://github.com/NixOS/nixpkgs/compare/69ce9a9edde3...6b89121c209c___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 751b91: pepperflash: 22.0.0.205 -> 23.0.0.207
Branch: refs/heads/release-16.09 Home: https://github.com/NixOS/nixpkgs Commit: 751b9188cc714dba0db5767e56efac2085538bd6 https://github.com/NixOS/nixpkgs/commit/751b9188cc714dba0db5767e56efac2085538bd6 Author: Ricardo M. Correia Date: 2016-11-18 (Fri, 18 Nov 2016) Changed paths: M pkgs/applications/networking/browsers/chromium/plugins.nix Log Message: --- pepperflash: 22.0.0.205 -> 23.0.0.207 (cherry picked from commit 6dfd4f5b08199f7c23f63318f6f7a928906a1859) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 6dfd4f: pepperflash: 23.0.0.205 -> 23.0.0.207
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 6dfd4f5b08199f7c23f63318f6f7a928906a1859 https://github.com/NixOS/nixpkgs/commit/6dfd4f5b08199f7c23f63318f6f7a928906a1859 Author: Ricardo M. Correia Date: 2016-11-18 (Fri, 18 Nov 2016) Changed paths: M pkgs/applications/networking/browsers/chromium/plugins.nix Log Message: --- pepperflash: 23.0.0.205 -> 23.0.0.207 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 5b59e9: ocamlPackages.menhir: 20160526 -> 20161115
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 5b59e91f7351559b62b354744f3028264ebb1cb9 https://github.com/NixOS/nixpkgs/commit/5b59e91f7351559b62b354744f3028264ebb1cb9 Author: Vincent Laporte Date: 2016-11-17 (Thu, 17 Nov 2016) Changed paths: M pkgs/development/ocaml-modules/menhir/default.nix Log Message: --- ocamlPackages.menhir: 20160526 -> 20161115 Commit: 58a18d167636dcbdd765ed78f0345414c8eebfe3 https://github.com/NixOS/nixpkgs/commit/58a18d167636dcbdd765ed78f0345414c8eebfe3 Author: Ricardo M. Correia Date: 2016-11-17 (Thu, 17 Nov 2016) Changed paths: M pkgs/development/ocaml-modules/menhir/default.nix Log Message: --- Merge pull request #20501 from vbgl/menhir-20161115 ocamlPackages.menhir: 20160526 -> 20161115 Compare: https://github.com/NixOS/nixpkgs/compare/711a42e03aa4...58a18d167636___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 3f6c9c: nixos.libvirtd: fix broken VMs due to emulator pat...
Branch: refs/heads/release-16.09 Home: https://github.com/NixOS/nixpkgs Commit: 3f6c9cceeace789760b17e1998d03aeede16b93f https://github.com/NixOS/nixpkgs/commit/3f6c9cceeace789760b17e1998d03aeede16b93f Author: Ricardo M. Correia Date: 2016-11-03 (Thu, 03 Nov 2016) Changed paths: M nixos/modules/virtualisation/libvirtd.nix Log Message: --- nixos.libvirtd: fix broken VMs due to emulator path changes This had already been fixed in f52f9bf7cd922b54c874e5500a2c64277e57d417, but the problem was reintroduced in bce59a1a8bb0430533178df080937ce24efe926a because the path to the XML files changed. (cherry picked from commit af01fa71e0787c66c4f7e6fa88f8ee525959cd26) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] af01fa: nixos.libvirtd: fix broken VMs due to emulator pat...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: af01fa71e0787c66c4f7e6fa88f8ee525959cd26 https://github.com/NixOS/nixpkgs/commit/af01fa71e0787c66c4f7e6fa88f8ee525959cd26 Author: Ricardo M. Correia Date: 2016-11-03 (Thu, 03 Nov 2016) Changed paths: M nixos/modules/virtualisation/libvirtd.nix Log Message: --- nixos.libvirtd: fix broken VMs due to emulator path changes This had already been fixed in f52f9bf7cd922b54c874e5500a2c64277e57d417, but the problem was reintroduced in bce59a1a8bb0430533178df080937ce24efe926a because the path to the XML files changed. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 7da48d: ocamlPackages.gen: 0.3 -> 0.4
Branch: refs/heads/master
Home: https://github.com/NixOS/nixpkgs
Commit: 7da48dec309127c2a08432137534703e8be86b9f
https://github.com/NixOS/nixpkgs/commit/7da48dec309127c2a08432137534703e8be86b9f
Author: Vincent Laporte
Date: 2016-10-26 (Wed, 26 Oct 2016)
Changed paths:
M pkgs/development/ocaml-modules/gen/default.nix
Log Message:
---
ocamlPackages.gen: 0.3 -> 0.4
Commit: 29f3eaef7ad4d2cd0ea3ae70e34d3f02ece3e50f
https://github.com/NixOS/nixpkgs/commit/29f3eaef7ad4d2cd0ea3ae70e34d3f02ece3e50f
Author: Vincent Laporte
Date: 2016-10-26 (Wed, 26 Oct 2016)
Changed paths:
M pkgs/development/ocaml-modules/sequence/default.nix
Log Message:
---
ocamlPackages.sequence: 0.6 -> 0.8
Commit: 0336a06d0e759bd6bad1db25c665b23433ad2450
https://github.com/NixOS/nixpkgs/commit/0336a06d0e759bd6bad1db25c665b23433ad2450
Author: Vincent Laporte
Date: 2016-10-26 (Wed, 26 Oct 2016)
Changed paths:
M pkgs/development/ocaml-modules/containers/default.nix
Log Message:
---
ocamlPackages.containers: 0.18 -> 0.20
Commit: 3c6e0f1207193c4395183350d0ef878167da89bd
https://github.com/NixOS/nixpkgs/commit/3c6e0f1207193c4395183350d0ef878167da89bd
Author: Ricardo M. Correia
Date: 2016-10-31 (Mon, 31 Oct 2016)
Changed paths:
M pkgs/development/ocaml-modules/containers/default.nix
M pkgs/development/ocaml-modules/gen/default.nix
M pkgs/development/ocaml-modules/sequence/default.nix
Log Message:
---
Merge pull request #19901 from vbgl/ocaml-containers-20
Update ocamlPackages.{gen,sequence,containers}
Compare: https://github.com/NixOS/nixpkgs/compare/f6c61ebe3d27...3c6e0f120719___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 47e619: ocaml-react: fix hash
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 47e61969b852a23d9059108b9356dad9ae515616 https://github.com/NixOS/nixpkgs/commit/47e61969b852a23d9059108b9356dad9ae515616 Author: Ricardo M. Correia Date: 2016-10-14 (Fri, 14 Oct 2016) Changed paths: M pkgs/development/ocaml-modules/react/default.nix Log Message: --- ocaml-react: fix hash The package had been updated from 1.1.0 -> 1.2.0 but the hash hadn't. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 4e14fd: nixos.acme: make timer persistent
Branch: refs/heads/release-16.09 Home: https://github.com/NixOS/nixpkgs Commit: 4e14fd5d5aac14a17c28465104b7ffacf27d9579 https://github.com/NixOS/nixpkgs/commit/4e14fd5d5aac14a17c28465104b7ffacf27d9579 Author: Ricardo M. Correia Date: 2016-10-04 (Tue, 04 Oct 2016) Changed paths: M nixos/modules/security/acme.nix Log Message: --- nixos.acme: make timer persistent This makes sure that if the system was powered off when the timer was supposed to trigger, it will run the next time the system boots up. (cherry picked from commit 16234769046a1edb4451fbdf0745c09a6c158527) Reason: Unobtrusive patch that may fix broken/outdated TLS certificates, depending on your powered-on/powered-off patterns. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 5688c3: zfs: Keep trying root import until it works
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: 5688c39af5a6c5f3d646343443683da880eaefb8 https://github.com/NixOS/nixpkgs/commit/5688c39af5a6c5f3d646343443683da880eaefb8 Author: Svein Ove Aas Date: 2016-08-18 (Thu, 18 Aug 2016) Changed paths: M nixos/modules/tasks/filesystems/zfs.nix Log Message: --- zfs: Keep trying root import until it works Works around #11003. (cherry picked from commit 98b213a11041af39b39473906b595290e2a4e2f9) Reason: several people cannot boot with ZFS on NVMe Commit: a53bb3ceb173924bdb1f646fe5d6663651897c27 https://github.com/NixOS/nixpkgs/commit/a53bb3ceb173924bdb1f646fe5d6663651897c27 Author: Ricardo M. Correia Date: 2016-08-18 (Thu, 18 Aug 2016) Changed paths: M nixos/modules/tasks/filesystems/zfs.nix Log Message: --- zfs: print the output of the zpool command (if any) when it succeeds (cherry picked from commit 1cf9bcaa3f84e3058a8b48ef36f97d8dee841df6) Compare: https://github.com/NixOS/nixpkgs/compare/81a8ce866812...a53bb3ceb173___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 1cf9bc: zfs: print the output of the zpool command (if any...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 1cf9bcaa3f84e3058a8b48ef36f97d8dee841df6 https://github.com/NixOS/nixpkgs/commit/1cf9bcaa3f84e3058a8b48ef36f97d8dee841df6 Author: Ricardo M. Correia Date: 2016-08-18 (Thu, 18 Aug 2016) Changed paths: M nixos/modules/tasks/filesystems/zfs.nix Log Message: --- zfs: print the output of the zpool command (if any) when it succeeds ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 98b213: zfs: Keep trying root import until it works
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 98b213a11041af39b39473906b595290e2a4e2f9 https://github.com/NixOS/nixpkgs/commit/98b213a11041af39b39473906b595290e2a4e2f9 Author: Svein Ove Aas Date: 2016-08-16 (Tue, 16 Aug 2016) Changed paths: M nixos/modules/tasks/filesystems/zfs.nix Log Message: --- zfs: Keep trying root import until it works Works around #11003. Commit: c2e5fd959d84cef0b62762df05e17c0748ffbb9f https://github.com/NixOS/nixpkgs/commit/c2e5fd959d84cef0b62762df05e17c0748ffbb9f Author: Ricardo M. Correia Date: 2016-08-18 (Thu, 18 Aug 2016) Changed paths: M nixos/modules/tasks/filesystems/zfs.nix Log Message: --- Merge pull request #16901 from Baughn/zfs-nvme-fix zfs: Keep trying root import until it works Compare: https://github.com/NixOS/nixpkgs/compare/409b53cba85d...c2e5fd959d84___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] cbb8ee: rustPackages: 2016-07-26 -> 2016-08-10
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: cbb8ee28b5725adffb2ad6df738e8117df118a94 https://github.com/NixOS/nixpkgs/commit/cbb8ee28b5725adffb2ad6df738e8117df118a94 Author: Ricardo M. Correia Date: 2016-08-10 (Wed, 10 Aug 2016) Changed paths: M pkgs/top-level/rust-packages.nix Log Message: --- rustPackages: 2016-07-26 -> 2016-08-10 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 0a4178: ponyc: 0.2.1 -> 2016-07-26
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 0a417845ef00c6964dd2ecf040055bfc3dc7f1f1 https://github.com/NixOS/nixpkgs/commit/0a417845ef00c6964dd2ecf040055bfc3dc7f1f1 Author: Ricardo M. Correia Date: 2016-08-02 (Tue, 02 Aug 2016) Changed paths: M pkgs/development/compilers/ponyc/default.nix A pkgs/development/compilers/ponyc/disable-tests.patch M pkgs/top-level/all-packages.nix Log Message: --- ponyc: 0.2.1 -> 2016-07-26 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 24d1d1: menhir: 20160303 -> 20160526 (#17343)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 24d1d19bd2f8f55f6740e9495d2b76c1218d2b7b https://github.com/NixOS/nixpkgs/commit/24d1d19bd2f8f55f6740e9495d2b76c1218d2b7b Author: Ricardo M. Correia Date: 2016-07-29 (Fri, 29 Jul 2016) Changed paths: M pkgs/development/ocaml-modules/menhir/default.nix Log Message: --- menhir: 20160303 -> 20160526 (#17343) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 2df3fd: ocamlPackage.ppx_blob: init at 0.2 (#17129)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 2df3fde700daf20a00188de616e677bc57c9794f https://github.com/NixOS/nixpkgs/commit/2df3fde700daf20a00188de616e677bc57c9794f Author: Ricardo M. Correia Date: 2016-07-21 (Thu, 21 Jul 2016) Changed paths: A pkgs/development/ocaml-modules/ppx_blob/default.nix M pkgs/top-level/all-packages.nix Log Message: --- ocamlPackage.ppx_blob: init at 0.2 (#17129) OCaml ppx to include binary data from a file as a string. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Haskell-env (via nix-shell) - am I doing this right?
On Fri, May 22, 2015 at 8:16 PM, Peter Jones wrote: > To start out, I'm using HaskellNG and a recent version of nixpkgs where > HaskellNG is the default. Here are the components I use with some > examples: > > 1) I write a default.nix that describes my dependencies: > > https://github.com/pjones/byline/blob/master/default.nix Thanks for the example! Out of curiosity, why is that "shellHook" stuff needed on every package? Couldn't "ghcWithPackages" export those variables instead (as a "setupHook ")? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ZFS on NixOS regarding the `/etc/zfs/zpool.cache` file.
I commented on that commit, but just in case, for future readers: If you add: boot.supportedFilesystems = [ "zfs" ]; ... to your configuration.nix, then /etc/zfs will be created, and /etc/zfs/zpool.cache will also be created when you import or create a ZFS pool. If you have this option in your configuration.nix and import a pool but even so, zpool.cache isn't created, please file a new issue in the nixpkgs github repository. (BTW, you can also, you can use the "zdb -e" option to invoke zdb on pools that don't have a cache file, but it's better to add "zfs" to the list of supported filesystems). On Tue, Apr 28, 2015 at 6:11 AM, Roger Qiu wrote: > Hello, > > I found the commit relating to my problem: > > https://github.com/NixOS/nixpkgs/commit/12e77fdc3f6f223be1a4d5c88d6c79bff63ae70c#commitcomment-10932244 > > I made a comment regarding the lack of zpool.cache file. It's required > for `zdb` to work. Perhaps we can generate the `zpool.cache` file at > startup? > > Thanks, > Roger > > On 28/04/2015 3:22 PM, Roger Qiu wrote: > > Hi, > > > > To people using ZFS on NixOS, does your `zdb` command work? > > > > I tried using `zdb` and it just gives: > > > > ``` > > cannot open '/etc/zfs/zpool.cache': No such file or directory > > ``` > > > > This file `/etc/zfs/zpool.cache` file does not exist if you follow the > > instructions regarding installing ZFS on NixOS. > > > > This line > > > https://github.com/NixOS/nixos/blob/master/modules/tasks/filesystems/zfs.nix#L6 > > hints that the current ZFS package doesn't handle the > > `/etc/zfs/zpool.cache` file. > > > > What's missing, and how would we set up the `zpool.cache` file? > > > > Thanks, > > Roger > > > > > > -- > > Founder of Matrix AI > > http://matrix.ai/ > > +61420925975 > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Bash CVE-2014-6271
Shea: I wasn't even using replaceDependency... and dry-run started compiling/downloading anyway, like if I had done a switch. Isn't this happening to anyone else who is using a recent commit from the unstable/master channel? On Mon, Sep 29, 2014 at 2:12 AM, Shea Levy wrote: > The dry-run thing is likely due to replaceDependency doing an import > from a derivation, which requires building at evaluation time. There's > not really a good way to work around that, unfortunately. > > ~Shea > > On Mon, Sep 29, 2014 at 12:52:10AM +0200, Ricardo M. Correia wrote: > > On Sun, Sep 28, 2014 at 10:19 AM, Vladimír Čunát > wrote: > > > > > On 09/25/2014 03:41 PM, Ricardo M. Correia wrote: > > > > > >> Also, I'm not sure if this is expected, but when I first tried to run > > >> "nixos-rebuild dry-run" with this workaround applied, it started to > > >> download and compile bash even though the man page of nixos-rebuild > > >> specifically says: [...] > > >> > > > > > > IIRC there are two steps -- first build nix, and then do the dry-run > (or > > > switch or anything else). Nix also needs its bash replaced, so first > you > > > need to build the bash replacement. That is, unless you specify > > > --no-build-nix option. > > > > > > > That's what I thought too after reflecting on it a bit more, but now I'm > > starting to think that there is a real bug. > > > > I just tried to run "nixos-rebuild dry-run" (in preparation for testing > > roconner's performance improvement) and it started to compile > rustcMaster! > > (I'm pretty sure that is not a dependency of nix). > > I expected it to do that if I ran "nixos-rebuild switch" or > "nixos-rebuild > > boot" because I changed it locally, but I didn't expect it to compile > when > > running "nixos-rebuild dry-run". > > > > For reference, I am currently running on > > e2d06c45b4586203a1838098460ec0a5781c8cf8 (from about 3 days ago). > > > ___ > > nix-dev mailing list > > nix-dev@lists.science.uu.nl > > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Bash CVE-2014-6271
On Sun, Sep 28, 2014 at 10:19 AM, Vladimír Čunát wrote: > On 09/25/2014 03:41 PM, Ricardo M. Correia wrote: > >> Also, I'm not sure if this is expected, but when I first tried to run >> "nixos-rebuild dry-run" with this workaround applied, it started to >> download and compile bash even though the man page of nixos-rebuild >> specifically says: [...] >> > > IIRC there are two steps -- first build nix, and then do the dry-run (or > switch or anything else). Nix also needs its bash replaced, so first you > need to build the bash replacement. That is, unless you specify > --no-build-nix option. > That's what I thought too after reflecting on it a bit more, but now I'm starting to think that there is a real bug. I just tried to run "nixos-rebuild dry-run" (in preparation for testing roconner's performance improvement) and it started to compile rustcMaster! (I'm pretty sure that is not a dependency of nix). I expected it to do that if I ran "nixos-rebuild switch" or "nixos-rebuild boot" because I changed it locally, but I didn't expect it to compile when running "nixos-rebuild dry-run". For reference, I am currently running on e2d06c45b4586203a1838098460ec0a5781c8cf8 (from about 3 days ago). ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Bash CVE-2014-6271
On Wed, Sep 24, 2014 at 11:34 PM, Peter Simons wrote: > If you are worried about Bash CVE-2014-6271 (you should) and don't want > to wait for Hydra to re-build the world, then check out > > https://github.com/NixOS/nixpkgs/pull/4257#issuecomment-56727114 > > to see how to replace the bash binary in your running system without > triggering re-builds. > This does appear to work (thanks!), but I'm having some issues with it. Namely, when I run "nixos-rebuild dry-run" on my laptop, instead of taking 3 seconds to finish, now it takes more than 65 minutes (!). It seems to be CPU-bound during the whole time. Also, take into account my laptop a relatively fast CPU - a quad-core i7. My Hydra server also took around 65 minutes to evaluate the expressions of the 4 machines in my network (I believe usually it doesn't take more than a couple of minutes). In my laptop, this is the process which seems to be taking 100% CPU during the whole time: root 16031 83.6 5.8 507344 471848 pts/1 R+ 14:16 49:29 /nix/store/fxik1nhqc4dkb72wl5cgb4fxxxlcrlfz-nix-1.7/bin/nix-instantiate --add-root /tmp/nix-build.jHT5_9/derivation --indirect -A system I know this feature is just a temporary workaround, but it's also a bad user experience. From a user perspective, it seemed like the process simply got stuck in an infinite loop. In contrast, compare this to apt-get, which doesn't take more than a couple of minutes to install a security fix... Also, I'm not sure if this is expected, but when I first tried to run "nixos-rebuild dry-run" with this workaround applied, it started to download and compile bash even though the man page of nixos-rebuild specifically says: dry-run Simply show what store paths would be built or downloaded by any of the operations above. Still, thanks for this feature because even though it's slow, it's still a lot better than waiting for everything to rebuild! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Will there be a systemd replacement at any time inthefuture?
FWIW, yesterday I've also experienced loss of stderr messages in a service I was trying to debug. In this case, it might have been either because the process exited immediately afterwards or because of rate limiting, I don't know which. I've also always experienced HDD thrashing issues on machines which have large journals (although for me, the command usually completes in 30-60 seconds or so, but it's still rather slower than "tail"). Just to give some more info, I'm using ZFS as my root filesystem on most of my machines and also, for some reason, on the machines where I've been using NixOS for a longer time journalctl complains about corrupted journals when I use "journalctl --verify", even though my fully checksummed ZFS filesystems never complained about a checksum error and I never noticed corruption in any other part of the system. On Tue, Sep 2, 2014 at 2:53 PM, Michael Raskin <7c6f4...@mail.ru> wrote: > >I would like to add I absolutely love systemd, as it provides proper > >dependency management, helping immensely for more dynamic setups where > >hardware changes should trigger services reconfiguration, or for > >changing services/vpn/routing based on wifi access point and more. > >It's really nice that - when configured well - things just work, no > >matter if you're booting, restarting some service or switching to a new > >configuration. No more subtle timing errors or things that need manual > >restarts in edgy situations. Systemd's "state manager" is extremely > >capable. And extremely fast compared to oldschool linear scripts. > > Unfortunately, making SystemD _not_ do something is harder than making > it do something. It would be irrelevant if it didn't become bigger with > time, but deconfiguring new functionality is sometimes needed. > > >If we ever want to move to some other init system, I think this will > >be easier than the upstart->systemd move. That move was mostly > >complicated by the fact that upstart just didn't have most config > >settings and abstractions, so stuff for run-as-user and daemonization > >logic was put into a bash script. That had to be extracted into > > If we migrate to a new init system, we will have (for example) to > rewrite all the dependencies. > > > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Grub Install Failure when using boot.loader.devices = [ "/dev/sda" "/dev/sdb" ];
Hi Roger, Not sure if it will help, but can you try: NIXOS_INSTALL_GRUB=1 nixos-rebuild switch ? On Wed, Jul 2, 2014 at 12:59 PM, Roger Qiu wrote: > Hello everybody, > > When I run with: > > ``` > boot.loader.device = "/dev/sda" > ``` > > or > > ``` > boot.loader.device = "/dev/sdb" > ``` > > It works. > > But when I try to install Grub on both using: > > ``` > boot.loader.devices = [ "/dev/sda" "/dev/sdb" ]; > ``` > > This is basically the abridged error message: > > ``` > Path '/boot/grub' is not readable by GRUB on boot. Installation is > impossible. Aborting. /nix/store/bv..etc...install-grub.pl: installation > of GRUB on /dev/sdb failed > ``` > > Any ideas? > > Additional information: > > The sda and sdb are formatted via GPT using sgdisk. I used this command: > > ``` > sgdisk -n 1:2048:+30MB -c 1:"BIOS Boot Partition" -t 1:ef02 /dev/sda > begin=`sgdisk -f /dev/sda` > sgdisk -n 2:$begin:0 -c 2:"Data Partition" -t 2:8300 /dev/sda > ``` > > And did it for both sda and sdb. > > Thanks, > Roger > > -- > Founder of Polycademy & SnapSearch > http://polycademy.com > https://snapsearch.io > +61420925975 > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] setfacl: /var/log/journal: Operation not supported
Hi Christian,
If the problem is indeed the setfacl failure (as it appears to be), I think
you need to enable ACLs in ZFS by doing:
"zfs set acltype=posixacl ", where is the ZFS dataset/filesystem
which contains your systemd journal.
I'm not sure if the default ZFS version (0.6.2) contains the acltype
property already... if not, you may have to use a recent git version. You
can do that simply by adding "boot.zfs.useGit = true;" to your
configuration.nix.
For performance reasons it's also advisable to do "zfs set xattr=sa ".
This allows ZFS to use a more performant on-disk representation of ACLs.
However, be careful because I think (but I could be wrong) that there have
been reports of filesystem corruption using this option.
See for example this issue: https://github.com/zfsonlinux/zfs/issues/2214
If I'm not mistaken our git version of ZFS, even in the unstable NixOS
channel, does not include the fix for that yet.
I may be wrong but I think that if you're not going to be using ACLs apart
from the systemd journal, it's OK to not set "xattr=sa", as the systemd
journal's ACL will probably always be cached in memory due to constant
access, so it shouldn't be cause a large performance impact.
On Wed, Jun 4, 2014 at 2:11 PM, _1126 wrote:
> Hello all!
>
> I recently re-installed my NixOS configuration on a ZFS root. Since
> then I am unable to access systemd's journal. My user is part of the
> systemd-journal group, but the journal file aint.
>
> -rw-r- 1 root root 117440512 Jun 4 14:07 system.journal
>
> This is might be due to the the error reported in the subject:
>
> setfacl: /var/log/journal: Operation not supported
>
> The nixos/modules/system/boot/systemd.nix module tries the following
> (line 743):
>
> ${pkgs.acl}/bin/setfacl -nm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx
> /var/log/journal
>
> This apparently fails. Has anyone an idea what that is the case? Or am
> I wrong in suspecting that and the reason for the wrong permissions is
> to be found somewhere else?
>
> Greetings
> _1126 (Christian Lask)
>
>
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Unfree packages in Nixpkgs
That works, thanks!
On Sun, Apr 13, 2014 at 5:00 PM, Aristid Breitkreuz wrote:
> If you put it in your ~/.nixpkgs/config.nix instead, it should be
> picked up by nix-repl.
>
> 2014-04-13 16:58 GMT+02:00 Ricardo M. Correia :
> > Hi Marc,
> >
> > I've added it to my configuration.nix but it doesn't seem to work:
> >
> > # nix-repl ''
> > Welcome to Nix version 1.6.1. Type :? for help.
> >
> > Loading ''...
> > Added 3740 variables.
> >
> > nix-repl> pkgs.flashplayer.name
> > error: user-thrown exception: package 'flashplayer-11.2.202.350' in
> > <> has an unfree license, refusing to evaluate
> >
> >
> > I would guess that would be because nix-repl doesn't even parse
> > configuration.nix?
> >
> >
> > On Sun, Apr 13, 2014 at 4:23 PM, Marc Weber wrote:
> >>
> >> > How do I pass "allowUnfree = true" to nix-repl, so that it lets me
> >> > evaluate
> >> > unfree expressions?
> >> system:
> >>
> >> configuration.nix:
> >> nixpkgs.config.allowUnfree = true;
> >>
> >> user:
> >>
> >> ~/.nixpkgs/config.nix:
> >> { pkgs, ... } : {
> >> allowUnfree = true;
> >> }
> >>
> >> Marc Weber
> >> ___
> >> nix-dev mailing list
> >> nix-dev@lists.science.uu.nl
> >> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >
> >
> >
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Unfree packages in Nixpkgs
Hi Marc,
I've added it to my configuration.nix but it doesn't seem to work:
# nix-repl ''
Welcome to Nix version 1.6.1. Type :? for help.
Loading ''...
Added 3740 variables.
nix-repl> pkgs.flashplayer.name
error: user-thrown exception: package 'flashplayer-11.2.202.350' in
<> has an unfree license, refusing to evaluate
I would guess that would be because nix-repl doesn't even parse
configuration.nix?
On Sun, Apr 13, 2014 at 4:23 PM, Marc Weber wrote:
> > How do I pass "allowUnfree = true" to nix-repl, so that it lets me
> evaluate
> > unfree expressions?
> system:
>
> configuration.nix:
> nixpkgs.config.allowUnfree = true;
>
> user:
>
> ~/.nixpkgs/config.nix:
> { pkgs, ... } : {
> allowUnfree = true;
> }
>
> Marc Weber
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Unfree packages in Nixpkgs
Hi,
On Wed, Apr 9, 2014 at 11:43 AM, Eelco Dolstra
wrote:
> tl;dr version: The default value of the 'allowUnfree' Nixpkgs
> configuration flag
> has changed from 'true' to 'false'. This means that if your NixOS system
> configuration requires unfree packages, you need to add
>
> { nixpkgs.config.allowUnfree = true; }
>
> to your configuration.nix. If you're using Nixpkgs standalone, you need
> to add
>
> { config.allowUnfree = true; }
>
> to ~/.nixpkgs/config.nix, or pass
>
> --arg config '{ allowUnfree = true; }'
>
> on the command line. (Also, note that unfree packages don't even show up in
> 'nix-env -qa' unless you have allowUnfree enabled.)
>
How do I pass "allowUnfree = true" to nix-repl, so that it lets me evaluate
unfree expressions?
Thanks,
Ricardo
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS (from USB) hangs at boot
Hi Colin, Assuming you are using NixOS release 13.10, you can try using the latest unstable ISO to see if it works better: http://nixos.org/channels/nixos-unstable/ On Mon, Feb 3, 2014 at 1:12 PM, Colin Adams wrote: > I'm trying to install NixOS. I have the 32-bit ISO on a USB. But whether I > select default or the NixOS installer from the boot menu, it hangs when > starting up linux. The last line visible on the console is: > > [ OK ] Reached target Sound Card. > > If I try to switch to other virtual consoles, there is no response. > > What can I try? > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] pthread
One thing you can do to investigate configure failures is to inspect the "config.log" file to find out exactly which command failed and how. To inspect the "config.log" file, however, you need to need to keep the results of a failed build. You can do that by passing the "--keep-failed" flag to nixos-rebuild or nix-build, and then look into /tmp/nix-build-* to find the results. Alternatively, you could use "nix-shell" to do a build step by step, but it's slightly more involved... On Fri, Jan 31, 2014 at 2:38 PM, Marco Maggesi wrote: > Hello, > > I'm trying to update OCaml Lwt to the current stable version 2.4.3. > The configure script fails with the following message: > > > - > [...] > testing for pthread: ... unavailable > not checking for glib > > The following recquired C libraries are missing: pthread. > Please install them and retry. If they are installed in a non-standard > location > or need special flags, set the environment variables _CLFAGS and > _LIBS > accordingly and retry. > > For example, if libev is installed in /opt/local, you can type: > > export LIBEV_CLFAGS=-I/opt/local/include > export LIBEV_LIBS=-L/opt/local/lib > [...] > > - > > Assuming that this is provoked by a not-so-smart configure script I can > try to pass the explicit path to it as suggested by the error message. > However, I'm not familiar with this kind of details > Which derivation contains pthread? Is it in gcc? > > Thanks, > Marco > > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hardened NixOS
On Tue, Nov 19, 2013 at 2:12 AM, Marc Weber wrote: > > Securing nixos > I guess we all want to be secure :) > > I'd also like you to start a wiki page talking about > - what could be done > - what you want to be done > - how to verify that the goal has been achieved (if this does make > sense) > - what else could be done to have a secure system .. > - how to detect that a "secure" system was hacked (or what do you try to > protect against ?) > Ok, if nobody disagrees I will create a wiki page and do a write-up sometime this week. > > NixOS doesn't have many users, and hardened NixOS would have even less of > > them, then perhaps this is not necessary at the moment... > Maybe you should also try to tell us why some people of us would not > like to adopt your changes, eg are there obvious downsides /limitations > of the changes you propose ? > Well, regarding the RSBAC and grsecurity kernel NixOS module ideas, there should be no downsides unless the user enables them, and they would be rather self-contained, so I don't think these are controversial. They can be incrementally improved over time. However, I haven't developed these yet. Regarding actually allowing software to run under a grsec/PaX kernel, then there are additional complications. Specifically, there will be software that will not compile or run until either they are patched or some protections are selectively disabled in their binaries. These are usually programs that run JIT-compiled code (Chromium/v8, Firefox/spidermonkey, Java VMs, ...), but there are others as well. You can see a (possibly incomplete) list of affected packages here, as used by Arch Linux: https://github.com/nning/linux-pax-flags (Note that the simple.conf file has the larger list). As you can see, it's a few dozen packages. In order for these software packages to run, they need minor fixes. Normally, we just need to disable a flag in the compiled binaries or marking a stack as non-executable, so usually it's just 2-4 lines of additional Nix code for each affected package. However, this code is not enabled unless users enable this feature in their nixpkgs.config, so by default we do not change how packages are compiled, and therefore there should be no regressions for people who do not wish to use these features. I am committing myself to at least fix the packages that break on my system (currently 8 out of 251), but as people file issues I would do my best to fix others as well. The other downside is that Hydra does not currently build packages with this feature enabled, so if a user enables it, he will currently have to rebuild their entire NixOS system from source. Regarding PIE+SSP, I do not know to what extent there will be downsides, but I think Ubuntu enables it by default, so it shouldn't have too many bad consequences, as long as, again, packages are fixed to compile/run correctly... Thanks! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Hardened NixOS
Hi, I am currently working on integrating grsecurity/PaX and making various software packages work under a grsec-enabled kernel (well, the packages I use): https://github.com/NixOS/nixpkgs/pull/1187 With those patches and a couple of unpublished workarounds I have a basic XFCE desktop + Firefox/Chromium browsers working under a grsec/PaX-enabled kernel (KDE does not start up yet, though). I am now working on a patch to the gcc derivation which fixes a broken build of OpenJDK, due to gcc's precompiled headers feature not liking randomized mmap addresses. This patch alone causes my entire NixOS system to be rebuilt from source, though. Looking forward, I would like to develop a NixOS module which provides an adequate grsecurity kernel and kernel config, and later integrate features similar to the ones used in the Hardened Gentoo project, especially an improved compiler toolchain which would generate position-independent code (PIE) and stack-smashing protection (SSP), if these are not enabled already. In the future, I am also interested in developing a NixOS module for grsecurity's RSBAC system. I was wondering if anybody else is interested in having these security enhancements to NixOS, some of which would of course only be enabled optionally? What do you think would be the best approach for development? I'm thinking of a few options: * I keep developing these patches in a piecemeal fashion and keep asking for pull requests into NixOS master as I go along, as I've been trying to do * I develop them in my own private branch, which would at some point be merged into NixOS master * Someone creates a NixOS/hardened branch, and I merge patches there * Create a separate channel? Perhaps with these features enabled by default? * Or should I just develop them in my own private branch, which would never get merged? Having Hydra precompile packages with these features enabled would of course be very convenient if there is a relevant number of other interested users, since otherwise the whole NixOS system has to be built from source (because these patches will touch gcc). However, taking into account that NixOS doesn't have many users, and hardened NixOS would have even less of them, then perhaps this is not necessary at the moment... Thanks, Ricardo ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ZFS root boot
Sorry, a few corrections: On Fri, Nov 8, 2013 at 1:06 PM, Ricardo M. Correia wrote: > $ zpool set mountpoint=/ rpool > The correct command is "zfs set mountpoint=/ rpool" To install NixOS, you have to mount the root pool and /boot under /mnt. > This is what I did: > > $ zpool export rpool > $ zpool import -o altroot=/mnt rpool > You also need to run "mkdir /mnt/boot" before mounting /mnt/boot. > $ mount /dev/sda1 /mnt/boot(instead of /dev/sda1, put whatever > partition you used for /boot). > Cheers, Ricardo ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ZFS root boot
Hi Danny,
I use a ZFS root pool with a btrfs /boot partition. I may not have done
everything correctly, but it seems to work for me, although my ZFS pool
only has 1 disk drive.
This is what I did:
When installing NixOS, after booting the CD, I added this to the
configuration.nix of the install cd:
boot.supportedFilesystems = [ "btrfs" "zfs" ];
Then I ran "nixos-rebuild switch". This will automatically install the ZFS
and btrfs tools, as well as compile the ZFS kernel modules.
Obviously you don't need to add btrfs if you just use ext4 as the /boot
filesystem.
Then I ran "modprobe zfs" to load the ZFS kernel modules.
After that, I created the partitions, the btrfs filesystem and the ZFS root
pool. I also did:
$ zpool set mountpoint=/ rpool
... to make sure the root filesystem of the pool will get mounted on /.
This will generate an error as it will also try to mount the filesystem on
/ at the exact moment you run that command, but you can ignore it.
To install NixOS, you have to mount the root pool and /boot under /mnt.
This is what I did:
$ zpool export rpool
$ zpool import -o altroot=/mnt rpool
$ mount /dev/sda1 /mnt/boot(instead of /dev/sda1, put whatever
partition you used for /boot).
Finally, to install:
$ nixos-generate-config --root /mnt
After that, I had to edit /mnt/etc/nixos/hardware-configuration.nix and
delete all autodetected ZFS filesystems except for the root filesystem
("/").
It seems that if you don't do this, NixOS will try to mount them on boot
but fail because ZFS had already automatically mounted these filesystems by
itself.
Next, I edited /mnt/etc/nixos/configuration.nix and added:
boot.supportedFilesystems = [ "btrfs" "zfs" ];
... as well as changing boot.loader.grub.device as the manual says, of
course.
That's all I had to do. I still get some warnings/errors mounting
filesystems when booting NixOS, but it seems to be working fine.
By the way, my ZFS root pool is also encrypted and this was very easy to do
as well and seems to work fine.
All I had to do was run cryptsetup to format and mount the luks device just
before creating the pool (see the Arch wiki instructions as a guide for
cryptsetup).
And finally, I just added this to /mnt/etc/nixos/configuration.nix:
boot.initrd.luks.devices = [ { device = "/dev/sda2"; name = "root"; } ];
And that was all... Although I guess if you have multiple drives, you would
have to add multiple luks devices and consequently you would have to enter
your password once for each drive/partition, which could be annoying... I
don't know if there is a better way to do it, though.
I hope that helps.
- Ricardo
On Fri, Nov 8, 2013 at 8:44 AM, deCube.net | Danny Wilson
wrote:
> Hi list,
>
> I have a machine with 5 disks in a ZFS raidz1 zpool. It would be great if
> I could boot from this.
>
> I tried running the nixos installer by following the instructions in the
> documentation, but grub couldn’t read /boot (probably because of raidz1)
> Next I tried giving every disk a small boot partition and creating raidz1
> out of the remaining space.
>
> This boots, but doesn’t get past Stage 1, busybox can’t mount /
>
>
> Does anyone have nixos configuration examples of a ZFS root boot? :-) I
> googled my ass off.
>
>
> Cheers
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fwd: Hardened Linux kernel with grsec/PaX + AppArmor
I am interested in grsecurity mostly because of the many generic improvements that you mentioned. The reason I'm using Apparmor for process confinement is that NixOS supports it already. In the near future I would like to use grsec's RBAC system instead of Apparmor, as it seems just as simple but more secure. But since Apparmor already worked and the grsecurity kernel patch includes the apparmor patches, I did not feel the urgency to replace Apparmor with RBAC right now. Thanks, Ricardo On Aug 7, 2013 3:54 PM, "Mathijs Kwik" wrote: Hi Ricardo, It has been some time I've looked into these security-hardening systems, but I was under the impression that grsecurity, selinux and apparmor were somewhat competative solutions for the same problems. I know there are some differences (path-based vs inode based) and that grsecurity provides a bunch of generic improvements (process hiding for example) too. However, I've never heard of combining grsec with apparmor. Why would one do that? On Wed, Aug 7, 2013 at 2:59 PM, Ricardo M. Correia wrote: > Hi, > > I'm attaching a simple patch that allows you to use a kernel with > grsecurity, PaX and AppArmor enabled, just in case it's useful to anyone. > > It requires the following changes to be applied first: > https://github.com/NixOS/nixpkgs/pull/802 > > I am not sending a pull request for this new kernel directly because it > needs further work to allow customization of the grsec kernel config options > from /etc/nixos/configuration.nix and I don't have time to investigate how > to do that right now. > > In particular, you need to specify whether the machine is a server or a > desktop; whether it's running as a VM guest, host or simply on bare metal; > whether hardware or software virtualization is being used and whether you > prefer more security or more performance. > > You can accomplish that by changing the GRKERNSEC_CONFIG_* options which you > can see in the patch (I enabled the ones I personally use). > > You can find a reference for these options here: > https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Configuration_Method > > In order to use the new kernel and features, you also need to add > "boot.kernelPackages = pkgs.linuxPackages_3_2_hardened;" and > "security.apparmor.enable = true;" to your configuration. > > You may also need to create AppArmor profiles for the programs you are > interested in confining. > > If you are doing chroot builds and running the new kernel, package > installation may fail due to "chmod +s" protection (apparently it can be > used to break out of the chroot). > > As a quick workaround, you can disable this protection temporarily during > package installation: > # sysctl -w kernel.grsecurity.chroot_deny_chmod=0 > You should probably re-enable it afterwards. I'm sure there are better ways > to do this, though. > > To make sure the kernel has been properly installed and is running, I > suggest running "dmesg" as a normal user: it should fail with "operation not > permitted". > > I hope this is useful to someone. > > PS: you can re-enable the following kernel config options, but you will lose > the corresponding security features: > > Xen support -> disables "Prevent invalid userland pointer dereference" > (MEMORY_UDEREF) > Hibernation -> disables "Sanitize all freed memory" (MEMORY_SANITIZE) > > Thanks, > Ricardo > > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: Hardened Linux kernel with grsec/PaX + AppArmor
Hi, I'm attaching a simple patch that allows you to use a kernel with grsecurity, PaX and AppArmor enabled, just in case it's useful to anyone. It requires the following changes to be applied first: https://github.com/NixOS/nixpkgs/pull/802 I am not sending a pull request for this new kernel directly because it needs further work to allow customization of the grsec kernel config options from /etc/nixos/configuration.nix and I don't have time to investigate how to do that right now. In particular, you need to specify whether the machine is a server or a desktop; whether it's running as a VM guest, host or simply on bare metal; whether hardware or software virtualization is being used and whether you prefer more security or more performance. You can accomplish that by changing the GRKERNSEC_CONFIG_* options which you can see in the patch (I enabled the ones I personally use). You can find a reference for these options here: https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Configuration_Method In order to use the new kernel and features, you also need to add "boot.kernelPackages = pkgs.linuxPackages_3_2_hardened;" and "security.apparmor.enable = true;" to your configuration. You may also need to create AppArmor profiles for the programs you are interested in confining. If you are doing chroot builds and running the new kernel, package installation may fail due to "chmod +s" protection (apparently it can be used to break out of the chroot). As a quick workaround, you can disable this protection temporarily during package installation: # sysctl -w kernel.grsecurity.chroot_deny_chmod=0 You should probably re-enable it afterwards. I'm sure there are better ways to do this, though. To make sure the kernel has been properly installed and is running, I suggest running "dmesg" as a normal user: it should fail with "operation not permitted". I hope this is useful to someone. PS: you can re-enable the following kernel config options, but you will lose the corresponding security features: Xen support -> disables "Prevent invalid userland pointer dereference" (MEMORY_UDEREF) Hibernation -> disables "Sanitize all freed memory" (MEMORY_SANITIZE) Thanks, Ricardo grsec.patch Description: Binary data ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
