2016-12-10

<clever> nathan7: ah, that sounds much better
<clever> AWS has something similar, after you get an ip via dhcp
<clever> ah, nice
<clever> or is it doing something funny to get the ip's?
<clever> nathan7: ah, that would work for the main os, but not for the tar idea, the tar'd nixos will have to mount a 2nd rootfs (the real one) and steal the file out of the host
<clever> nathan7: and nixos doesnt obey that file, so networking doesnt come up
<clever> nathan7: from things ive read online, DO will edit /etc/network/interfaces when you snapshot a vm and spawn a new copy of it
<clever> so every tar is locked to a single ip
<clever> nathan7: main limitation with DO is the static ip mess, you would need to embed the ip into the configuration.nix
<clever> nathan7: nice
<clever> nathan7: but what if an aarch64 build of this was made?
<clever> nathan7: yep, that is one use for it
<clever> nathan7: you can then scp that tar to any linux server, and execute it, and boom, nixos is running from a ramdisk
<clever> nathan7: this compiles with to a tarball containing the closure of kexec, and a kernel+initrd, and a bash script
<clever> nathan7: that reminds me, let me grab the link
<clever> nathan7: ive booted nixos systems before with only /nix/store mounted, and / 100% empty
<clever> nathan7: the bash script in the initrd creates that on bootup
<clever> /home/clever/apps/nixpkgs/nixos/modules/system/boot/stage-1-init.sh: touch "$root/etc/NIXOS"
<clever> k11`: moving that back is optional, it can boot without /etc/nixos, but yeah, you will want to restore configuration.nix at some point
<clever> nathan7: due to funky designs in the V3D stuff, it behaves more like 192 cores
<clever> nathan7: the rpi3 has 4 arm cores (64bit capable), 2 VC4 cores (no mmu, normaly runs an rtos called threadx), and 12 V3D cores (the shaders)
<clever> nathan7: it doesnt have to actualy implement gpu things, you can just ignore all the gpu features and treat it as a dedicated hypervisor core
<clever> k11`: ah, nixos is capable of fully recreating /etc on bootup, so try just renaming /etc from the installer and reboot
<clever> k11`: are the things in question symlinks or directories?
<clever> nathan7: i believe it has no effect on the VC4 cores, so an open source gpu firmware can just turn such a thing off, it to setup an open-source hypervisor on another core
<clever> nathan7: but if used correctly, the gpu firmware will block the arm from having access
<clever> nathan7: its just a normal memory mapped IO register, that all cores (gpu and arm) have access to
<clever> nathan7: this can allow the gpu firmware to lock out sections of ram and control registers, so you can protect keys from the arm cpu
<clever> nathan7: there is a 2nd MMU layer, between what the arm thinks is physical, and the real ram
<clever> nathan7: there are also some interesting features on the rpi from a security point of view
<clever> nathan7: but the above github is an open-source implementation of everything after the bootrom
<clever> nathan7: yep, a boot rom on the VC4 dual-proc chip is what bootstraps the system
<clever> nathan7: ? lol
<clever> in theory, proper UEFI support could be added to it
<clever> nathan7: there is some work being done on open-source firmware for the rpi: https://github.com/christinaa/rpi-open-firmware
<clever> k11`: yeah, nixos-install --chroot or just run nixos-install with everything mounted to re-build from configuration.nix
<clever> fpletz: then you have tgt-admin, a perl script that can read targets.conf, run tgtadm, and configures everything
<clever> fpletz: tgtd is the daemon, it doesnt support any config files and comes up blank, tgtadm is a remote-control to alter things in the daemon, it also has no config files
<clever> fpletz: and tgt is a bit confusing, there are 3 parts to it
<clever> fpletz: let me pastebin a tgtd config file
<clever> fpletz: for a 64bit os on arm, thats less likely to happen, since the bit sizes all match up, but i still like how iscsi works
<clever> fpletz: half of the programs in nixos claim file not found when EOVERFLOW happens, because they dont handle errors correctly
<clever> fpletz: and half of nixos isnt built with that 64bit compat enabled
<clever> fpletz: so stat() with its 32bit fields returns EOVERFLOW, but stat64 works
<clever> fpletz: 32bit os on the rpi, 64bit inodes over nfs because of xfs
<clever> fpletz: failed horribly on my rpi
<clever> gchristensen: i configured it to retoute the hdd to iscsi
<clever> gchristensen: for x86, there is ipxe, which can hijack the legacy bios calls for reading the local hdd
<clever> and i did have a pair of rpi1's booting with the rootfs on iscsi, and /boot on the SD card
<clever> my laptop is booting nixos from pure iscsi (including grub in the iscsi MBR)
<clever> and it could be lvm, so gchristensen doesnt have to dedicate an entire drive
<clever> that then lets you back it by any hdd you want, on any machine in the LAN
<clever> fpletz: tgtd is the server i used
<clever> fpletz: this allows you to just connect to a iscsi target without having to configure anything on the client
<clever> fpletz: ${pkgs.openiscsi.iscsistart}/bin/iscsistart -t ${dev.iscsi.lun} -a ${dev.iscsi.host} -i ${config.boot.initrd.iscsi.initiatorName} -g 0
<clever> gchristensen: another option that ive done on this end, iscsi
<clever> fpletz: my main thought for the above, was to get a quick&dirty build slave up, that can double the speed at which i build proper nixos (2 rpi's working together)
<clever> and mount everything up like you would for any chroot
<clever> k11`: but the main thing to keep in mind, is that /nix/var/nix/profiles/system/sw/bin has to be in $PATH
<clever> k11`: there is a nixos-install --chroot command
<clever> fpletz: and then just because i could, i added plymouth to it, lol
<clever> fpletz: mainly, i added ntp to solve some jan 1st issues, made the store writable via overlayfs, and added dhcp to the initrd to tftp the rootfs
<clever> fpletz: yeah, not-os, ive done some fairly large changes recently that i havent had a chance to clean up and push
<clever> fpletz: i have a nix expression here, that generates a kernel, initrd, and root.squashfs, which boots a rpi3 into a 40mb ramdisk, that is capable of doing nix builds
<clever> yonk: so you need to use -A with them
<clever> yonk: all of those are attribute paths, not names
<clever> yonk: man-pages posix_man_pages stdmanpages
<clever> git does the same thing to its main index file a lot
<clever> and then ash cant edit his own config files
<clever> without that, vim will be editing ash's files as root, and files will randomly become owned by root
<clever> hence why i always say to use sudoedit
<clever> which should make the problem less likely
<clever> rather then what root has
<clever> that means it will use what ash has nix-env -i'd
<clever> ashkitten: what about TERMINFO_DIRS
<clever> ashkitten: maybe compare the output of "sudo -E env", "sudo -i ; env", and just env without any root
<clever> ashkitten: you will need to review the list in "nix-env -q" and figure out what is fixing the problem, then add that globally
<clever> whatever you installed as to ash's profile to fix it originally
<clever> its possibly the same ~/.nix-profile stuff, need to install things globaly not per-user
<clever> so it uses config from the correct home, and wont cause root to own your config files and bork stuff
<clever> yours runs the editor as root, mine copies the file to /tmp, runs the editor without root privs, and upon exit, copies the file back
<clever> ashkitten: EDITOR=vim sudoedit /etc/nixos/configuration.nix
<clever> Fare: there is a way to do package overrides like that, and the haskell overrides have been doing it for a while
<clever> osa1: i think i moved it to .bashrc after the installed added it to .profile
<clever> this is in my .bashrc on my gentoo machine
<clever> if [ -e /home/clever/.nix-profile/etc/profile.d/nix.sh ]; then . /home/clever/.nix-profile/etc/profile.d/nix.sh; fi # added by Nix installer
<clever> ashkitten: no idea, i havent done much work with terminfo stuff
<clever> osa1: the script in ~/.nix-profile/etc/profile.d/nix.sh should do that for you
<clever> osa1: another option is to just install it to /nix normally, then move it over and add the bind mount
<clever> osa1: dont think you need to
<clever> osa1: sounds more like a network error to me, but you can try the bind-mount Dezgeg sudjested, rm /nix; mkdir /nix; mount --bind /home/user/nix /nix
<clever> Dezgeg: i found a recent bug in nixpkgs, it wants config.platform to be a lambda now, there isnt enough () around the change in top-level/default.nix dealing with platform
<clever> ashkitten: yeah, thats what tripped me up and lead to the wrong path
<clever> ashkitten: oh oops, was thinking of urxvt
<clever> osa1: export NIX_IGNORE_SYMLINK_STORE=1
<clever> ashkitten: and its in /home/ash/.nix-profile/share/terminfo/u/ ?
<clever> ashkitten: thats probably the issue then, did you nixos-rebuild after adding it to systemPackages?
<clever> ashkitten: does it show up in /run/current-system/sw/share/terminfo/u/ ?
<clever> ashkitten: either nix-env -i it as root, or put it into systemPackages
<clever> ashkitten: the xrvt stuff is probably in /home/ash/.nix-profile, so root cant find it
<clever> osa1: if you have write to /home/user/nix, sure
<clever> ashkitten: did you install rxvt with nix-env?
<clever> osa1: you can make a symlink from /nix to /home/user/nix
<clever> there is no point in mixing different tools that do the same thing
<clever> ashkitten: i always use sudo -i
<clever> yes
<clever> ale-batt: nixos wants to control all files in /etc, users.users.clever.extraGroups = [ "wheel" ]; will add me to the wheel group automaticaly
<clever> ashkitten: what does this command output: realpath /home/ash/.nix-defexpr/channels_root/nixos
<clever> ashkitten: you already had a channel on root called nixos, so you didnt need to add any channels to ash, nix-channel --remove nixpkgs
<clever> ashkitten: paste the exact error/warning message
<clever> angerman: it exposes things like the path to nixpkgs that your not really meant to use in nix expressions
<clever> there are 2 different areas where nix-env can give that kind of error
<clever> ashkitten: i need to see more information on what is colliding
<clever> angerman: that is the function used to make .meta.position work on every derivation
<clever> "/nix/store/k984k6xncihdsiajy99wk82gn3zhhy7x-nixos-17.03pre95306.a24728f/nixos/pkgs/applications/misc/hello/default.nix:14"
<clever> nix-repl> hello.meta.position
<clever> angerman: yep
<clever> ashkitten: there is a gist command in nix, or nixpaste can do it purely with stock tools, $ <command> | curl -F 'text=<-' http://nixpaste.lbr.uno
<clever> angerman: http://pastebin.com/aRcuQhyp this tells you where pkgs.fetchurl comes from, reading that line gives the path to fetchurl/default.nix
<clever> including the command you ran
<clever> ashkitten: can you pastebin the start of the output when you run nix-env?
<clever> angerman: i memorized its location in nixpkgs after reading the a decent chunk of it.....
<clever> angerman: i generaly find the source to be the best documentation for most things: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchurl/default.nix#L38-L80
<clever> ashkitten: the channels are setup to only update once hydra has built everything
<clever> ashkitten: http://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.chromium.x86_64-linux looks like hydra failed to build chromium 55 on master
<clever> toogley: alt+f8 i believe
<clever> if your not on nixos
<clever> ashkitten: nix-channel --add https://nixos.org/channels/nixpkgs-unstable nixpkgs
<clever> ashkitten: building from nixpkgs master?
<clever> ashkitten: there should be a pre-built copy on hydra, which channel are you on?
<clever> ashkitten: is this from nix-env, nixos-rebuild, or nixos-install?
<clever> ashkitten: 32 or 64bit?, have you changed any nixpkgs config options?
<clever> and it would take up at least 80gig of your hdd
<clever> it would be near imposible to get it to not conflict
<clever> you would still need to manualy put in each package you want
<clever> you can break the config up over many files, and have one for the config like stuff, and one for packages
<clever> Cinnamon811rc: it would be a bit insane to install all packages, there are over 10,000 of them
<clever> all packages?
<clever> xfce4-settings-manager
<clever> yes
<clever> i use xfce on all of my systems
<clever> probably one of the files update-grub reads
<clever> aptosid's grub config
<clever> and once you have the exact command, you can add it to the proper grub.cfg
<clever> yeah
<clever> so you can poke around and find it with that
<clever> and it does have tab-completion
<clever> Cinnamon811rc: the simplest test is to hit c at the grub menu, then try typing "source (hd0,0)/boot/grub.cfg"
<clever> i'm a bit fuzzy on the hdd half of things, but you can test it without editing files
<clever> Cinnamon811rc: yes
<clever> but you need to know what the hdd path is, so you may want to play with the grub command line first (hit c at grub)
<clever> Cinnamon811rc: so you can do soemthing like source (hd0,0)/boot/grub.cfg to load the nixos grub config into the other one
<clever> Cinnamon811rc: there is a command in grub, that will read another config file
<clever> so you need to source the generated grub.cfg file from the other one
<clever> but it will break again the next time you do any changes to configuration.nix
<clever> Cinnamon811rc: when i did something similar, i used the source command in grub, to load the nixos grub.conf file from the other grub.conf file
<clever> Cinnamon811rc: and if you dont sync that config up properly, it will undo all changes upon reboot
<clever> Cinnamon811rc: nixos needs to update the bootloader config every time you do a nixos-rebuild
<clever> Cinnamon811rc: ah maybe its jut lag
<clever> Cinnamon811rc: ctrl+q, though you may not see it
<clever> Cinnamon811rc: is /boot mounted correctly?
<clever> all -p does is insert it into a runCommand similar to what i had typed
<clever> oh, that might work with -p, nix-shell -p '(pkgs.callPackage ./default.nix {})'
<clever> angerman: so maybe 'with import <nixpkgs> {}; runCommand "dummy" { buildInputs = [ (callPackage ./default.nix {}) ]; } ""'
<clever> angerman: it needs to be a derivation that has the ghc in buildInputs
<clever> angerman: oops, wrong a name
<clever> ale-batt: make a new nix file, that has that ghc in buildInputs, and run nix-shell on it
<clever> bit hard to read the --tree when every single fetchurl depends on curl, but has been fixed-derivation'd out of the equation
<clever> perl, python
<clever> but anything that links to libcurl still has to rebuild
<clever> fixed-output derivations will stop things from spreading thru fetchurl
<clever> curl depends on nghttp2
<clever> and this will show the build-time dependency tree for everything
<clever> [root@amd-nixos:~]# nix-store --query --tree /nix/store/xhj44wkk6lc7l4zlclk307npx5j49vax-nixos-system-amd-nixos-17.03pre95306.a24728f.drv
<clever> this will spit out the .drv file for my entire nixos build
<clever> [root@amd-nixos:~]# nix-instantiate '<nixpkgs/nixos>' -A config.system.build.toplevel
<clever> ive been using xfce ever since gnome3 ruined gnome
<clever> ah
<clever> ale-batt: i cant see what has caused that to change though
<clever> so its stuck on
<clever> ale-batt: aha, somebody set CONFIG_MOUSE_PS2_SYNAPTICS=y in the kernel config
<clever> and it happens to have 2 mice, the joystick in the keyboard is un-affected
<clever> ive got the same issue on my laptop, but i almost exclusively use an external mouse
<clever> hmmm, dont see that on my laptop
<clever> ale-batt: there should be a kernel module by the same name, that turns it into a touch screen if you lack the xserver half
<clever> ale-batt: i never liked how the synaptics driver behaves, and it may help to turn off the matching kernel driver
<clever> newNixos: any progress on the linode server?
<clever> lol
<clever> but 8 days ago, it died in the middle of a snow storm
<clever> i only loose the power once or twice a year
<clever> but it doesnt even host cacti, it proxy's it onward
<clever> hmmm, cacti still goes thru it
<clever> the bios battery in that box has also died, so it needs an f1 every time it comes back from a power outage
<clever> one of the servers i need to retire did my personal website, but ive already migrated 90% of the stuff out, i need to see whats even reaching it still
<clever> some of that code pre-dates my exposure to linux
<clever> its been running for over a decade now...
<clever> but i still keep it up, lol
<clever> i'm not sure if anybody is even using that service now
<clever> the last mobo failure killed off the xp server, and now its running on win7 in a domu
<clever> but over the years, various hardware failures have pushed it to newer and newer versions of windows
<clever> it originaly ran on a win95 laptop, lol
<clever> the only personal thing running outside of the house is a windows vm for some stuff i wrote in 2004 and am heavily neglecting
<clever> i have ~4 servers in my house, lol
<clever> ive got most of those private things on local boxes, but i need to merge things
<clever> ah
<clever> and xen has a memory leak in its qemu, so it needs 64bit of swap and bi-yearly reboots of the guests
<clever> ah, similar mess on one of my servers, xen+ubuntu on the host, and a random collection of domU's
<clever> nekroze: is there anything stopping you from just running all of the services right on the host?
<clever> nekroze: is there a reason you need to use containers?
<clever> it instead shuts down the entire container, then boots it back up with the new config
<clever> its also unable to restart services within a container as seamlessly as it does on the host
<clever> it affects all services using @
<clever> that nixos-rebuild isnt aware of
<clever> but container@test1 reads /etc/containers/test1.conf, which is a bit of an impurity
<clever> and restarts when it does
<clever> nekroze: the issue, is that nixos-rebuild checks to see if the /etc/systemd/system/container@.service symlink has changed or not
<clever> it must be using the routing tables of the host
<clever> uh, i didnt set defaultGateway, and i also have wan, lol
<clever> you need to manualy systemctl restart container@test1
<clever> or just reboot
<clever> nekroze: also, nixos is unable to restart declarative containers when they change
<clever> yeah
<clever> that will at least give it access to the LAN, but probably not the WAN
<clever> the docs for localAddress
<clever> The IPv4 address assigned to the interface in the container. If a hostBridge is used, this should be given with netmask to access the whole network. Otherwise the default netmask is /32 and routing is set up from localAddress to hostAddress and back.
<clever> nekroze: aha, i ran tcpdump on br0 while booting a container, it never tried to do dhcp!
<clever> building it with some more debug utils
<clever> which lacks an IP
<clever> now it has its own network interface
<clever> booting it again with privateNetwork = true;
<clever> letme try again with private networking enabled
<clever> nekroze: http://imgur.com/a/BDhKz with a minimal config, it wound up with the exact same interfaces as the host
<clever> uploading
<clever> also, the hostBridge option behaves differently then i was expecting
<clever> id give it a second static ip then
<clever> ah
<clever> nekroze: you will want to move that static ip to br0
<clever> how is nixops turning dhcp off?
<clever> so if its null, it will just auto-dhcp everyting
<clever> i think setting it to anything will also disable it on all other interfaces
<clever> and it may also need a .enable = true;
<clever> networking.dhcpcd.allowInterfaces = [ "br0" ];
<clever> nekroze: did you change any dhcpcd related settings?
<clever> hmmm, the nat of qemu may complicate it, but we will see
<clever> hmmm, or qemu would work
<clever> nekroze: let me finish cleaning out my laptop, then i can experiment with things on this end
<clever> nekroze: ah, hadnt seen that option, looks perfect
<clever> and if a lan interface has been added, it will get a reply from the lan
<clever> nekroze: under nixos, it will just run dhcpcd on br0 automaticaly, if it lacks an IP
<clever> nekroze: i think you need to add the veth interfaces to br0
<clever> nekroze: and then somehow add the containers to br0
<clever> nekroze: i havent tried containers with a bridge yet, but you will need to at least do networking.bridges.br0.interfaces = [ "enp0s20u1" ]; with the LAN interface
<clever> then you are free to format the hdd and nixos-install like normal
<clever> newNixos: and you will get nixos running from a ramdisk, similar to if you had put an install ISO in the machine
<clever> newNixos: if you insert your own ssh public key into configuration.nix, and build it correctly, you will get a tar file, upload it to the server and run it as shown in session.md
<clever> newNixos: there is a new thing that ive been testing out on virtualbox
<clever> and thats enough to boot a raspberry pi 3 over the network, and make it into a nix build slave
<clever> with a single nix-build command, i get a kernel, initrd, and a ~40mb squashfs
<clever> i'm also experimenting with a custom OS that can act as a build slave
<clever> so platform = system: pkgs.platforms.raspberrypi2; would work on the newer version
<clever> and the config.platform option has recently been "broken", it no longer accepts an attrset, it instead wants a function from system to attrset
<clever> newNixos: the rpi3 needs a different kernel, which is done via nixpkgs.config.platform
<clever> newNixos: and if you add http://pastebin.com/zL5dXim4 to /etc/nix/nix.conf you can leech off my binary cache
<clever> then you basicaly just follow the linode guide
<clever> that will get you nix on any arm distro
<clever> newNixos: here is an arm tarball: http://hydra.earthtools.ca/build/40582
<clever> the script itself lacks arm support, because there is no arm tarball
<clever> newNixos: i have a couple links that will speed it up as well
<clever> newNixos: the simplest way to start, is to install nix on another distro like the debian variants for the beaglebone, and then use nix-build to compile the rest up and nixos-install to an SD card
<clever> newNixos: i have 2 installs of nixos on armv6, and i am working on a v7 build
<clever> either services.xserver.displayManager.sessionCommands or ~/.xprofile
<clever> i tend to use chromium on linux
<clever> nix-env tells you exactly what should go in there
<clever> text editor
<clever> ashkitten: that will only effect nixos-rebuild
<clever> so you probably need to set it in 2 places
<clever> nixos-rebuild only reads configuration.nix
<clever> ashkitten: nix-env always reads ~/.nixpkgs/config.nix
<clever> nix-env -iA nixos.discord
<clever> ashkitten: channels are per-user, and you generaly only want a channel on root
<clever> ashkitten: you need to remove the nixpkgs channel in nix-channel --list
<clever> different versions of the libs will conflict, and ruin the entire benefit of using nix
<clever> thats not how nix is meant to be used
<clever> then just diff -u a.txt b.txt
<clever> you can see what gets set by doing "env > a.txt" outside of the shell, and "env > b.txt" inside the shell
<clever> Leo`: you generaly only put libraries in nix-shell -p, they should never be installed with nix-env

2016-12-09

<clever> it will still make a grub.cfg in /boot, but nothing will be installed to the MBR
<clever> yeah
<clever> boot.loader.grub.device = "nodev"; tells it to not install a grub to the MBR
<clever> Cinnamon811rc: it should finish in under a minute, since all the files are present, and re-ask for the root pw
<clever> Cinnamon811rc: simplest thing is to just boot from the installer, re-mount things, and re-run nixos-install
<clever> and then the testcase can read the file out of the guest, to steal the secret and continue testing
<clever> my thought, is to have it generate its own secret when nixops isnt at play
<clever> lewo: the sshd service is an example of that already in nixos