<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>
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: 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>
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