2017-10-04

<clever> xd1le: you can also enable swap and resize /nix/.rw-store/, if you have the disk space for it
<clever> yeah, that would explain it
<clever> doing a garbage collection and installing something thinner should help
<clever> it sounds like a bug in nixos-install, building things on the wrong store
<clever> oops, yeah, that one
<clever> xd1le: has nixos-install been ran at any point?
<clever> xd1le: have you ran nixos-rebuild?, and what args did you give to nixos-install?
<clever> xd1le: ah, i think the problem is in /nix/.rw-store, but nixos-install should have chroot'd
<clever> xd1le: what about the df -i output?
<clever> xd1le: can you gist the full error and df output?
<clever> zfs also has checksums on everything, so corruption wont get to the userland apps
<clever> zfs journals both the data and metadata, so the files cant get out of sync like that
<clever> and it wont repair them automatically
<clever> even if they boot an old generation, nix will get upset that files in the store are corrupt
<clever> hyper_webirc: i have seen a few new users improperly shutdown nixos after a nixos-rebuild, and it truncated various files in /nix/store/
<clever> yeah, i just always ext4 it
<clever> MoreTea: there is also a copyKernels option, that forces nixos to copy the kernel, within the same dataset
<clever> and if /boot is on the same filesystem as /nix/store, nixos will just use symlinks by default
<clever> grub has trouble traversing really large directories like /nix/store/
<clever> correct
<clever> xd1le: it must not be a partition
<clever> xd1le: i would still set boot.loader.grub.device
<clever> hyper_ch: how is typing the above "so much work" ?
<clever> "man configuration.nix\n/hostId\n"
<clever> read the configuration.nix man page
<clever> the docs for the hostid tell you
<clever> yeah
<clever> hyper_ch: grub has trouble reading zfs, so its best to have a seperate partition for boot
<clever> aw: then you can always recover it via spi as well
<clever> aw: i would want to backup the bios via spi first
<clever> and it runs sshd on bootup
<clever> even remotely
<clever> with this, you can forcibly run nixos from a ramdisk, hijacking any linux system
<clever> aw: if you can get any linux kernel to boot, you could try my kexec trick, but it may not like the uefi then
<clever> i havent investigated how it has changed since then
<clever> then write the size, and raw contents to a /sys entry
<clever> udev would then check the fs, give a positive or negative reply by writing to a /sys entry
<clever> when i had done it, the kernel ran a special hook program, and passed it an env variable saying what file it wanted
<clever> and was able to get an ip, and download the rootfs over wifi
<clever> i put my wifi drivers, and firmware into the initrd, then rewrote udev's firmware loader in bash
<clever> some of the insanity ive done with initrd's in the past
<clever> aw: yep
<clever> the default for cpio (only ever used by the kernel) is not supported by the kernel!
<clever> aw: oh yeah, that also tripped me up when building them by hand on gentoo
<clever> fearlessKim[m]: or for tests, initialPassword = "hunter2";
<clever> fearlessKim[m]: i always set users.users.foo.initialHashedpassword
<clever> aw: its a bit odd that your main initrd isnt compressed
<clever> [root@amd-nixos:~]# file -L /run/current-system/initrd
<clever> /run/current-system/initrd: gzip compressed data, max compression, from Unix
<clever> fearlessKim[m]: yeah, that varies between terminals, i try to play it on the same side and add a space or omit it
<clever> aw: what does "file" say about the 2nd initrd?, and the 1st?
<clever> zero initrd's*
<clever> aw: that would imply it got zero rootfs's, and proceded directly to mounting the rootfs without the aid of an initrd
<clever> aw: then try to confirm what files are present after the kernel unpacks everything
<clever> aw: to start with, add boot.allow_shell to the kernel args, and get a shell after it fails
<clever> aw: i have made multiple initrd's work fine with ipxe before
<clever> sphalerite: another machine, has twinkling stars in the background image
<clever> sphalerite: the bios on one of my machines can even save screenshots to usb
<clever> hyper_ch: until you get to the root of a dataset, and add an entry to the ringbuffer
<clever> hyper_ch: my understanding, is that when you write to any file, it also has to modify every directory above it in the tree, because the directories are also immutable
<clever> hyper_ch: and at the root level, there is a ring-buffer, pointing to the immutable root directory
<clever> hyper_ch: yeah, i believe thats how it works
<clever> you need to either use the expression generated by cabal2nix, or use ghcWithPackages
<clever> yeah
<clever> yeah
<clever> yeah
<clever> oops, no ; at the end
<clever> iqubic: (pkgs.haskell.lib.overrideCabal pkgs.haskellPackages.glirc (drv: { doCheck = false; }));
<clever> iqubic: just insert this into systemPackages
<clever> this is one way to just disable the testing
<clever> [clever@amd-nixos:~]$ nix-build -E 'with import <nixpkgs> {}; haskell.lib.overrideCabal haskellPackages.glirc (drv: { doCheck = false; })'
<clever> iqubic: he never pushed the fix to hackage, as far as i can tell
<clever> curl: (22) The requested URL returned error: 404 Not Found
<clever> 2.23 is what fails to build
<clever> error: build of ‘/nix/store/gpf59kr5ib59adlpwidl0zlcgsvm7apd-glirc-2.23.drv’ failed
<clever> the commit i linked is tagged as 2.24
<clever> the tests are broken
<clever> test/Main.hs:14:1: error: Failed to load interface for ‘Client.Commands.Arguments’
<clever> Perhaps you meant Client.Commands.Arguments.Spec (from glirc-2.23)
<clever> nix-env -iA nixos.haskellPackages.glirc
<clever> then you need to use ghcWithPackages
<clever> iqubic: do you want to just run binaries within it, or compile code that links against it?
<clever> iqubic: are you using ghcWithPackages?
<clever> iqubic: they work fine together for me
<clever> wasnt sure which one had died
<clever> there is node2nix and npm2nix
<clever> pmade: you must use things like fetchurl to download the files before the build has begun, then copy them into the right spots
<clever> pmade: the network is unavailable during the entire build

2017-10-03

<clever> or*
<clever> oh haskellConcealPlus
<clever> chessai: i think you want to add haskellConceal to the list, rather then github:enomsg/vim-haskellConcealPlus
<clever> catern: you will need to duplicate this expression (because its inside the tar creator), and then just rsync the closure of that bash script
<clever> catern: the "compiled" copy of install-nix-from-closure.sh is what does most of the setup, after the tar has been unpacked
<clever> one min
<clever> you can just rsync the store over, instead of untar
<clever> thats fairly close to what the curl installer does
<clever> yeah
<clever> but that copy might be out of date
<clever> catern: it would need to interogate the target, then copy binaries over with scp
<clever> chessai: inspecting in nix-repl, i see a vimPlugins.haskellConceal
<clever> chessai: i think it loads all the plugin names into vim, and then runs a ExportPluginsForNix function
<clever> chessai: yeah, i would have expected that to work at a glance as well
<clever> catern: thats pretty much all nix-copy-closure does, it packs each storepath into a NAR, and streams it over ssh, where a remote nix unpacks it
<clever> cement: then you can put pathogen config into the string near 24, the same as vundle
<clever> cement: and pathogen is a supported plugin, just add it on ;ome 20
<clever> cement: that file goes into the imports list
<clever> which means you want to run this even after a fresh install
<clever> catern: nix-env -i /nix/store/hash-nix/
<clever> catern: then you would want to realize a specific nix from the cache
<clever> catern: and to make it extra idempotent, always update the channel and nix-env after an install
<clever> catern: yeah, you would need to check for the existance of nix-env, then either nix-chanenl --update && nix-env -iA nixpkgs.nix or install
<clever> ah
<clever> catern: ansible cant just run a bash script?
<clever> and at that point, why doesnt the admin just finish the install for you?
<clever> such an automatic install would only work if the admin had already given you ownership of /nix
<clever> so you own an empty /nix dir?
<clever> catern: which requires either sudo perms or ownership of /nix/
<clever> catern: the most i can think of, is to detect the failure of nix-store --serve, and then run the install script over ssh automatically
<clever> yeah, thats just an issue with PATH
<clever> catern: but you could just include nix in there as well, and have a script to setup the profiles
<clever> catern: in my case, it lacks nix, and there is no management for that /nix/store/
<clever> catern: this creates a tarball containing the full closure of a bash script (which includes kexec tools, the linux kernel, and an initrd)
<clever> catern: you could make your own tarball, ive done something similar in my kexec tool
<clever> catern: which is what https://nixos.org/nix/install does
<clever> catern: you need a tarball that contains the full /nix/store/ that can just be unpacked to /nix/ and used
<clever> infinisil: when i was new to linux, i spent hours just reading every man page i could find :P
<clever> did you loadkeys first?
<clever> for legacy, you must "mount -t zfs pool/name /foo"
<clever> ah
<clever> what do the zfs and zpool man pages say about load-keys?
<clever> hyper_ch: luks or zfs encryption?
<clever> run blkid on the partition
<clever> hyper_ch: you have to run zpool import on the pool name
<clever> given*
<clever> M1k3y: click on the hydra job for a give channel
<clever> M1k3y: the latest version of master to pass a range of testing
<clever> that will apply an override to the mlocate put into the module
<clever> Judson: try instead doing locate.location = lib.hiPrio pkgs.mlocate;
<clever> Judson: one sec
<clever> Judson: ah, then the ordering in systemPackages isnt quiet right
<clever> Judson: and the order of the items in systemPackages is the main control
<clever> Judson: for system-path, such a collision is just a warning and you can just ignore it
<clever> Judson: there is no way to override this list
<clever> Judson: and have you seen this? https://nixos.org/nixos/options.html#locate.locate
<clever> Judson: how did you enable mlocate?
<clever> Cale: the only way to check the key is to download something from it, and you need to know the hash of something it has to do so
<clever> hyper_ch: also be aware, compression doesnt take effect on the data when enabled, it takes effect at write time
<clever> but out of fear of future forkbombs, you keep autologin off
<clever> heh
<clever> i restart so little that its not a bother
<clever> i dont
<clever> hyper_ch: the above is for a crap-ton of compiled haskell packages
<clever> zfs-test2 97G 14G 83G 15% /zfs-test2
<clever> zfs-test1 106G 23G 84G 21% /zfs-test1
<clever> zfs-test1 compressratio 2.86x -
<clever> zfs-test2 compression gzip-9 local
<clever> zfs-test1 compression lz4 local
<clever> zfs-test2 compressratio 4.49x -
<clever> hyper_ch: using the above, you can then experiment, and make a 10 drive array of 512mb images, and play around to see what it does
<clever> and its all gone
<clever> [root@amd-nixos:~]# rm image-1.img
<clever> [root@amd-nixos:~]# zpool export pool1
<clever> after that, df -h reported it as being bigger
<clever> hyper_ch: and there it is, thats the command to make zfs fully utilize the size of the partition/device its already on
<clever> [root@amd-nixos:/pool1]# zpool online -e pool1 /root/image-1.img
<clever> -e Expand the device to use all available space. If the device is part of a mirror or raidz then all devices must be expanded before the new space will become available to the pool.
<clever> zpool online [-e] pool device...
<clever> hyper_ch: aha, because autoexpand was off
<clever> pool1 autoexpand off default
<clever> NAME PROPERTY VALUE SOURCE
<clever> [root@amd-nixos:/pool1]# zpool get autoexpand
<clever> and it did not auto-resize with defaults
<clever> cp: error writing './jdk-8u131-linux-x64.tar.gz': No space left on device
<clever> it now has an expand size of 512mb
<clever> pool1 496M 126K 496M 512M 0% 0% 1.00x ONLINE -
<clever> NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
<clever> i had to give -d, because the "device node" isnt in /dev/
<clever> re-import the pool (the zfs name for mount)
<clever> [root@amd-nixos:~]# zpool import pool1 -d /root/
<clever> double the size of the disk image
<clever> [root@amd-nixos:~]# truncate image-1.img -s 1g
<clever> (the zfs name for umount)
<clever> [root@amd-nixos:~]# zpool export pool1
<clever> pool1 496M 105K 496M - 0% 0% 1.00x ONLINE -
<clever> NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
<clever> [root@amd-nixos:~]# zpool list
<clever> neither will a lot of other tools
<clever> zfs wont know which one to use
<clever> yeah, dd is the simplest, as long as the old drive is never present when the new is booting
<clever> this creates a pool out of that image
<clever> [root@amd-nixos:~]# zpool create pool1 /root/image-1.img
<clever> this creates a 512mb file
<clever> [root@amd-nixos:~]# truncate image-1.img -s 512m
<clever> hyper_ch: again, you can also test this with the truncate command
<clever> hyper_ch: resize the partition to be bigger, and then mess with the expand setting in zpool (check its man page)
<clever> hyper_ch: yes
<clever> nix-env expects certain things about the value it loads
<clever> and just do qt4 = pkgs.qt4.override { gtkStyle = true; };
<clever> sirkha: at this point, its simpler to just make a packageOverride in ~/.config/nixpkgs/config.nix
<clever> ah
<clever> your trying to index the "-E" attribute of the string
<clever> take -A out
<clever> wait no
<clever> ah, nix-env is probably expecting a set/function
<clever> sirkha: what command did you run
<clever> sirkha: all it does is eval a chunk of nix expression, which must return a derivation
<clever> because its called gtkStyle, not gtkstyle
<clever> 10 , gtkStyle ? true, gtk2
<clever> nix-env -i -E 'with import <nixpkgs>{}; qt4.override { gtkstyle = true; }'
<clever> because of how nix works
<clever> and also, installing an overriden qt4 may not make programs use it
<clever> sirkha: that wont call .override
<clever> correct
<clever> [clever@amd-nixos:~/apps/cc]$ nix-locate bin/infocmp
<clever> ncurses.dev 63,752 x /nix/store/d329049jlh4z31rr0i9cw0qnad2w4qbs-ncurses-6.0-dev/bin/infocmp
<clever> id ignore it
<clever> yeah, i either use gparted (graphical) or fdisk
<clever> and easyer copy/paste
<clever> fearlessKim[m]: the only benefit to the graphical cd is a graphical web-browser for the docs, and a graphical way to configure the wifi
<clever> fearlessKim[m]: no, it only has the CLI nixos-install
<clever> ~/.fishrc
<clever> it might be something you installed into $HOME
<clever> dont know then
<clever> (run ps)
<clever> is root also fish, or bash?
<clever> just so you know when your on root
<clever> thats normal for a lot of systems
<clever> what differences have you noticed?
<clever> [root@amd-nixos:~]# nix-env --list-generations -p /nix/var/nix/profiles/system 330 2017-09-27 11:53:06 331 2017-09-29 19:23:08
<clever> iqubic: because #1 ceased being used when #2 was created
<clever> iqubic: if generation 1 has date X, and generation 2 has date Y, nix-collect-garbage will use Y as the date #1 was last-used

2017-10-02

<clever> overlays allow you to specify several sets of package overrides, and nixpkgs will merge all of them together
<clever> and they could be other package sets
<clever> package overrides (and overlays) can just add any attribute you want to pkgs
<clever> nixpkgs.config.packageOverrides = pkgs: { unstable = import <unstable> {}; };
<clever> i havent played with overlays yet
<clever> or let unstable = import <unstable> {};
<clever> (import <unstable> {}).packageName
<clever> no
<clever> as <unstable>
<clever> iqubic: yeah
<clever> iqubic: yeah
<clever> nixos-rebuild will use the channel called nixos
<clever> allow you to refer to a channel as nix-env -iA <name>.hello
<clever> iqubic: "man nix-channel" and "nix-channel --remove"
<clever> lejonet: if they depend on eachother, id open one pr for both
<clever> Eisfreak7: but when you just import it directly, it loads the config from $HOME
<clever> Eisfreak7: when nixos loads nixpkgs for the pkgs argument, it passes in nixpkgs.config
<clever> let unstable = import <unstable> { config = { allowUnfree = true; }; in
<clever> Eisfreak7: you have to pass a config attr to it when importing
<clever> Eisfreak7: that 2nd copy of nixpkgs is loading ~/.nixpkgs/config.nix
<clever> the path appearing in any argument to mkDerivation
<clever> the lib.optional stops that
<clever> it only depends on sssd if the path of sssd gets sent to stdenv.mkDerivation
<clever> no
<clever> lejonet: add sssd to the arguments on line 1
<clever> lejonet: nix doesnt allow either one in the store
<clever> the hard part, is that this sudo isnt setuid root
<clever> nix-build -E 'with import ./. { config = {}; }; sudo.override { ... }'
<clever> and for the override
<clever> in the root of the nixpkgs checkout
<clever> nix-build -A sudo
<clever> ah
<clever> then ensure the packageOverride is present in that config.nix
<clever> lejonet: nix-build -A sudo --arg config 'import ./config.nix' is one option
<clever> yep
<clever> (assuming you also remove it from buildInputs)
<clever> if optionals doesnt return sssd, then you wont depend on it at build time
<clever> nix-repl> lib.optionals false [ "--with-sssd" "--with-sssd-lib=${sssd}/lib" ]
<clever> [ ]
<clever> some pastebins use '' specialy, i prefer using gist
<clever> [ "--with-sssd" "--with-sssd-lib=/nix/store/5xgwy0aywvkmj7v6qckaldqyij43bzc3-sssd-1.14.2/lib" ]
<clever> nix-repl> lib.optionals true [ "--with-sssd" "--with-sssd-lib=${sssd}/lib" ]
<clever> static const char path[] = _PATH_SSSD_LIB"/libsss_sudo.so";
<clever> lejonet: can you pastebin the current override?
<clever> lejonet: that causes this to get set
<clever> #define _PATH_SSSD_LIB "$sssd_lib"
<clever> lejonet: we will need to refer to the sudo source (or docs if we are lucky)
<clever> just pop it into buildInputs and see what happens
<clever> that also works sometimes
<clever> and the configure script/gcc will persist that path within the elf files, so it will automatically be required at runtime
<clever> then if you pass true to the lib.optional, it will include the sssd path at build time, and download sssd
<clever> lejonet: and if the build doesnt put a copy of that path somewhere under $out, it wont be required at runtime
<clever> lejonet: if lib.optional doesnt return the path, it wont be downloaded at build time
<clever> its getting late as well, i should get to bed
<clever> v0lZy: and this "package" is just a collection of bash scripts: https://gist.github.com/cleverca22/2c088cd9ed86fa9370d29e422111d89d