<clever>
boxscape: what pid/process do the <number>'s refer to?
<clever>
boxscape: do you have a nix-shell open?
<clever>
boxscape: try the --query as root?
<clever>
boxscape: lol!
<clever>
boxscape: you will need to depending on what {censored} is, you will need to delete it, but the safe way to do so differs depending on what it is
<clever>
boxscape: try running `nix-store --delete` on that path, and dont use the force flag
<clever>
dsg: i prefer setting it to a specific rev, but you can also point it to a local channel (managed by nix-channel) or just directly to a channel
<clever>
# nixops modify -d house deployments/house.nix -I nixpkgs=https://github.com/nixos/nixpkgs/archive/dae9cf6106d.tar.gz
<clever>
2019-09-28 11:48:09 < pie_> ah ok, but i just meant for the usersapce, like nix-shell -I nixpkgs=channel:nixos-unstable zfs or something
<clever>
dsg: nixops modify -d name foo.nix -I nixpkgs=something
<clever>
boxscape: that corrupted some files, try doing a `nix-collect-garbage` to see if it can delete the corrupt ones
<clever>
boxscape: have you had any improper shutdowns lately?
<clever>
jluttine: or the sudoers file?
<clever>
jluttine: have you looked into systemd user services?
<clever>
pie_: did you mess with the channels before the nixos-rebuild?
<clever>
then you also need to reload spl
<clever>
name another!
<clever>
pie_: name one
<clever>
pie_: is spl in `lsmod` ?
<clever>
pie_: what unknown symbol? what does dmesg say?
<clever>
2019-09-28 11:44:07 < clever> pie_: try turning on enableunstable then, from the iso, then `rmmod zfs` and `modprobe zfs` to reload it, dont update the nix channels
<clever>
pie_: thats why i said to rmmod first, a few mins ago
<clever>
pie_: correct, modinfo looks at the fs, not the live kernel
<clever>
pie_: did you `rmmod zfs` first?
<clever>
pie_: realpath $(which zfs)
<clever>
pie_: zfs --version?
<clever>
pie_: the kernel part is the most important one i think
<clever>
,pills
<clever>
pie_: which is why i said to not update channels
<clever>
pie_: if you mess with the channel, the zfs module wont fit your kernel version, and you cant load it
<clever>
pie_: userspace is the part that will update the easiest
<clever>
xok: ive never used that
<clever>
pie_: what did it fail with?
<clever>
pie_: try turning on enableunstable then, from the iso, then `rmmod zfs` and `modprobe zfs` to reload it, dont update the nix channels
<clever>
pie_: i typically travel with 3 or 4 random usb sticks, lol
<clever>
xok: you can use `nixops set-args --arg foo 42` to pass an argument to the deployment file, and then use `lib.range` and `lib.map` to dynamically generate N machines
<clever>
pie_: do you have 2 usb sticks?
<clever>
but you cant reboot the iso
<clever>
pie_: changing zfs flags at runtime is tricky, and its best to reboot first
<clever>
pie_: did you set any zfs options in configuration.nix?
<clever>
pie_: nix-du does that
<clever>
that removes a root, and then normal gc can delete it
<clever>
ivan: also, i have an open issue on nixops, that would do what you said above
<clever>
ivan: sounds like nixops
<clever>
ivan: morph?
2019-09-27
<clever>
samueldr: what happens fi you run `nix-collect-garbage --max-freed 1` ?
<clever>
gchristensen: that file also has derivations for signing things, but the keys wind up in the nix store
<clever>
67 locks requirements for signatures on, then 69/70 fetch a script/sig, and validate it, then execute it
<clever>
gchristensen: but with the script= on line 65, it will embed that into the binary, and always run that on bootup, so it wont dhcp, and wont run whatever dhcp tells it to
<clever>
gchristensen: the embeded script is also of use, without that, ipxe will default to not needing signatures
<clever>
gchristensen: dummy certs/keys are in the repo (for CI) along with a regen script, because they keep expiring (and breaking CI)
<clever>
hodapp: try the 2nd one then, with --store
<clever>
hodapp: yep
<clever>
hodapp: or `nix-store --store local?root=/mnt --delete /nix/store/foo`
<clever>
hodapp: nixos-enter
<clever>
hodapp: run `nix-store --delete` on the storepath, what does it say?
<clever>
hodapp: and nixos-rebuild is just a helper script that runs nix-build
<clever>
hodapp: nixos-install is basically just a helper script, that runs nixos-rebuild in a chroot
<clever>
since ext4 was interupted mid-write
<clever>
hodapp: could have similar effects though
<clever>
hodapp: nix-store --verify --check-contents, will validate everything
<clever>
hodapp: but ext4 can commit things out of order, and i have seen files get truncated after nix flagged them as valid, after an improper shutdown
<clever>
hodapp: nix wont register a path as valid in db.sqlite until it has finished writing it
<clever>
exarkun: that leads to you spending 6 hours trying to get your changes to print anything at all :P
<clever>
exarkun: if you then `nix-build -A nixops` and ./result/bin/nixops, it will use the nixops from nix-shell, not from result
<clever>
exarkun: ive run into related problems, if you `nix-shell -p nixops`, it will leak a PYTHONHOME
<clever>
gchristensen: i'm using buildLayeredImage and am winding up with 3gig layers, got any tips on how to debug it, or should i just increase the layer count more?
<clever>
spazzpp2: what about the dmesg output?
<clever>
spazzpp2: that would be the problem, it shouldnt be empty
<clever>
spazzpp2: what is the contents of that file?
<clever>
EFI eliminates that issue
<clever>
but grub also almost never updates
<clever>
ive yet to break a machine, lol
<clever>
then the MBR just never updates
<clever>
personally, i usually just set it to "nodev" after i install
<clever>
so it can still boot, but you will likely want to fix it, or you risk overwriting the MBR of the wrong disk
<clever>
hodapp: which only happens when the grub version changes
<clever>
hodapp: nixos will only use that device setting when it has to re-install the bootloader to the MBR
<clever>
sphalerite: so you can either write a dhclient hook, or switch to dhcpcd, and use a dhcpcd hook
<clever>
On after defining the make_resolv_conf function, the client script checks for the presence of an executable /etc/dhcp/dhclient-enter-hooks script
<clever>
Type: one of "dhclient", "dhcpcd", "internal"
<clever>
sphalerite: does network-manager have any dhcp hooks? what dhcp client does it use?
<clever>
and i then echo'd them to a file, in the right format, to include into the bind cfg
<clever>
sphalerite: the dns servers are in an env var when that hook gets ran
<clever>
Shell code that will be run after all other hooks. See `man dhcpcd-run-hooks` for details on what is possible.
<clever>
networking.dhcpcd.runHook
<clever>
sphalerite: `man dhcpcd-run-hooks`
<clever>
sphalerite: `Hooking into events` in `man dhcpcd`, it will run some shell scripts when it does things
<clever>
sphalerite: ah right, i did that on an old gentoo machine, let me see what the exact method was...
<clever>
sphalerite: ive done that before, let me see
<clever>
slabity: `nix show-config` also shows the result of parsing the config
<clever>
slabity: --option just lets you override any nix.conf entry
<clever>
gchristensen: packet.net could be a real pxe boot, with the installer image
<clever>
gchristensen: aws would just have an ami, that is basically the installer iso with ssh enabled, to let you in
<clever>
gchristensen: and the kexec is an optional function, that some backends can choose to use, but the backend must supply a way of getting root on a rescue shell or ubuntu image
<clever>
gchristensen: my idea, is that steps 2/3/4 are all a common library, that any nixops backend can use
<clever>
then you just reboot, and its live!
<clever>
which installs the bootloader for an already copied nixos
<clever>
infinisil, gchristensen: did you see my nixops issue, that could use nixpart features?
<clever>
hodapp: because then changes you make to that stick persist, and you can leave a clone of your config repos, and ssh priv keys on it
<clever>
hodapp: nixos-install works on any nixos machine, and i do prefer the idea of just installing to a usb stick
<clever>
and then you can do whatever you want
<clever>
the reason i was thinking haskell and rpc, is that the guest could create any kind of object, serialize it, and fire it off to the host, which deserializes
<clever>
and also stream logs over, in real-time
<clever>
exarkun: the guest side can then do lines 34-55, and spit out a json blob? with status
<clever>
exarkun: step 1, boot the vm, step 2, tell the guest half of the code to do everything else
<clever>
exarkun: for this test for example, i just want the host side to be a 2 step process
<clever>
network and tcp isnt going to be available
<clever>
does haskell have anything close to that?
<clever>
exarkun: the issue, is that i basically need an RPC channel, that can act over a byte stream, and is mux-able (can deal with parallel concurrent streams)
<clever>
exarkun: and then haskell code in each guest, doing actions, and reporting status over the rpc
<clever>
exarkun: so you can have haskell code in the host, acting as a conductor
<clever>
exarkun: with haskell code on both the client and server side (host and guest)
<clever>
exarkun: what i want, is a haskell library, with a muxed RPC over that serial console
<clever>
exarkun: that is something i have wanted to solve
<clever>
exarkun: also behind the scenes, it uses a qemu hypervisor serial port, to get a backdoor shell into the guest