2018-06-22

<clever> infinisil: i'm actually looking into eval-time problems with nixops right now
<clever> bpye: preStart automatically sets an attribute in serviceConfig
<clever> as somebody else had done when toying with {^_^}
<clever> > let a = (let AAAA = 3; in AAAA); in AAAA
<clever> it was already defined to something else
<clever> > b
<clever> bluej774: the above also applies to gcc
<clever> ,library
<clever> bpye: yeah
<clever> bpye: you have to overwrite the entire serviceConfig with mkForce due to how the nixos options work
<clever> bpye: thats not a package, but a nixos module
<clever> bpye: you can also use overrides
<clever> ErikD_: also, is this nixos or nix on another distro?
<clever> did you run `fdisk /dev/sda` or `fdisk /dev/sda1` ?
<clever> Oogieboogie: did the drive originally have LVM enabled?
<clever> youll need to reboot to apply the fdisk changes
<clever> something was probably mounted when you edited the partition tables, so the kernel couldnt reload it
<clever> irc ate it, prefix the path with a space
<clever> return to the fdisk step and recreate the partition
<clever> yeah
<clever> why is your root filesystem only 1kb in size?
<clever> just lsblk, no args
<clever> Oogieboogie: what does `lsblk` say about sda1 ?
<clever> ssh makes it much simpler to scroll up or copy/paste
<clever> shift+page up can scroll in the console
<clever> and what did it print?
<clever> what are the exact args you used when you ran mkfs?
<clever> that means it hasnt been formatted
<clever> which would also explain why it cant find any FS with the label nixos
<clever> it sounds like you never formatted sda1
<clever> it should also give a filesystem type
<clever> blkid /dev/sda1
<clever> the mount command doesnt accept -L
<clever> you must do `mount /dev/sda1 /mnt`
<clever> Oogieboogie: sda1 is not a directory, so you cant do /dev/sda1/nixos
<clever> Oogieboogie: and what is the exact command you ran?
<clever> Oogieboogie: what error does it fail with?
<clever> Oogieboogie: it only works by-label if you have set a label with you ran mkfs.ext4

2018-06-21

<clever> yeah
<clever> infinisil: it may also be an XY problem, ./foo gives file not found
<clever> ,library
<clever> and have fun compiling ghc on a new platform :P
<clever> voidconf: ghc is over a gig in size
<clever> voidconf: i'm guessing its the bootstrapping and compiler size problems

2018-06-20

<clever> tenten8401: strace is always the answer
<clever> eacameron: nix-store -q --tree also shows a tree
<clever> eacameron: when ran on a .drv file, it only shows buildtime deps
<clever> eacameron: when you run nix-store -qR on a non-drv file, it only shows runtime deps
<clever> M-dpetranek: a service like bind that is listening on port 53 udp
<clever> eacameron: nix-store -qR
<clever> anp, not ano
<clever> M-dpetranek: netstat -ano | grep udp | grep 53
<clever> M-dpetranek: is there a local dns server listening on port 53?
<clever> M-dpetranek: what does /etc/resolv.conf contain?
<clever> aws has a standardized base install it clones, so the rootfs config is predictable
<clever> tenten8401: only targetEnv = "none"; requires things like the rootfs
<clever> tenten8401: of note, when using the targetEnv = "ec2"; nixops will auto-create an ec2 instance in aws, using an AMI image, and in that setup, it knows the rootfs config and can boot with an empty config
<clever> and i'm off to bed now, nearly 1am
<clever> tenten8401: nixops doesnt know how the machine boots, so you have to copy over all of configuration.nix and hardware-configuration.nix
<clever> and the default unpackPhase will copy it to the temp dir, and use that copy
<clever> yeah
<clever> so nix never unpacked the source
<clever> you didnt put unpackPhase in the phases list
<clever> can you gist your nix file?
<clever> is that under nix-shell or nix-build?
<clever> what files does ls show?
<clever> does `ls *.cabal` find the file?
<clever> but if you want to mess with the code in a git checkout, you can skip the unpackPhase (and ignore $src) and just cd into that git repo
<clever> rizary: and the unpackPhase will by default copy that to the current dir
<clever> rizary: nix will copy the dir ./. pointed to into /nix/store/
<clever> genericBuild is the function to run all of the phases in order
<clever> rizary: the buildPhase expects you to be in the source directory, which was made by the unpackPhase
<clever> rizary: with nix-shell you typically need to cd into the dir the source comes from, or run the unpackPhase to create that dir, then cd into it
<clever> ah, that could work
<clever> if you ran `nixos-rebuild switch1
<clever> infinisil: but that could still overwrite config in /boot and leave you unable to ssh in
<clever> and the management of that machine itself would be done by either running nixops on a local machine, or creating a deployment to manage itself
<clever> yeah, you would have to ssh into that machine, and then run nixops there
<clever> build slaves also let you build things for other platforms
<clever> then download it to the machine running nixops
<clever> but if you also configure that server as a build slave, it will build it on that server
<clever> yeah
<clever> deployment.hasFastConnection controls how much the remote machine will use the binary-cache to avoid uploading things
<clever> and then uploads the entire nixos closure using nix-copy-closure
<clever> it builds it on the machine running nixops
<clever> it only has to be set manually if you want to avoid it using whatever the host has
<clever> and nixops will then create its own key and allow that in
<clever> yeah
<clever> but if you have your own keys for root, you can recreate the deployment on another machine, and continue to deploy
<clever> it stores the keys in ~/.nixops/deployments.nixops
<clever> but after it deploys, it will give its own key access
<clever> when using the `none` targetEnv, you need to initially give it root via a password or ssh-agent
<clever> yeah
<clever> using modify like above, you can tell nixops to use a specific version, then it will always be predictable
<clever> yeah
<clever> so my router uses a specific version, and wont update when the laptop updates
<clever> and then it always uses that rev of nixpkgs
<clever> if you run this, you can change the default NIX_PATH for a deployment
<clever> # nixops modify -d router -I nixpkgs=https://github.com/nixos/nixpkgs/archive/ce0d9d638de.tar.gz deployments/router_deployment.nix
<clever> which may not always be what you want
<clever> also of note, nixops will use whatever <nixpkgs> points to on the host
<clever> i think its `nixops rollback`
<clever> the above file is an example of managing a pair of 32bit netbooks
<clever> yeah
<clever> and if you set network.enableRollback on the nixops file, it will also create generations locally (on the box that ran nixops)
<clever> so if you have access to the bootloader or `nixos-rebuild --rollback`, you can undo any deployment
<clever> when you deploy with nixops, it creates a generation on the remote machine
<clever> this also changes the path of <nixpkgs> to match the one you built the system with (via nixops)
<clever> so nixos-rebuild is now just broken
<clever> it changes the default path of configuration.nix to a pre-defined one, that always fails
<clever> tenten8401: thats why i always add this to the imports of anything i manage with nixops
<clever> yeah
<clever> yep
<clever> tenten8401: and then you run `nixops create -d name bar.nix` on the file containing the above line
<clever> tenten8401: then foo.nix contains what you original used as configuration.nix
<clever> { hostname = { deployment = { targetEnv = "none"; targetIp = "1.2.3.4"; }; imports = [ ./foo.nix ]; }; }
<clever> tenten8401: it would probably help, basically, you make a nix file containing...

2018-06-19

<clever> without the $ on VAR
<clever> rizary: same way you do it in bash, export VAR=value
<clever> it still needs to know where to put the .efi binaries
<clever> yeah
<clever> once it boots with efi once, you can unset that, and then nixos will poke around in the efivars
<clever> yeah
<clever> and those cant be in the efivars, because they are removable
<clever> it uses the same filename as removable drives, so the bios is tricked into thinking its a bootable usb stick
<clever> tenten8401: this option allows you to do an efi install without access to the efivars
<clever> boot.loader.grub.efiInstallAsRemovable = true;
<clever> Dezgeg: ah, but if the rescue system isnt efi, it cant forward it on anyways
<clever> then either the bios doesnt support efi, or the rescue system was not booted via efi
<clever> efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
<clever> tenten8401: when in the rescue system, do you see the efi vars filesystem mounted?
<clever> Dezgeg: i dont think the kexec method passes the table of function pointers from the EFI
<clever> thats where kexec helps a lot, you can just scp a ~200mb tar file to the server, run it, and your in the installer
<clever> kexec is simpler then booting the iso into qemu and redirecting the hdd's in
<clever> tenten8401: also, kexec doesnt handle efi either
<clever> tnks: *waves*
<clever> i'm guessing its something to do with /etc/profile or /etc/bashrc
<clever> i just `sudo -i` and then `nixos-rebuild switch`
<clever> NIX_PATH=$HOME/.nix-defexpr/channels:nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/profiles/per-user/root/channels
<clever> tnks: id just use a noral root shell: sudo -i
<clever> tnks: yeah, nix-path cant be set like that
<clever> weird
<clever> tnks: try just `sudo FOO=bar env`
<clever> tnks: possibly, try another custom var
<clever> tnks: does /etc/sudoers mention either var?
<clever> yeme: you can also use nix.nixPath in configuration.nix to change the default NIX_PATH, but you still need to -I nixpkgs=/path/to/nixpkgs the first time
<clever> yeme: you have to use -I nixpkgs=/path/to/nixpkgs
<clever> you can also read the script, manually download the files with wget, and then unpack them and configure it properly
<clever> ah
<clever> bluej774: either pipe it directly into sh, or save it to a file and run sh on it
<clever> bluej774: curl https://nixos.org/nix/install
<clever> bluej774: there is also a bash script that just downloads a pre-compiled copy of nix
<clever> so every single one of those nix-channel --add's had zero effect
<clever> hyper_ch: you forgot to run nix-channel --update
<clever> hyper_ch: what version of nixpkgs are you using?
<clever> hyper_ch: can you gist the error?
<clever> at least you didnt have to wait 5 hours for chrome to compile, only for it to stop crashing :P
<clever> 12:46 AM here, and chrome is still segfaulting
<clever> and mount it to /mnt/boot
<clever> yeah, then re-format one of those partitions as ext4 and fix-up its type-code in fdisk
<clever> about all i can think of is to do a non-mirrored /boot, you can always recreate /boot from the rescue system
<clever> tenten8401: not sure how to fix your /boot raid issues, but i can help you mess with kexec if you want to compare it to qemu and see which is simpler
<clever> yeah, i'm not sure why grub cant identify things
<clever> ah, then thats not why it was slow to boot
<clever> tenten8401: on the rescue system, what does `ls -l /dev/kvm` report?
<clever> also of note, both qemu and kexec will break configuring efi in the bios, so efi based installs wont work with either trick
<clever> you just upload a tarball to a rescue system, run the shell script within, and now its running nixos from a ramdisk
<clever> not that you have to switch, but here it is: https://github.com/cleverca22/nix-tests/blob/master/kexec/session.md
<clever> ah, that sounds like the perfect job for my kexec trick
<clever> MBR partition tables, so efi would never have worked to begin with
<clever> tenten8401: `systemctl start sshd` and `passwd`, then you can ssh into it, if you want
<clever> tenten8401: what does "fdisk -l /dev/sda" report?
<clever> so you always have enough users
<clever> copumpkin: for example, the max number of concurrent builds, and the number of build users, are tied together by default
<clever> copumpkin: the nix-daemon service already does that
<clever> copumpkin: mkMerge will handle the same merging as imports and other modules
<clever> tenten8401: then set efi to false, and restore the previous devices param
<clever> copumpkin: config = mkMerge [ { ... } (mkIf condition { ... }) ];
<clever> i think you can only do redundant bootloaders with legacy booting
<clever> in that case, you would use efiSysMountPoint = "/boot/efi";
<clever> and then the "non-mirrored" fat /boot/efi is manually mirrored after installing, the contents will rarely change
<clever> your /boot can be something linux like ext4
<clever> tenten8401: you could adjust the config a bit, use a mirrored /boot, and then have a "non-mirrored" /boot/efi
<clever> tenten8401: id just use a single /boot, ive never lost a boot partition
<clever> tenten8401: oh, grub may not understand the raid stuff
<clever> tenten8401: and boot.loader.grub.devices is only for legacy booting, it should probably be set to "nodev"
<clever> tenten8401: efiSysMountPoint must be set to /boot since thats where your fat partition is mounted
<clever> tenten8401: can you pastebin your entire configuration.nix file?
<clever> ah, you do
<clever> everything will be made read-only and owned by root
<clever> nix-daemon will revert all the chmod bits for you when the build is done
<clever> you called it nixpkgs in your file, so nixpkgs.glibcLocales
<clever> rizary: in the install phase, after you copy the frontend
<clever> export LOCALE_ARCHIVE="${pkgs.glibcLocales}/lib/locale/locale-archive";
<clever> rizary: line 22 is also not pure, you should refer to the locales within nixpkgs, not the current-system
<clever> and since the unpackPhase is also empty, you could just omit unpack from line 30, and delete lines 17-19
<clever> rizary: and if your not using the src, you can omit line 17
<clever> rizary: you need to chmod -R +w $out/prod/static/
<clever> rizary: line 26 copied the frontend package, which is read-only, so now $out/prod/static is read-only
<clever> rizary: ah, i see the problem, its not chown you want, its chmod
<clever> rizary: are you trying to modify the files in $src ?
<clever> rizary: you cant, all files you build must be owned by the user doing the build, and nix-daemon will then chown them to root when its done
<clever> yeah
<clever> tenten8401: which is also deleted at shutdown, so you have to fix the qtcreator config every time you reboot
<clever> tenten8401: ive found it only works in a nix-shell, after running the preconfigure hook, and using the qmake that nix-shell has in $PATH

2018-06-17

<clever> strace solves everything :P
<clever> id say strace both and compare
<clever> gchristensen: one per machine

2018-06-16

<clever> rizary: you must use `runhaskell Setup.hs` to access cabal
<clever> rizary: nix doesnt provide a cabal binary, only the cabal library
<clever> kreetx: if you `import <nixpkgs> {}` it can default to darwin, and then embed darwin binaries into the docker image
<clever> juhe: yep
<clever> tilpner: the nix patch has been merged into nix master
<clever> juhe: this is an example i had tested, that deploys to arm, but it needs arm build slaves to build
<clever> truthadjustr: either use `NIX_REMOTE=daemon nix-repl` or `nix repl`

2018-06-15

<clever> pie_: and if anything network related has been modified, it restarts the network
<clever> pie_: if ssh has been modified, it restarts ssh
<clever> pie_: smartctl -a /dev/sdX
<clever> pie_: and df -h?
<clever> strace df -h
<clever> yep
<clever> yeah
<clever> pie_: journalctl -f as root
<clever> pie_: ah, df is also dwarf fortress
<clever> pie_: are these all graphical programs installed with nix-env?
<clever> pie_: nix-store --verify --check-contents
<clever> hyper_ch: death to network manager!
<clever> hyper_ch: yay
<clever> so i spent 5 hours building it under nix-shell, got one segfault out of it, added more debug, and now it wont crash :P
<clever> chrome segfaulted 5 times in a row on me today
<clever> zfs time!
<clever> hyper_ch: there are 2 versions of it, with and without gui
<clever> i'm guessing network manager broke upstream
<clever> hyper_ch: then disable it with the normal nixos options, in the configuration.nix used by kexec
<clever> then read the nix expressions for it, it has a withGnome ? true option
<clever> hyper_ch: nix-build '<nixpkgs>' -A networkmanager_iodine
<clever> hyper_ch: then poke around in nixpkgs and find networkmanager_iodine
<clever> hyper_ch: first, look at the name of the derivation: NetworkManager-iodine
<clever> hyper_ch: try building just the failing network-manager derivation with nix-build
<clever> hyper_ch: that is a different package from what is failing
<clever> hyper_ch: nix-store -qR /run/current-system | grep NetworkManager-iodine
<clever> hyper_ch: does network manager build on that nixpkgs?
<clever> hyper_ch: nixos or nixpkgs?
<clever> hyper_ch: which nixpkgs channel are you using?
<clever> hyper_ch: do you want network manager in the image?
<clever> pie__: yes
<clever> sir_guy_carleton: you have to read their definitions: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/qemu-vm.nix#L193
<clever> sir_guy_carleton: the qemu options are special and dont appear in any of the automated docs
<clever> hyper_ch: can you build again with -j 1, the error is corrupted
<clever> Taneb: nix will then ensure they always exist
<clever> Taneb: if possible, embed the paths to those executables into the binary
<clever> hyper_ch: is it giving an error?
<clever> so they can mutate the state and effect eachother
<clever> ThatPako: all of setup.sh, your build phase, and the setup-hooks are just sourced into a single bash
<clever> ThatPako: yeah
<clever> dont think so
<clever> ThatPako: cc-wrapper will obey NIX_LDFLAGS_LINK and a few others
<clever> pie__: you can override the nixpkgs itself, with nixpkgs.pkgs = import ...; but you cant override the modules that nixos is using so easily
<clever> ThatPako: it appears to be a var within setup.sh
<clever> /home/clever/apps/nixpkgs/pkgs/stdenv/generic/setup.sh: for targetOffset in "${allPlatOffsets[@]}"; do
<clever> ThatPako: and then hooks like this can integrate into it
<clever> ThatPako: this bash function is ran for everything in buildInputs
<clever> pie__: yeah, all nix.nixPath does is set the value of NIX_PATH at runtime, it has no effects on the current build
<clever> ThatPako: the stdenv already automates all of that
<clever> a."b.c" = 3; will also look similar in some outputs, but is logically a different option
<clever> and its also identical to a.b.c = 3;
<clever> pie_: a.b = { c = 3; }; is identical to a = { b = { c = 3; }; }; };
<clever> pie_: it has to be a string representing the path to the module, check the example i pasted above
<clever> pie_: those 2 blocks of code appear to do almost the same thing
<clever> lol
<clever> pie_: nope
<clever> :D
<clever> infinisil: its almost done building
<clever> [30317/32348] CXX obj/third_party/WebKit/Source/modules/webgl/webgl/WebGLContextAttributeHelpers.o
<clever> pie_: nixos should merge that value between all files
<clever> infinisil: building chrome with a custom patch to stop it from crashing in about 5mins
<clever> pie_: configuration.nix is just a nixos module, and the imports field has a list of paths to more modules, so you can create a tree of modules that refer to eachother
<clever> infinisil: can you guess what ive been busy all day with? https://gist.github.com/cleverca22/ee3c5b7e567aae52e5890f3e8f82367b
<clever> Taneb: nix-bundle is one option
<clever> LnL: ah, i was wondering if this was documented anywhere
<clever> and you also need an overlay to change the version of nixpkgs that the module uses
<clever> pie_: the above has to be done in configuration.nix, not an overlay
<clever> the 2nd line then loads a copy of ntpd.nix, which you are now free to edit
<clever> the first part causes nixos to just ignore the ntpd.nix in nixpkgs, so you effectively loose ntp support
<clever> #imports = [ ./ntpd.nix ];
<clever> #disabledModules = [ "services/networking/ntpd.nix" ];
<clever> pie_: oh, i have a fix for services
<clever> but overlays are probably simpler
<clever> pie_: then use IFD in the above fetcher.nix to import the result of patching nixpkgs
<clever> pie_: you could potentially make a nix derivation that applies a .patch file to a copy of nixpkgs
<clever> /etc/systemd/system/nix-daemon.service:RequiresMountsFor=/nix/var
<clever> Myrl-saki: did you flag the service as requiring the mounts for its own data dir?
<clever> Myrl-saki: use stat instead of ls