<clever>
slabity: nixops can only access the ssh agent if the $SSH_AUTH_SOCK var is set right
<clever>
slabity: are you running nixops in the same terminal?
<clever>
deni: some of the columns can be , seperated, space always seperates columns from eachother
<clever>
slabity: does the key you added actually exist in /root/.ssh/authorized_keys ?
<clever>
deni: enless your trying to set the mandatory features
<clever>
deni: the features at the end must be , seperated
<clever>
slabity: as the user that runs nixops, start ssh-agent, and do an ssh-add
<clever>
WhatisRT: i think the default for dhcp may have changed
<clever>
deni: its set on the local machine, the one starting the build
<clever>
deni: when true, the remote machine will obey its own `substituters` in its own `nix.conf`, to fetch what it can first
<clever>
deni: that depends on the builders-use-substitutes flag, check `nix show-config | grep builders-use-substitutes`
<clever>
slabity: launch an ssh agent, and ssh-add your ~/.ssh/id_rsa
<clever>
slabity: but if an ssh agent is running, those keys will leak into nixops and give it more power then it "should have"
<clever>
slabity: so it never loads ~/.ssh/id_rsa directly
<clever>
slabity: nixops will override the default private key location, to use its own keys
<clever>
deni: when you use a build machine, you first download all dependencies to the current machine, then you copy them to the remote machine, and ask it to do the build, then copy the product backwards
<clever>
tilpner: in vim, you can just do: 52i0<escape>
<clever>
deni: you likely need to be a trusted user on the remote machine, to copy pre-built things over to it
<clever>
gchristensen: ive noticed a few things in the queue-runner-status, that arent in the metrics, let me find an example
<clever>
lordcirth__: what else could you do with that metric?
<clever>
lordcirth__: sort of tricky, if you just report total time spent compressing, you wind up just showing cpu usage for that task (time spent vs time elapsed)
<clever>
leo_: probably
<clever>
gchristensen: those might even be small enough that the L1 or L2 cache could hold the entire thing
<clever>
gchristensen: not a single one of those was over 1mb, lol
<clever>
88mb in 46 seconds, ouch!
<clever>
> 92888096 / 1024 / 1024
<clever>
> 92888096 /1024 /1024
<clever>
(92888096 bytes, compressed 86.4% in 46864 ms) to binary cache
<clever>
gchristensen: youll find lines like this in the journal for hydra-queue-runner
<clever>
gchristensen: (1578144 bytes, compressed 89.7% in 499 ms) to binary cache
<clever>
both have a hydra, only one is booted
<clever>
there are 2 identical nixops deployments
<clever>
*duh*
<clever>
oh wait
<clever>
gchristensen: i cant get into the hydra that is uploading to s3, lol
<clever>
gchristensen: ok, thats an issue..... ssh is blocked on the firewall
<clever>
oh, it does log the cpu time spent...
<clever>
gchristensen: ive also only really noticed the xz bottlenecks when dealing with ghc derivations
<clever>
to see if something has been built before
<clever>
another factor that can slow some hydra's down (but not nixos's), is checking upstream caches for narinfo files
<clever>
gchristensen: how many cores on hydra.nixos.org ?
<clever>
yep
<clever>
i had to attach gdb and grab a backtrace, to see what it was "hung" on
<clever>
Hc i think
<clever>
so if you hit the right keys in top, you can see what drv each thread is compressing
<clever>
andi-: it also puts the drv name into the threads argv[0]
<clever>
gchristensen: its just compressing one std::string into a second pre-allocated std::string, so it needs zero fileio, and zero memory allocations
<clever>
gchristensen: weirdly enough, its doing it so well, it doesnt make a single syscall, so its imposible to even know why its "hung" for 2mins with only strace, lol
<clever>
gchristensen: i found that hydra often gets bottlenecked with xz compression
<clever>
,pr nahamu
<clever>
werner291: there is no linux5 in 19.09
<clever>
werner291: everything says it should be working...
<clever>
werner291: any overrides or overlays in configuration.nix? can you pastebin the entire file?
<clever>
thats strange
<clever>
werner291: and youve ran nixos-rebuild as root?
<clever>
werner291: what does `echo $NIX_PATH` report?
<clever>
werner291: what path is configuration.nix at ?
<clever>
werner291: what exactly did you add to systemPackages ?
<clever>
werner291: nix-env only reads config.nix
<clever>
werner291: yes
<clever>
werner291: and is codium in /run/current-system/sw/bin/codium ?
<clever>
werner291: did nixos-rebuild work without errors?
<clever>
werner291: yes
2019-11-12
<clever>
NoctisLa1: behind the scenes, `--upgrade` does `nix-channel --update nixos`, which only updates the nixos channel
<clever>
betaboon: yep
<clever>
correct
<clever>
betaboon: so you run the 1st, once it boots you run `justdoit`, and shutdown, then run the 2nd to actually boot the machine it just installed
<clever>
one uses -kernel and -initrd to boot the install media i'm testing
<clever>
the attrs at the bottom each create a pair of qemu scripts
<clever>
the efi firmware may be loading the default path
<clever>
i cant remember if its actually persisting efi vars though
<clever>
betaboon: thats what ive used when testing efi installs under qemu
<clever>
samueldr: check the simple-test.nix in my kexec dir, that sets up the second flash
<clever>
there is a qemu flag that should make nvram persist
<clever>
and then use the same flags in the tests
<clever>
it would let you at least confirm if nvram persists or not, when using certain flags
<clever>
samueldr: if you `-boot menu` with efi enabled in qemu, i believe you can get into the full efi bios config UI
<clever>
gchristensen: what could i run to query the agent and prod it do things and debug it?
<clever>
gchristensen: tried that, no difference
<clever>
gchristensen: my gpg ssh agent has been busted since the last nixos upgrade, it just fails with "sign_and_send_pubkey: signing failed: agent refused operation" now
<clever>
selfsymmetric-pa: what args did you give it?
<clever>
selfsymmetric-pa: that a shell command
<clever>
selfsymmetric-pa: how does current-system depend on the fonts?
<clever>
betaboon: nixos-unstable-small updated 6 hours ago, so the basic tests are passing
<clever>
,howoldis betaboon
<clever>
slabity: i'm just running full-blown nixos on a router, with 2 cpu sockets, and 8gig of ecc ram
<clever>
__monty__: from #nixos-on-your-router
<clever>
2019-11-12 04:27:23 < clever> Nov 12 04:23:15 system76 3s0avjla52qx9zx8yi6glba43did5bvq-unit-script-wpa_supplicant-start[7893]: /nix/store/3s0avjla52qx9zx8yi6glba43did5bvq-unit-script-wpa_supplicant-start: line 4: /sys/class/net/bonding_masters/uevent: Not a directory
<clever>
__monty__: looks like you fixed the exact problem i was having
<clever>
__monty__: oh, that may help my issues too
<clever>
slabity: can you pastebin the output of both commands and the commands themelves?
<clever>
slabity: does `nixops list` list `mysystem` ?
<clever>
betaboon: also, the tty changes in nix-daemon somehow broke all logging in the derivation that builds the boot image
<clever>
betaboon: so you need special flags to control the boot order
<clever>
betaboon: i think the basic problem, is that with 2 virtio devices, qemu doesnt know which one to boot from
<clever>
betaboon: not sure why, i got distraced and never followed up on the comments as well
<clever>
kenran: ah, if you just want an env var pointing to it, do `env_var = writeText "name" "contents";` in whatever you pointed `nix-shell` to (inside the mkDerivation)
<clever>
kenran: and then just run nix-build on that file, and then `cat result`
<clever>
kenran: for example, just shove this into a file: with import <nixpkgs> {}; writeText "name" "hello is at ${hello}"
<clever>
if using a set, then you -A something, to select a key in the set