<clever>
jumper149: i believe it returns a set, you can confirm that in `nix repl`
<clever>
hr[m]: builtins.toFile and builtins.toJSON
<clever>
energizer: ah, in my case, it was a linux router, so i had the ability to record all the stats i wanted
<clever>
energizer: i never figured out how to "fix" it, but reducing the ping to every 1 sec made the problem nearly invisible
<clever>
energizer: and it was configured to ping every 20 seconds, so it would always recover within 20 seconds, from an otherwise "permanent" hang
<clever>
energizer: and after much debugging, i eventually tracked it down to a bug in the pppoe drivers on linux, and that the pppoe pings bypassed the "permanent hang", and would fix the state
<clever>
energizer: and then after a while of that, i noticed, every time i had a problem, upload hit a perfect 0/second and download suffered (due to a lack of ack packets)
<clever>
energizer: i had written it to poll them every second, and render a real-time thruput graph, for both directions
<clever>
energizer: last time i had such issues, i wrote a custom program to watch the byte counters in /proc/net/dev
<clever>
jboy56: `import <nixpkgs>` returns a function, you want `import <nixpkgs> {}` to call that function
<clever>
zxcvqwfp: was there another lib in a place we didnt think to look?
<clever>
oops
<clever>
TargetName Type Endian TapName State
<clever>
zxcvqwfp: if you set those env vars, ld.so will print its own debug, as it tries to resolve all the DT_NEEDED's
<clever>
zxcvqwfp: lddtree makes it much more obvious which one is to blame
<clever>
zxcvqwfp: you must patchelf the rpath, of all of the other .so files
<clever>
zxcvqwfp: its in the DT_NEEDED of one of the other .so files, in the same dir
<clever>
zxcvqwfp: libXrandr.so.2 is not in the DT_NEEDED of that binary
<clever>
zxcvqwfp: and what is the rpath? patchelf can print it
<clever>
xelxebar: and what is the rpath? patchelf can print it
<clever>
zxcvqwfp: what does `file` say when ran on the binary?
<clever>
zxcvqwfp: is it a 32bit or 64bit binary?
<clever>
Alexey37: that function takes a haskell package, and does the override for you
<clever>
Alexey37: haskell.lib.dontCheck
<clever>
srk: everything else worth playing just works under proton+steam
<clever>
srk: space engineers and elite dangerous are the only 2 games that fail under proton and i sometimes want to play
<clever>
morgrimm: proton is steam's fork of wine, that has been improved to support most games, and is baked into the linux steam launcher
<clever>
morgrimm: ive found that gpu passthru tends to be picky, and you tend to have to reboot constantly, on the host side
<clever>
ornxka: theres also pgrep
<clever>
glittershark: but then it wont work for unwrapped things
<clever>
not sure how those interact with killall and pidof
<clever>
there are tricks to fudge argv[0] when launching the wrapped binary
<clever>
glittershark: depends on how the binary is named, some things are .foo-wrapped
<clever>
cinimod: you want to just set no profiling on the packages your building, and not use mkDerivation to force it to everything
<clever>
turlando: simplest is to just secure physical access to the machine
<clever>
cinimod: if you make any changes from default, then it wont be cached
<clever>
cinimod: by default, hydra is building everything twice (in the same derivation) with and without profiling
<clever>
turlando: the worst that can happen, is that somebody could read your /boot partition, and then impersonate the machine, then wait for you to enter a pw
<clever>
turlando: oh right, nvm, i was thinking zfs key, not ssh host key
<clever>
cinimod: because hydra had pre-built everything with profiling off, changing that means you must now build EVERYTHIGN yourself
<clever>
turlando: but that also means the key will be in plaintext within /boot, so it wont be secure enless you encrypt /boot via some other means
<clever>
turlando: nix is going to copy the file into the initrd for you, so it doesnt matter where you put it
<clever>
turlando: /run/keys is managed by nixops, you probably want to use a different directory
<clever>
turlando: i just build a custom installer image (like the ISO) that has that script pre-installed in systemPackages, then just run ot
<clever>
turlando: the file i linked is exactly that, a shell script to create everything
<clever>
so i may give coredump its own dataset, to turn snapshots off there
<clever>
turlando: and then on a case by case basis, add more with diff options, for example, /var/lib/systemd/coredump can have a lot of churn on some machines, and the snapshots of / then eat a lot of space
<clever>
turlando: personally, i have seperate datasets for / /nix /home and then turn on snapshots for everything except /nix
<clever>
turlando: i find it much simpler to just leave /nix on the main storage pool, so you dont have any problems in the future if it ever baloons up to 300gig, since you would have terrabytes available
<clever>
its also running a hydra
<clever>
that nas is a raidz1 of 3 x 4tb disks
<clever>
dont trust the size column, zfs makes it a lie
<clever>
naspool/nix 434G 130G 305G 30% /nix
<clever>
Filesystem Size Used Avail Use% Mounted on
<clever>
turlando: for my nas, the nix store is on the main pool for all storage
<clever>
turlando: its 74gig on my main desktop
<clever>
turlando: if you have other nixos builds, and do a lot of development, it can grow
<clever>
i'm using zfs and compression
<clever>
turlando: the nixos build for my main desktop, totals to ~7.8gig, including wine, chrome, steam, and other large packages
<clever>
cinimod: then you dont need the rvar = rvar; mess
<clever>
cinimod: lines 9-12, you want hself, not self.haskellPackages
<clever>
manveru: not completely sure, but i think it just got renamed, and you get that error if you mix nixpkgs versions
<clever>
i should get to bed
<clever>
and its getting late here, 1:36 am, dang
<clever>
worldofpeace: ah, the note you linked is more about running both at once, so NM ignores a certain IF
<clever>
worldofpeace: i checked this, and i dont see it reading the cfg
<clever>
Raito_Bezarius: also, nearly half the machine is empty, so you could make a much smaller case with the exact same motherboard
<clever>
Raito_Bezarius: but system76 didnt have any gpu choices for this model
<clever>
Raito_Bezarius: but from the photos, you can clearly see the gpu and gpu-ram missing, and a void where the gpu heatsink/fan are supposed to go
<clever>
Raito_Bezarius: i dont really watch the freq enough to know
<clever>
metasyntactical: and if you run `list_networks`, does it show the same ssid?
<clever>
Raito_Bezarius: doesnt seem to get too hot, but it mostly just sits on a desk near me
<clever>
metasyntactical: if you run `scan`, wait for results, then `scan_results`, does it show your network?
<clever>
you can also do `scan`, and when its done, `scan_results` to see the current networks
<clever>
when i do that, and run `status`, i can see the current network name and all the other info
<clever>
metasyntactical: did you tell it which interface to connect for?
<clever>
[root@system76:~]# wpa_cli -i wlp3s0
<clever>
you can also just edit wpa_supplicant.conf (which is why nix doesnt manage it for me), and restart the wpa_supplicant.service in systemd
<clever>
or wpa_gui
<clever>
metasyntactical: thats trivial with wpa_cli
<clever>
metasyntactical: i just always use wpa_supplicant bare, with wpa_supplicant.conf un-managed, and it has worked great
<clever>
Raito_Bezarius: pretty sure you will always have wpa_supplicant, because network-manager uses wpa_supplicant behind the scenes
<clever>
metasyntactical: what does `man nmcli` say?
<clever>
so i had to add a dummy char on the end, lol
<clever>
i would set the network to "abc" and then `iwconfig` would say its looking for "ab"
<clever>
Raito_Bezarius: at one time, the wifi driver for my card would cut the last byte off the network name, lol
<clever>
metasyntactical: are you able to just plug in an ethernet cable?
<clever>
Raito_Bezarius: but by default, it shares the same <nixpkgs> as the main nixos, and will rebuild every time, so bugs within nixpkgs itself (or the kernel, or other stuff) can break the rescue env
<clever>
it operates entirely from ram, and is isolated from your / partition, so it can act like a rescue env
<clever>
Raito_Bezarius: and if you want to make the free space on /boot even worse!, this will build a 2nd nixos, and jam it into /boot and your grub menu, using the same netboot stuff i talked about earlier
<clever>
but thats only partially of use, because 10 generations could share a single kernel/initrd, or they might wind up with 10 different ones of each
<clever>
Raito_Bezarius: you can also use this flag, to limit how many generations it keeps on /boot/
<clever>
i use nixops to manage my NAS and router, ans also my fully open pi
<clever>
Raito_Bezarius: except for the first deploy with nixops
<clever>
or just reboot
<clever>
Raito_Bezarius: at that point, you have to manually build the wg module for the old kernel, copy-closure it, and insmod it
<clever>
Raito_Bezarius: when the kernel versions desync, modprobe starts using /run/booted-system/ to find kernel modules, so it can reference the nixos it had booted from (with the older kernel stuff)
<clever>
Raito_Bezarius: if A and A' use the same kernel version, it will load just fine
<clever>
it still needs a "reboot", but its not going to fail then
<clever>
but with my `nix copy` based idea, you boot an installer env, deploy the config to the disk, then boot that config
<clever>
and then you immediately have to reboot, because the kernel is old and cant load the wireguard driver
<clever>
currently, you would boot an old nixos from an AMI image, and deploy your full config with wireguard
<clever>
this is also a problem that would be solved by my `nix copy` idea previously explained
<clever>
Raito_Bezarius: nixops can then detect that, and trigger a reboot, if you --allow-reboot
<clever>
Raito_Bezarius: this script will exit with code 100 to signal that special failure
<clever>
Raito_Bezarius: if the internal api of systemd changes, you cant dynamically reload systemd and switch to the new generation
<clever>
Raito_Bezarius: there is partial support for auto reboot, one min
<clever>
Raito_Bezarius: --force-reboot
<clever>
and you cant assume wg is in $PATH before you deploy, so you have to copy-closure it first
<clever>
so the central box never knows the secrets
<clever>
and only then, can you build the deployment (and bake pubs into everything), and deploy nixos to each
<clever>
to do it "securely", you would want to copy-closure the wireguard binary to the remote machines, and run the keygen commands over ssh, storing the secret remotely, and public in the nixops state
<clever>
that reminds me, i was thinking about how wireguard would work in nixops
<clever>
and now you need to insert a p between device and partition!
<clever>
because sata uses /dev/sda1, but nvme uses /dev/nvme0n1p1
<clever>
so you can then test how justdoit behaves on each
<clever>
and then configures justdoit for each of those situations
<clever>
booting with either legacy or uefi
<clever>
qyliss: this has code to spin up a qemu with either a sata, pata, nvme, or virtio disk
<clever>
because the netboot code puts the entire rootfs into the initrd
<clever>
Raito_Bezarius: most of my code to boot nixos in ram (kexec, multi-boot-helper, and others) is just grabbing that netboot kernel/initrd, and then booting it via something else
<clever>
Raito_Bezarius: this generates an ipxe script
<clever>
Raito_Bezarius: the netboot stuff in nixos also already supports ipxe
<clever>
Raito_Bezarius: havent seen that, but packet.net also allows it, you just give it the url to an ipxe script i believe
<clever>
or to make a /boot only disk image, that boots directly from ram
<clever>
but it can also be used as another option, when kexec isnt supported in your rescue kernel
<clever>
it was originally made to help a guy, that wanted to put a dozen distro installers onto 1 USB stick
<clever>
it will behave like a livecd, so all changes are lost at shutdown
<clever>
energizer: you would then add that fragment of config to your grub file, and copy the other 2 to /boot, and then you can launch the installer from grub, like any other os in a multi-boot setup
<clever>
energizer: this will generate a kernel, initrd, and grub fragment, to boot nixos into ram
<clever>
energizer: though, it could just be the /boot alone, with a kernel/initrd, and then procede to the 2nd function i gave above
<clever>
energizer: but DO requires that it be ext3 or ext4...
<clever>
armin: cant remember if thats an option or not
<clever>
so you can just boot the livecd, and let nixops install to disk
<clever>
adisbladis: the "none" backend would also have livecd support, you boot the existing ISO on baremetal, point nixops to it, and just run the 2nd function
<clever>
for packet.net, you can pxe boot the kernel+initrd, then use the 2nd func
<clever>
for something like OVH, use the api to force it into the netboot rescue console, then use the 1st func to kexec, and the 2nd to deploy
<clever>
for aws, skip the kexec stage, use an ami that boots the kernel/initrd directly
<clever>
adisbladis: then each provider like aws, will call the right ones, depending on what the provider can do
<clever>
adisbladis: the 2nd fucntion then takes ssh creds for a nixos running from ram (kexec, livecd, other similiar ones), and will `nix copy` to /mnt/nix/store, and activate
<clever>
adisbladis: i was thinking of it being a plugin that offers 2 main functions, the 1st takes ssh credentials for "not nixos" and will kexec into nixos (which aws can skip, as above)
<clever>
adisbladis: and finally, run nixos-install with a storepath, to activate the bootloader
<clever>
adisbladis: then nixops would use `nix copy` like in the above ticket, to copy to /mnt/nix/store on the aws machine
<clever>
adisbladis: for aws, you would have an AMI that contains the same kernel/initrd (plus changes to deal with aws ssh keys), and grub, and boots with root in ram
<clever>
adisbladis: and for aws, you could skip the kexec even, just put the same kernel/initrd into an AMI with grub, and boot it to ram always
<clever>
adisbladis: but kexec provisioning would make generation #1 be your exact config
<clever>
adisbladis: so once nixops has deployed, you basically doubled your disk usage, due to a mass-rebuild
<clever>
energizer: it requires a reboot
<clever>
adisbladis: one anoyance with image based stuff like the AMI's in aws, is that your rarely deploying the same nixpkgs revision
<clever>
adisbladis: so nixops can copy a pre-made closure to the target, and immediately activate the bootloader cfg
<clever>
adisbladis: it also includes directions on how to skip configuration.nix, and just use `nix copy` to copy to /mnt/nix/store on the remote machine
<clever>
adisbladis: yeah, thats what the ticket i linked is for
<clever>
so you could go to basically any cloud provider, provision a generic linux distro, then just give nixops the ip and root pw, and bam, its now nixos
<clever>
energizer: that ticket is also about extending nixos, to support kexec'ing any target to nixos