2020-05-31

<clever> if the default.nix your loading is nixpkgs, yeah
<clever> then it will want aarch64, but find it doesnt match the host, so it will look for a builder
<clever> you want to instead set the system arg of nixpkgs to that, `import <nixpkgs> { system = "aarch64-linux"; }` and leave the --option alone
<clever> so it trusts you, and tries to run aarch64 binaries
<clever> angerman: --option system aarch64-linux tells nix that your current cpu is aarch64
<clever> angerman: that would be your problem then
<clever> angerman: are you using `--optino system` ?

2020-05-30

<clever> iqubic: /bin/bash doesnt exist, you can usually get away with /bin/sh
<clever> cmcaine[m]: that will let you easily patch things without nix-shell
<clever> cmcaine[m]: https://gist.github.com/cleverca22/8cae5bc9c02c12099a3bf5e20e75161f run `nix-build simple-test.nix` then you can just `./result thing-to-patch`
<clever> jlv[m]: that file always has the right path for the stdenv your in (via nix-shell -p patchelf)
<clever> $ cat $NIX_CC/nix-support/dynamic-linker
<clever> /nix/store/qb6k4hp7gk331x9fydw0w7qj4dv09bwz-glibc-2.27/lib/ld-linux-x86-64.so.2
<clever> jlv[m]: you want to use $NIX_CC and nix-support, /lib/ld-linux-x86-64.so.2 will only work for 64bit x86
<clever> nix-copy-closure
<clever> most stuff in /etc/ is text based, and an empty file is just 0 lines
<clever> what happens if you simply create it with `touch` ?
<clever> does printcap exist?
<clever> blame MS for rolling file-sharing and printer-sharing into a single protocol
<clever> elvishjerricco: samba includes the windows printer sharing logic i believe
<clever> if its a multi-user system, then you are limited to your own nix-env generations
<clever> ashkitten: ^
<clever> jluttine[m]: system profiles are in this directory, so only root can delete its generations
<clever> drwxr-xr-x 4 root root 44 May 23 12:30 /nix/var/nix/profiles/
<clever> jluttine[m]: nix-collect-garbage -d can only delete generations from profiles it has write access to

2020-05-29

<clever> euank: yeah, that would also work
<clever> cole-h: -arg overlays '[ (self: super: { ... }) ]'
<clever> cole-h: --arg needs a valid expr, in this case, a list of 2 layers of functions returning a set
<clever> mica[m]: nixpkgs.overlays = [ (self: super: { foo = (import /home/clever/nixpkgs {}).foo; }) ];
<clever> mica[m]: you can
<clever> mica[m]: you can use builtins.fetchTarball against a git revision, or just import your own clone of nixpkgs on-disk
<clever> cole-h: faster and fewer typos!, you beat me!
<clever> ,unstable MichaelRaskin
<clever> MichaelRaskin: if you can be sure of that, yeah
<clever> MichaelRaskin: if you expose the root disk to a guest, you run the risk of data corruption
<clever> cinimod: that should also be in $PATH, so you can just `julia`
<clever> bqv: stdenv.mkDerivation { foo = [ "1" "2" "3" ]; } will toString for you
<clever> bqv: also, you dont even need toString in some cases
<clever> cinimod: and what do you then want to do with that path?
<clever> cinimod: `echo $buildInputs` ?
<clever> omnipotententity: probably
<clever> cinimod: that is a list with 3 elements, a function, path, and set
<clever> cinimod: use () around the callPackage
<clever> omnipotententity: it will use spaces to seperate each element
<clever> > "${toString [ "1" "2" "3" ]}"
<clever> omnipotententity: if the string wont contain spaces, you can just do `export FOO=${toString foo}`
<clever> ldlework: `nix repl --show-trace` and it will
<clever> kalbasit: you would need to do `lib = super.lib // { mkOption = ..; };`
<clever> which replaces the entire lib
<clever> kalbasit: lib.mkOption = is identical to lib = { mkOption = ...; };
<clever> kalbasit: that overlay replaced ALL of pkgs.lib, with just { mkOption = ...; }
<clever> raghavsood: sounds like you could have also fixed it by somehow telling the bios to just boot from the nvme
<clever> iqubic: hardware.pulseaudio.extraConfig
<clever> iqubic: yeah
<clever> raghavsood: for an SSD, blkdiscard will also give a boost to write performance, until youve written the whole disk once
<clever> raghavsood: that basically tells the disk controller to assume all blocks are wiped
<clever> raghavsood: a faster way to do that is the blkdiscard cmd
<clever> raghavsood: so the nvme grub takes over
<clever> raghavsood: you may need to zero the MBR of sda/sdb, to remove grub from it
<clever> raghavsood: yeah, somethings wrong there, is sda GPT or MBR?
<clever> raghavsood: try running the bootinfo script, from the debian liveimage
<clever> raghavsood: are you able to boot it into a rescue console?
<clever> raghavsood: what does the script report, after you install nixos onto one of the failing machines?
<clever> as for the nvme machine, you have 2 nvme devices, each with an ext4 boot and a zfs vdev, and the bootinfo script doesnt think legacy would work, so its not looking for it
<clever> about all it does, is make the boot order in the bios not matter
<clever> raghavsood: so sdb isnt giving you very much redundancy
<clever> raghavsood: sda is configured to find an fs with a given uuid (or default to sda1) and then read /grub from that, sdb is configured to just blindly read sda sector 1, which does the previous
<clever> and pastebin the results
<clever> raghavsood: can you run this on one of the working machines?
<clever> and the /boot cant be on nvme either in that case
<clever> raghavsood: nvme will rarely be able to boot via BIOS means
<clever> raghavsood: which block devices did you set it to?
<clever> raghavsood: what is boot.loader.grub.devices set to?
<clever> it ignores .package in several spots
<clever> yeah, its a bug that its mising cfg.package and pkgs.fprintd
<clever> xwz91: i had a typo in my example!
<clever> xwz91: that says fprintf, it should be fprintd
<clever> xwz91: can you pastebin the nixpkgs. area of the config file?
<clever> xwz91: it goes near the nixpkgs.config you already have
<clever> xwz91: that will mutate pkgs.fprintf as well, and you dont need it in systemPackages at all
<clever> xwz91: you need to add `nixpkgs.overlays = [ (self: super: { fprintf = pkgsUnstable.fprintd; }) ];
<clever> xwz91: it will use fprintd.package for the udev rules, but pkg.fprintd for the systemPackages
<clever> xwz91: aha, its a bug in the fprintf module
<clever> xwz91: i would expect that to all work, what does `nixos-rebuild switch` output?
<clever> xwz91: can you pastebin the whole configuration.nix file?
<clever> xwz91: do you have fprintd in systemPackages multiple times?
<clever> xwz91: how did you check the version?
<clever> adit[m]: it will still obey the overlays in configuration.nix
<clever> adit[m]: nix-build '<nixpkgs/nixos>' -I nixos-config=configuration.nix -A system, oops, missed that bit
<clever> adit[m]: nix-build '<nixpkgs/nixos>' -I nixos-config=configuration.nix
<clever> yep
<clever> xwz91: either works
<clever> xwz91: yeah
<clever> xwz91: put `let key=value; in` before the { that was on line 10 last time i saw the cfg
<clever> ,unstable xwz91
<clever> hpfr[m]: ^^
<clever> > builtins.listToAttrs (map (key: { name = key; value = "val"; }) [ "a" "b" ])

2020-05-28

<clever> xwza91: you can combine them together, and also use newlines to make it simpler to read
<clever> ,unstable
<clever> xwza91: you didnt use disabledModules to disable the old module
<clever> xwza91: imports goes after line 10, not before
<clever> xwza91: imports = [ <nixos-unstable/nixos/modules/tasks/encrypted-devices.nix> ];
<clever> xwza91: so you want <nixos-unstable/nixos/modules/tasks/encrypted-devices.nix> in your imports list
<clever> xwza91: its not a package, its a nixos module
<clever> xwza91: then you should be able to just `import <nixos-unstable> {}`
<clever> xwza91: you would just do <nixos-unstable> if `nix-channel --list` shows the name as nixos-unstable
<clever> xwza91: yep
<clever> xwza91: look up disableModules in the nixos manual
<clever> xwza91: that sounds like a bug in nixpkgs then
<clever> njha: make sure you dont lock yourself out though!
<clever> njha: https://nixos.org/nixos/options.html#services.openssh.open there is also an option to turn that off
<clever> njha: i disable password auth at least
<clever> njha: enabling ssh opens port 22 automatically
<clever> xwza91: on my older nixpkgs, its being defined with map, which returns a list, what about on your machine?
<clever> 67 devices =
<clever> 68 map (dev: { name = dev.encrypted.label; device = dev.encrypted.blkDev; } ) keylessEncDevs;
<clever> hexagoxel: CI will lack secrets, and only test if the code compiles, but locally, secrets.nix does exist
<clever> hexagoxel: i have basically the identical code in here
<clever> infinisil: out of order execution?
<clever> infinisil: but the `> true` didnt lag
<clever> eyJhb: with this package, $out is the default, but the binaries are in $bin
<clever> > "${tpm2-pkcs11.bin}"
<clever> infinisil: ?
<clever> > "${tpm2-pkcs11}"
<clever> > true
<clever> > "${tpm2-pkcs11.bin}"
<clever> > "${tpm2-pkcs11}"
<clever> > "${tpm2-pkcs11.outputs}"
<clever> > tpm2-pkcs11.outputs
<clever> eyJhb: xrandr isnt split output, so the 2 are identical in that case
<clever> > xorg.xrandr.outputs
<clever> eyJhb: if a package has a .bin, then the bin dir wont be in the default output
<clever> asbachb: you want disabledModules from the nixos manual
<clever> i tend to use a local hydra for that job
<clever> not sure how to do that
<clever> LnL: it would be a result pointing to the $out, not the .drv file
<clever> LnL: i typically use `nix-store -r $foo --add-root result --indirect`, but the `-r` will try to build a drv first
<clever> kalbasit: that should also work fine
<clever> kalbasit: id just do it by hand, postPatch = "mv a b"
<clever> kalbasit: the patch is just renaming a file, the normalization process might drop that
<clever> bqv: you want NIX_REMOTE=local to disable it
<clever> bqv: try without NIX_REMOTE, that might be what broke it
<clever> alexherbo2: you need to add a `name = "somethingwithoutspaces";` to the fetchurl
<clever> try using a normal nix?
<clever> bqv: i would expect that to work
<clever> bqv: which version of nixpkgs are you using?
<clever> bqv: what if you run `nix path-info` on that bash?
<clever> bqv: where does that path appear in the derivation, `nix show-derivation /nix/store/foo.drv` ?
<clever> bqv: can you pastebin more of the build log?
<clever> bqv: which expression are you trying to build?
<clever> bqv: that looks like a sandboxing issue
<clever> bqv: yep
<clever> nix#3628
<clever> > pkgs.path
<clever> betawaffle: it lets you add custom args to every module, in the same place { config, pkgs, lib, ... }: happens
<clever> energizer: i believe mobile-nixos is already able to do that as well
<clever> mmchen: is the lsp server running under nix-shell?
<clever> ,libraries mmchen

2020-05-27

<clever> bqv: only if you use self.passthru
<clever> > "${hello}"
<clever> bqv: the derivation itself is $out
<clever> bqv: why are you trying to get $out from passthru?
<clever> bqv: runCommand has its own $out
<clever> cole-h: nope
<clever> wchresta: but you could also just `makeWrapper ${a}/bin/foo $out/bin/foo`
<clever> wchresta: so basically, `wrapProgram foo` will rename foo -> .foo-wrapped, then runs `makeWrapper .foo-wrapped foo`
<clever> wchresta: makeWrapper takes a thing to run, and a thing to output to, while wrapProgram takes a single param, renames it, then runs makeWrapper on the renamed + original
<clever> wchresta: pkgs.runCommand with makeWrapper should do
<clever> jtojnar: not sure, usually you just <nixpkgs/nixos/something>
<clever> jtojnar: imports cant depend on the pkgs passed into a module
<clever> cole-h: you may need to add it to boot.supportedFilesystems first
<clever> cole-h: i think it was `mount -t ntfs3g` maybe?
<clever> cole-h: you might be using the read-only ntfs implementation
<clever> cole-h: where did `backup` come from?
<clever> cole-h: what does `lvdisplay -C` report?
<clever> keithy[m]: you can just `nix-shell -p coreutils`, even on a mac
<clever> ,locate bin/realpath
<clever> __red__: cat /etc/systemd/system/foo.service
<clever> balsoft: ahh
<clever> balsoft: the user is within the config file, so i expect the service to do its own root-drop
<clever> not sure
<clever> __red__: while the home = libDir; tells nixos to make it as the home of a user
<clever> __red__: StateDirectory tells systemd to dynamically create its own dir with the right privs
<clever> __red__: i would expect it to be owned by bacula
<clever> angle?
<clever> balsoft: ah, hadnt looked at that attack angel
<clever> iclanzan: nix-serve doesnt allow you to list things, so the attacker would need to know the hash of a storepath to download it
<clever> iclanzan: its only a risk if you tell others what the path to one of the secrets is, or something depending on the secret
<clever> benny: the timestamp of the symlinks in /nix/var/nix/profiles/
<clever> iclanzan: it has to be setup in the /etc/nix/nix.conf file
<clever> iclanzan: and nix will just fetch the deps automatically
<clever> iclanzan: all binaries made by nix, use libraries in /nix/store, even on darwin
<clever> iclanzan: yes
<clever> iclanzan: if the cache is configured, it pulls a pre-built copy, if the cache isnt configured, nix builds whats missing
<clever> iclanzan: and they can still just run nix-shell
<clever> iclanzan: there is no difference between linux and nixos builds
<clever> iclanzan: you compile on each platform, then push to the cache server
<clever> iclanzan: run your own cache? or use cachix?
<clever> iclanzan: not really
<clever> chloekek_: that is exactly what haskellPackages.callCabal2nix does
<clever> -p takes 0 or more packages, which get added to the buildInputs
<clever> `-p` isnt `--pure`
<clever> `nix-shell -p` should give you make, its part of the stdenv
<clever> keithy[m]: installing anything that isnt compiler related
<clever> `nix-shell -p` then `make`
<clever> keithy[m]: run make in nix-shell ?
<clever> keithy[m]: what kind of use?
<clever> keithy[m]: you should generally not install any compiler type tools, only ever use nix-shell
<clever> ive never had such issues with zfs though
<clever> yeah
<clever> or a random .drv file is nulls, so nix cant build anything touching it
<clever> and now the manifest.nix for nix-env is toast, so they cant install anything
<clever> other nix users, that did an improper reboot immediately after a nix build
<clever> but that issue has never been on my own machines
<clever> ah, that would solve the issue ive seen before
<clever> so nix would have to open every file in $out and fsync() each one...
<clever> elvishjerricco: then nix read $out, hashed it, and recorded its presense in db.sqlite
<clever> elvishjerricco: one case i can see, where nix isnt entirely at fault, is if you just built something, and the binary in the derivation didnt fsync()
<clever> elvishjerricco: but ext4 is sometimes doing naughty things, and data can still be lost after that point
<clever> elvishjerricco: my rough understanding, is that when you close() a file, the fs driver is supposed to flush everything to disk, and not return until its commited
<clever> abathur: and run ended with: Illegal instruction (core dumped)
<clever> prepare ended with: 2147483648 bytes written in 47.78 seconds (42.86 MiB/sec).
<clever> abathur: the main storage is a raidz1 over 3 mechanical drives
<clever> abathur: the nas has an optane that i sometimes use as an SLOG or L2ARC, but its currently inactive
<clever> Henson: maybe i'm just spoiled by having nvme on everything else, and the spinning rust is just always that slow, lol
<clever> abathur: found the box for the optane module, it doesnt say much, lol
<clever> Henson: how do the above numbers look?
<clever> but ARC hit% was never below 99.5%
<clever> Henson: putting a 2gig file into /dev/shm, also caused the ARC to drop from 6.8gig to 4.79gig
<clever> Henson: somehow, its worse then when going over nfs, lol
<clever> Henson: and thats the performance to write the whole 2gig file back to zfs
<clever> 2147483648 bytes (2.1 GB, 2.0 GiB) copied, 29.6706 s, 72.4 MB/s
<clever> Henson: just creating the random sample, ran at that rate, but thats primarily a cpu/ram test...
<clever> 2147483648 bytes (2.1 GB, 2.0 GiB) copied, 14.3825 s, 149 MB/s
<clever> [root@nas:/dev/shm]# time dd if=/dev/urandom of=blob bs=1024 count=$((1024*1024*2))
<clever> i'll try someting within the nas now...
<clever> for ~80mb/sec
<clever> Henson: 52 seconds for that 4.1gig to copy
<clever> DigitalKiwi: dedup is now off, so any further writes arent dedup'd
<clever> Henson: i usually have both `iostat -x 30` and `zpool iostat -v 30` open at all times
<clever> copying 4.1gig over nfs now...
<clever> but thats obviously not pushing it very hard
<clever> ~83mb/sec
<clever> Henson: copying a 703mb file from a single-disk xfs, over nfs, and writing to the raidz1, took 8.4 seconds
<clever> DigitalKiwi: nope, just sync=standard for most, and sync=disabled for one
<clever> Henson: 3 of those, in raidz1
<clever> User Capacity: 4,000,787,030,016 bytes [4.00 TB]
<clever> Model Family: Western Digital Red
<clever> Device Model: WDC WD40EFRX-68N32N0
<clever> abathur: let me see if i can find more, lol
<clever> abathur: 01:00.0 Non-Volatile memory controller: Intel Corporation Device 2522
<clever> vendor: ASRock
<clever> product: FM2A88X-ITX+
<clever> 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 40)
<clever> Henson: the performance problems are almost entirely in the write and delete paths, rarely in the read path
<clever> and 40% of that 3%, was found in the L2
<clever> so only ~3% missed the ram ARC, and had to go out to other places
<clever> Henson: but thats only counting what missed the ARC in ram, which was at 3gig, and getting >97% hit rate
<clever> intel optane
<clever> Henson: from april 3rd to 15th, my L2ARC was covering at around 6gig used, and getting around a 40% hit rate
<clever> naspool 10.9T 10.4T 527G - - 64% 95% 1.06x ONLINE -
<clever> NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
<clever> Henson: it may not help, that my pool is at 95% capacity and 64% frag
<clever> but zfs cant repack the hash tables, so the size hasnt changed
<clever> the number of entries is going down, ive been keeping some records
<clever> had
<clever> and that
<clever> dedup: DDT entries 5631543, size 1.31K on disk, 324B in core
<clever> seems fine today
<clever> one more dataset with a high churn, 3 seconds to delete 1.38gig
<clever> *doh*, i didnt include `time`, lol
<clever> `zpool get freeing` now reports 1.7gig, and then 0
<clever> will reclaim 1.73G
<clever> [root@nas:~]# zfs destroy -v naspool/root@zfs-auto-snap_daily-2020-05-20-00h00%zfs-auto-snap_hourly-2020-05-26-17h00
<clever> and that command took 8 seconds to complete
<clever> Henson: as a test, `time zfs destroy -v naspool/root@zfs-auto-snap_weekly-2020-05-18-00h00`, this snapshot is the final root for 412mb of data
<clever> Henson: and nix-collect-garbage once ran for over 8 hours recently
<clever> Henson: basic things like `zfs destroy` on a snapshot can take over 5 mins sometimes
<clever> Henson: the laptop is nvme single-disk, and theres no real issues with it
<clever> Henson: the nas with 3 disks in raidz1, seems to perform poorly, but its all spinning rust
<clever> Henson: performance for zfs, seems to vary wildly from machine to machine
<clever> when it was otherwise idle
<clever> Henson: for example, my nas had the arc shrink by almost a gig, for no aparent reason
<clever> Henson: any kind of load, and it tends to discard the entire ARC
<clever> Henson: ive not had any issues like that, and ive found the reverse is the problem
<clever> Henson: thats basically what line 65 does: wipefs -a ${cfg.rootDevice}
<clever> Henson: :D
<clever> Henson: i was thinking more along the lines of https://www.youtube.com/watch?v=oe-2slh4njQ
<clever> and it will immediately format, and install nixos, with zero confirmations
<clever> after you kexec, you just ssh in, and run `justdoit`
<clever> yep