2016-12-11

<clever> yeah
<clever> m`: the user generations are from nix-env, and the system generations are from nixos-rebuild
<clever> you probably ran sudo nixos-rebuild build
<clever> so it will still hold onto a lot of 03 until he gets rid of all of those old system's
<clever> oh, yeah, he just updated from 03 to 09
<clever> so thats doubling your usage
<clever> m`: yeah, thats nixos 16.03, and your now running 16.09
<clever> m`: you have an old result symlink in your home directory that is probably holding onto something sizable
<clever> m`: can you pastebin the results?
<clever> yep
<clever> sphalerite: yeah, for when the ssh server has stopped responding
<clever> i havent looked into solving that issue yet in the script, it improperly shuts the host down, in the middle of you using ssh, so its a bit tricky to get out
<clever> gchristensen: oh, another thing thats massively usefull, <enter>~. will make the linux ssh client hang up instantly
<clever> ive only used lvm and zfs for multi-disk arrays
<clever> no idea, havent tried mdadm
<clever> and i have 5gig free
<clever> the issue, is that i'm testing something that involves building 300-400mb tarballs
<clever> MichaelRaskin: zfs, had to delete 3 snapshots to get gc to run
<clever> error: could not set permissions on ‘/nix/var/nix/profiles/per-user’ to 1777: No space left on device
<clever> [root@amd-nixos:~/nixcfg]# nix-collect-garbage
<clever> gchristensen: out of disk space, during a kexec test
<clever> gchristensen: eeek!
<clever> then nixops can run it with the correct args, over ssh
<clever> but it could be modified to take arguments, like --authorized_keys=/ssh_pubkey
<clever> right now, it just assumes the file already exists on the host
<clever> cat /ssh_pubkey >> authorized_keys
<clever> somebody with more bash skillz could add arguments to the kexec script
<clever> gchristensen: you could even have hydra pre-build the tar, and it could be used as-is
<clever> gchristensen: so multiple people could reuse the same tar, and still control who gains root
<clever> gchristensen: this time around, i created a /ssh_pubkey file on the host, before running the kexec script, and it used that to authorize ssh
<clever> sheenobu: i recently wanted to fix a bug in my custom android app for my thermostat system, it took an hour just to find the source (last-mod times in 2013), and then another hour to remember how to build it
<clever> sheenobu: heh, ouch
<clever> sphalerite: <nixpkgs/foo> will keep checking each nixpkgs it can find, until it comes across one that has a foo in the root, while <nixpkgs>/foo will pick the first one, then just blindly append /foo to the end
<clever> sphalerite: there is also a difference between <nixpkgs>/foo and <nixpkgs/foo>
<clever> gchristensen: let me see if i can modify it to rebuild with the ssh keys faster
<clever> Dezgeg: ah, thats easy
<clever> gchristensen: yeah
<clever> not sure how to just tell it to use it all
<clever> Dezgeg: in the above script, it makes the partition 1.5gig
<clever> gchristensen: you should be able to paste it into here, and then just make a systemd unit to spit status out over http maybe?, and do a real reboot at the end
<clever> Dezgeg: main issue i ran into with sfdisk, is making it fill the entire disk up automaticaly
<clever> gchristensen: heh, i didnt think fdisk would be happy with echo on stdin
<clever> Fare: builtins.listToAttrs
<clever> Fare: :r to reload all files
<clever> [root@router:~]# nix-instantiate --eval -E '<nixpkgs>'
<clever> /nix/store/5gkbjsjsnb4w1dhybf1vn7a245vyxxy5-nixos-16.03pre76756.885acea/nixos/nixpkgs
<clever> sheenobu: it turns into 2 atomic operations, and the 1st isnt undone in the event of the 2nd failing
<clever> sheenobu: the only thing --upgrade does, is run "nix-channel --update" first, which sort of makes the whole "nixos-rebuild --upgrade switch" non-atomic
<clever> sheenobu: you insert the libs, and then run nix-build, and it creates a shell script that will just patch it
<clever> sheenobu: here is a tool i wrote to simplify patchelf a while back: https://gist.github.com/cleverca22/fcd3e6d18073804b9357a26c468aaa70
<clever> hokoJU: id try the 2nd command then, that should get you some more
<clever> hokuJU: start by seeing how much you can save by running nix-collect-garbage, and then consider deleting older generations, like "nix-collect-garbage --delete-older-than 30d"
<clever> Fare: throw "foo"
<clever> hokuJU: start by seeing how much you can save by running nix-collect-garbage, and then consider deleting older generations, like "nix-collect-garbage --delete-older-than 30d"
<clever> Fare: nix-repl
<clever> c0bw3b: the fetchurl inside nghttp2 uses a different build of curl
<clever> c0bw3b: which does have a small override on it
<clever> c0bw3b: https://gist.github.com/cleverca22/47e1d60442f06a75a3d84cb747a9314b a quick check shows that curl depends on the unmodified nghttp2 that is present in top-level
<clever> c0bw3b: yeah
<clever> c0bw3b: so somebody has to make an override that sets it to null to actualy disable it
<clever> c0bw3b: callPackage will always specificy the optional things
<clever> LnL: it is a bit odd for nixpkgs to be filed under misc
<clever> vanrein: if you install directly to usb, then you wont loose everything upon reboot, and you can add tools you often use at install and they stay
<clever> vanrein: it is also possible to build a custom livecd that just has zfs by default, but i find it more powerfull to just point nixos-install at a usb stick
<clever> vanrein: then you can see the install on the hdd and mount it
<clever> vanrein: you need to re-add zfs to boot.supportedFilesystems, on the livecd's config, then nixos-rebuild switch
<clever> vanrein: yeah, the livecd has its own config
<clever> vanrein: nixos wont import all pools on bootup, it only imports the pools listed in the active configuration.nix
<clever> hodapp: dell d630, Core(TM)2 Duo 1.8ghz, 3gig of ram
<clever> viric__: 53.0.2785.143
<clever> hodapp: i have it running on my laptop without issue
<clever> viric__: and chromium cant render the about page
<clever> and if i hit call, i can see myself twice
<clever> then i can see myself
<clever> viric__: in chromium, i had to allow the camera first
<clever> firefox 49.02 "nightly" from nixos-unstable
<clever> viric__: complete failure on firefox, let me find chrome
<clever> hokoJU: yeah, and the channel should be called nixos
<clever> hokoJU: pretty sure everybody should be switching to 16.09 now
<clever> i'll need to add a note to my readme
<clever> gchristensen: yeah
<clever> gchristensen: ah, i filed a PR for that, which nix channel did you build from?
<clever> LnL: heh, and youve proven me wrong, just a couple hours ago, i said i was probably the only one to be using the module framework outside of nixos
<clever> hokuJU: in ~/Downloads, but once the PR kmicu linked hits the channel, the problem will be fixed
<clever> hokuJU: i think you can just rename this to hybrid-v35_64-nodebug-pcoem-6.30.223.271.tar.gz and then nix-store --add-fixed sha256 it
<clever> but it wont register it as valid, so next time you rebuild, it will try to download it again
<clever> hokuJU: and also, nix leaves the invalid file behind after failures like this, so you can debug it
<clever> and all nix knows, is that the hash is wrong
<clever> so broadcom hasnt actualy modified the tar, they just took it down
<clever> hokuJU: if you run "file" on that path, it will probably say html
<clever> hokuJU: ah, sounds like it 404'd
<clever> hokuJU: how large is it?
<clever> hokuJU: find it somewhere on google. and then nix-store --add-fixed sha256 ~/Download/hybrid-v35_64-nodebug-pcoem-6.30.223.271.tar.gz
<clever> hokuJU: so broadcom has changed the tar, without telling anybody
<clever> hokuJU: it appears to be the broadcom wifi drivers
<clever> hokuJU: the upstream source changed the contents of that tar
<clever> clever@c2d ~ $ head -n32 /nix/store/5n59fpmkjna4gfcnjh5b0kpgn4vnpvkq-nixpkgs-17.03pre96825.497e6d2/nixpkgs/pkgs/top-level/all-packages.nix | tail -n1 callPackage = newScope {};
<clever> { column = 3; file = "/nix/store/5n59fpmkjna4gfcnjh5b0kpgn4vnpvkq-nixpkgs-17.03pre96825.497e6d2/nixpkgs/pkgs/top-level/all-packages.nix"; line = 32; }
<clever> clever@c2d ~ $ nix-instantiate --eval -E 'with import <nixpkgs> {}; __unsafeGetAttrPos "callPackage" pkgs'
<clever> angerman: but some things like fetchurl are special, and you cant fetchurl.meta
<clever> angerman: there is also just hello.meta.position that tells you where hello came from
<clever> Profpatsch: yeah, in the 2015 example, the location of mkDerivation from the stdenv
<clever> { column = 3; file = "/nix/store/5n59fpmkjna4gfcnjh5b0kpgn4vnpvkq-nixpkgs-17.03pre96825.497e6d2/nixpkgs/pkgs/top-level/all-packages.nix"; line = 13325; }
<clever> clever@c2d ~ $ nix-instantiate --eval -E 'with import <nixpkgs> {}; __unsafeGetAttrPos "hello" pkgs'
<clever> lol
<clever> bit different from how i usualy use it
<clever> 2015-11-01 10:17:17< bennofs> Profpatsch: oh, I've just found out that nix has a builtins.unsafeGetAttrPos function: nix-instantiate --eval -E 'builtins.unsafeGetAttrPos "mkDerivation" (import <nixpkgs> {}).stdenv'
<clever> angerman: i believe it used nix-instantiate
<clever> angerman: nix-prefetch-git and fetchgit
<clever> yeah, the livecd doesnt save anything, so its all reset to defaults after a reboot
<clever> you can manualy systemctl start zed once the module is loaded
<clever> vanrein: thats a bug in nixos, it tries to start zed before loading the module
<clever> its usualy better if the channel isnt updated first, because the kernel version has to match the module
<clever> vanrein: nix-env will never work with kernel modules, they have to go into /etc/nixos/configuration.nix
<clever> and the extra/zfs entry is a symlink, from the "all modules" package to the zfs package
<clever> lrwxrwxrwx 1 root root 98 Dec 31 1969 /run/current-system/kernel-modules/lib/modules/4.4.30/extra/zfs -> /nix/store/ribhzzwc4jk624w3gvrmm0lrm7mn98y5-zfs-kernel-0.6.5.8-4.4.30/lib/modules/4.4.30/extra/zfs
<clever> vanrein: this is where i find the zfs module
<clever> filename: /run/current-system/kernel-modules/lib/modules/4.4.30/extra/zfs/zfs.ko.xz
<clever> [clever@amd-nixos:/media/videos/4tb/dcc]$ modinfo zfs
<clever> vanrein: did you do anythign with nix-channel before the nixos-rebuild?
<clever> nix-channel --update can break things though, did you run that at any time?
<clever> vanrein: you need to set boot.supportedFilesystems = [ "zfs" ]; and run rebuild-switch on the livecd
<clever> srhb: and if copy-closure is in the mix, you should also be able to use nix-env -p /nix/var/nix/profiles/per-user/root/rpi3-netboot --set /nix/store/93pacv7s9k0fm2d497c6cd1j0g95vxrq-rpi_image
<clever> srhb: the reason ive been wanting to go this way, is that i now gain nix-env --rollback, so i can revert changes without having to revert the nix expressions first
<clever> srhb: this will built the rpi_image attribute of release.nix, and then set the rpi3-netboot profile to the resulting storepath, no -i or -e stuff to merge things
<clever> srhb: [root@router:/tftproot/try2]# nix-env -p /nix/var/nix/profiles/per-user/root/rpi3-netboot -f not-os/release.nix -A rpi_image -I nixpkgs=./nixpkgs/ --set
<clever> let me pull up the man page and finish that idea up
<clever> srhb: i have recently considered using nix-env to manage some network booting servers
<clever> and i think i'm the only person to have reused that module framework to create something that is not nixos
<clever> dont think ive seen it documented anywhere
<clever> { packages, config, ...}: {
<clever> would become
<clever> packages: {config, ...}: {
<clever> joepie91: that is an internal part of the nixos module framework, that adds options to the { config, ... }: area
<clever> pikajude: using the crossDrv stuff, it probably could, but it would rely on package maintainers correctly using nativeBuildInputs and buildInputs
<clever> and merge it into the existing attrset
<clever> _module.args.packages = packages; would do the same thing
<clever> then you wont need 2 lambda's in every file
<clever> maybe you want _module.args.foo, then you can just do { foo, pkgs, config, ... }: at the top
<clever> oh wait, those are in imports ....
<clever> joepie91: it would let you create a bunch of packages, that are able to self-reference, and can be loaded via callPackage
<clever> pikajude: but the user had imported nixpkgs again, and half the derivations didnt do that
<clever> pikajude: that setup was just using linux build slaves, not a proper cross-compile
<clever> joepie91: pkgs.newScope self; creates a new instance of callPackage, and then for each argument in a given file, it will try self.arg, then pkgs.arg
<clever> and pulling up an example
<clever> joepie91: looks like you may wanto to look into how newScope and callPackage work
<clever> this is why you can access pkgs from that top level
<clever> _module.args.pkgs is a special config within the module framework, that adds an argument to all modules
<clever> yeah
<clever> in the mac case, the 2nd instance of nixpkgs defaulted to darwin, and now he has mach-o binaries in the systemd service on a linux server
<clever> and i have helped other users who did the above while cross-compiling mac->linux for nixops
<clever> i have read the source behind how nixos loads nixpkgs repeatedly
<clever> ah, close!
<clever> import <nixpkgs> { config = config.nixpkgs.config; } will fix that
<clever> it uses /root/.nixpkgs/config.nix
<clever> and because you didnt specify the config argument, that doesnt use nixpkgs.config
<clever> my guess, is that you have an import <nixpkgs> somewhere
<clever> joepie91: can you gist your configuration.nix file?
<clever> k11`: out of ideas and i need sleep, nearing 24 hours uptime
<clever> sheenobu: the cache.nixos.org url's are NAR files, which need to be unpacked to the correct location in /nix/store, so nix-prefetch-url wont like them
<clever> but nix builds sometimes cheat and use tarballs.nixos.org
<clever> it shouldnt
<clever> sheenobu: one of the plugin options causes a recompile
<clever> and thats WITH dynamic linking
<clever> sheenobu: the correct statement is, ech chromium is a bloody 179mb binary
<clever> -r-xr-xr-x 1 root root 179M Dec 31 1969 /nix/store/f6r0xahj842q7b2kkg4rlcjnxl8a1lw6-chromium-53.0.2785.143/libexec/chromium/chromium

2016-12-10

<clever> k11`: or the ram?
<clever> k11`: my only guess is that maybe the hdd is going tits up?
<clever> every time you eval the nix expression, it will re-import that directory, and if it has changed, it will rebuild things
<clever> Sirolu: src = ./.;
<clever> you can if you think the hardware config needs to be updated
<clever> k11`: and then restore /etc/nixos/
<clever> k11`: i would rename it, since the corrupt etc stuff was making a mess there
<clever> k11`: then you should be safe to just rm -rf /mnt/old-nix
<clever> k11`: was there anything of value in things like "nix-env -q"?
<clever> k11`: exit out of the chroot, and rename /mnt/nix to /mnt/old-nix, then just run nixos-install and it will recreate all of /nix from the configuration.nix you already have
<clever> k11`: might cut it a bit close, but i have an idea on how to rescue it with less data loss, what livecd are you using?
<clever> k11`: oh, how much free disk space is there?
<clever> is 179 a generation that can boot?
<clever> yeah, thats a bit strange, but should be safe to ignore
<clever> k11`: then rollback again
<clever> k11`: /nix/var/nix/profiles/system should now point to a different number, what is it?
<clever> k11`: try "nixos-rebuild --rollback boot"
<clever> k11`: it will try to restart services and stuff, which will be upset from the chroot
<clever> k11`: switch must never be used under a chroot
<clever> k11`: we can still recover it
<clever> k11`: what did the above command say?
<clever> k11`: ok, start by doing nixos-rebuild --rollback
<clever> k11`: the correct answer is a number, not a boolean
<clever> k11`: and which generation is system pointed to?
<clever> k11`: what generation does the /nix/var/nix/profiles/system symlink point to, and are you still going thru /mnt, a chroot, or booted into another generation?
<clever> k11`: what is the output of "realpath /nix/var/nix/profiles/system-181-link/etc" ?
<clever> k11`: its possible that the system was malfunctioning during the nixos-rebuild, so that generation is toasted and the hashes say its fine
<clever> k11`: it should be possible to recover without a reinstall, can you pastebin the output of `nix-store --verify --check-contents`
<clever> k11`: it looks like that generation of nixos is tottally corrupt, what was the outcome of nix-store --verify --check-contents --repair ?
<clever> including the compiler
<clever> LnL: yeah, everything uses setup.sh
<clever> k11`: this is not normal
<clever> lrwxrwxrwx 1 root root 63 Jan 1 1970 dhcpcd.exit-hook -> /nix/store/vpyf34anbwgnj1a3p10nnxc2vyazzlk2-ca-certificates.crt
<clever> k11`: something looks horribly wrong here...
<clever> lrwxrwxrwx 1 root root 55 Jan 1 1970 locale.conf -> /nix/store/hl6q6cy09zbha8q9qv969s18n3xaddav-usermod.pam
<clever> k11`: looking over the pastes
<clever> and runHook supports bash arrays, so there can be several
<clever> runHook is seperate, and is normaly used by the phase itself, to do pre/post hooks
<clever> yes, its ugly and not user friendly
<clever> LnL: this will either run the bash function, or eval the chunk of bash in a variable of the same name
<clever> LnL: yes
<clever> one min
<clever> k11`: and ls -ltrhR ls /nix/var/nix/profiles/system-<foo>-link/etc/ for the generation that wont boot
<clever> k11`: can you pastebin the result of ls -ltrhR /etc/ ?
<clever> k11`: upload to imgur and i can take a look
<clever> k11`: what paths is it saying are broken?, can you pastebin all of the console output?
<clever> fpletz: sounds good here too
<clever> gchristensen: does the hosting provider offer a rescue shell, or other distros?
<clever> k11`: there are some changes that cant be done online, and test/switch do them, boot is sometimes safer
<clever> k11`: "something" ?
<clever> sphalerite: the current nixos modules set everything to :0, so it will likely get upset when things start to run on :1
<clever> k11`: did you try "nixos-rebuild boot" ?
<clever> kmicu: what error happens on bootup?
<clever> sphalerite: not currently
<clever> gchristensen: now my script uses the fixed kexec, but systemd used the broken kexec (and wont mass-rebuild)
<clever> gchristensen: let me push it to that repo
<clever> gchristensen: oh, i have a thought, a faster way
<clever> gchristensen: oh, and kill the override on 42 also, systemd still references it
<clever> gchristensen: just kill this line and it should fallback to the kexec on the host: https://github.com/cleverca22/nix-tests/blob/master/kexec/configuration.nix#L22
<clever> gchristensen: apt-get may help there
<clever> gchristensen: if the host already has kexec in $PATH, you can use that
<clever> the hash will be world readable, but it should be hard to brute-force, so you basicaly only loose /etc/shadow
<clever> sphalerite: initialPasswordHash
<clever> kmicu, LnL: what are your opinions on hardeningDisable = [ "all" ]; in kexectools?
<clever> gchristensen: i'm a bit iffy about just blanket disabling the hardening in gcc, but its a tool that only root will ever use, and it just does nothing without root
<clever> because it says release, it must be the stable one!
<clever> but that poor naming leads to people using the wrong release-16.09 anyways
<clever> LnL: i think its because the release-16.09 and release-16.09 branches collide (one is to push security to 16.09 and let hydra test, the other is the real channel)
<clever> gchristensen: i need to file that PR and get hydra to help out
<clever> gchristensen: it has to rebuild kexectools to fix a bug caused by hardening, and systemd depends on kexec, and util-linux depends on systemd, and half the os depends on util-linux
<clever> gchristensen: i would have just made it branches on the main nixpkgs
<clever> rotaerk: the -small channels are ones that have only passed testing, the non-small channels have had hydra attempt to build every single package in nixpkgs
<clever> rotaerk: the nixos channels are versions of nixpkgs that have passed all nixos tests, and probably wont brick a nixos machine
<clever> LnL: so you need lan or serial console
<clever> LnL: yep, but the GPU breaks when you kexec
<clever> LnL: yeah, if kexec is enabled in the kernel and you have root, you can now format the box and install nixos properly
<clever> LnL: in theory, it could also be added to nixops, and can target any hoster that obeys the MBR
<clever> LnL: i have some thoughts on how to better integrate the ssh public key stuff, so it needs less rebuilding
<clever> gchristensen: and then run the 1st command in session.md
<clever> and any other things you may want in the ramdisk
<clever> gchristensen: https://github.com/cleverca22/nix-tests/tree/master/kexec clone this on pretty much any machine with nix, and then edit the configuration.nix to have your ssh pubkey
<clever> gchristensen: pong
<clever> xwvvvvwx: the fixupPhase on line 61-68 handles the patchelf'ing
<clever> ale-batt: you generaly never install tools like make on nixos, you use nix-shell
<clever> and to make debuging more fun, the STB's cheat for the first 30 seconds, they stream over tcp, to make it tune faster, then switch to multicast as the igmp kicks into gear
<clever> but i have never gotten nixos to route the multicast traffic from WAN->LAN correctly
<clever> i did manage to configure nixos to handle both vlans, and i reverse engineered the routing tables in the ISP router (i put a linux box on both the wan and lan ports, and just brute-forced it)
<clever> and i believe bare dhcp+ipv4 (in the 10.0.0.0) + multicast for the tv vlan
<clever> my isp has bare dhcp and ipv4 over the internet vlan
<clever> so nfs and ssh are entirely useless from a laptop
<clever> nathan7: and my isp router is horid, there is no way to turn the wifi<->wired isolation off
<clever> nathan7: the fiber modem spits out 802.1q tagged packets, 1 vlan for the internet, 1 vlan for the tv service (where the multicast happens)
<clever> nathan7: every tv channel is its own multicast group
<clever> nathan7: my ISP does phone+tv+internet over the same fiber network
<clever> nathan7: heh, in my case its over a controled private network
<clever> nathan7: you ever get to play with multicast?
<clever> everything else is just regular consumer desktops, mostly old crap
<clever> it came out of an xray machine
<clever> my router is a dual-processor server with 3gig of ecc ram, it runs hydra and does NAT for the house
<clever> the most i have here is fiber internet
<clever> heh
<clever> nathan7: ah, mine is scattered over a couple consumer desktops, and 1 old server grade box
<clever> heh, i dont really have any hypervisors active on my LAN
<clever> nathan7: i have a feeling that i could probably arp poison the switches in that datacenter...
<clever> i fixed it by having dhcpcd renew the leasse, and it got a public ip
<clever> nathan7: and the help line wasnt able to figure out what was wrong
<clever> nathan7: so the dhcp server derped and gave my server a private ip, which somehow worked (they must have configured it to allow both)
<clever> nathan7: and with some more proding via another server in the same datacenter, i discovered that it shared a broadcast domain with things that had public IP's
<clever> nathan7: and further investigating, revealed it had a 172.16.0.0/20 ip address
<clever> nathan7: this also reminds me of a datacenter i once used in costa rica, one day the server just went down, but i could still reach it over the vpn
<clever> so when you change the elastic ip, the box's ip doesnt have to change
<clever> nathan7: and that reminds me, ec2 doesnt actualy put the public ip on the box, i think they always get a private ip, and something else sort of does 1 to 1 NAT
<clever> ah
<clever> nathan7: floating ip's?
<clever> nathan7: but i feel that the tarball idea is much cleaner, nixos isrunning from a ramdisk, so you are free to format the hdd and do a clean install
<clever> nathan7: i'm sort of responsible for nixos-in-place, it was written after i told somebody about how i mutated my gentoo netbook into nixos, lol