2017-10-22

<clever> iqubic: what does "fdisk -l /dev/sda" say?
<clever> iqubic: mount /dev/sd?? -v -o ro -t ntfs /mnt/ && ls /mnt/
<clever> nixos-generate-config may auto-detect it and make the config for you
<clever> it might even be automatic
<clever> ldlework: sure
<clever> iqubic: and if you want to see an example of how to do a nixos install with zfs, https://github.com/cleverca22/nix-tests/blob/master/kexec/justdoit.nix#L38
<clever> iqubic: i dont trust grub with zfs, and it has had problems in the past
<clever> iqubic: for zfs, i would keep a seperate /boot partition
<clever> ghostyyy: line 179-185 handled all of udev
<clever> or modify the package directly
<clever> ldlework: looks like such a thing doesnt exist yet, your only option is either allowBroken or allowUnsupportedSystem in config.nix
<clever> { valid = false; reason = "broken"; errormsg = "is not supported on ‘${system}’"; }
<clever> else if !allowUnsupportedSystem && !allowBroken && attrs.meta.platforms or null != null && !lib.lists.elem system attrs.meta.platforms then
<clever> ldlework: in that case, it takes a name, and returns a bool, so you can manage allowUnfree on a per-name basis
<clever> one min
<clever> so you cant read it, to make an override
<clever> ldlework: the platform stuff, stops you from ever reading the original dotnetPackages.FSharpAutoComplete
<clever> ldlework: ah, i see the problem
<clever> ldlework: i cant see why not
<clever> addMetaAttrs {description = "Bla blah";} somePkg
<clever> 15 addMetaAttrs = newAttrs: drv:
<clever> /home/clever/apps/nixpkgs/lib/meta.nix:/* Some functions for manipulating meta attributes, as well as the
<clever> let me see...
<clever> ldlework: meta has a special override function
<clever> which leaves little point in having it detatched
<clever> and an advesary could just archive the /boot and ciphertext at once, and steal your pw later
<clever> yeah
<clever> nixos version, oops!
<clever> so it will be world readable within your /boot folder
<clever> the gentoo version will embed the file into the initrd when you do "nixos-rebuild switch"
<clever> so you can just set .header = "/header";
<clever> that will make the header available at /header within the initrd
<clever> ghostyyy: and then you can safely insert some commands before it, at 189
<clever> ghostyyy: by changing the luks to be post lvm, it will be opened at line 198
<clever> '';
<clever> umount /somewhere
<clever> cp /somewhere/header /header
<clever> mount /dev/sd?? /somewhere
<clever> boot.initrd.preLVMCommands = ''
<clever> ghostyyy: my guess, change the luks to preLVM = false;, then set
<clever> so the luks will be opened in the preLVMCommands phase
<clever> boot.initrd.preLVMCommands = concatStrings (mapAttrsToList openCommand preLVM);
<clever> default is before
<clever> ghostyyy: is the luks flagged as before or after lvm?
<clever> ghostyyy: you will need to add a script somewhere to tell the initrd to mount the usb stick, copy the header into the ramdisk, and then umount it

2017-10-21

<clever> anyways, its getting late here, i should get back to bed
<clever> At least for now. It would increase the ISO size by ~10 MB,
<clever> joko: that causes nix to count them as a dependency, and copy them in for you
<clever> joko: all paths in system.extraDependencies are just written to a random file within the nixos build, and never touched again
<clever> joko: but recently, it got redone, and a bug was introduced, it now builds the entire system on the host rootfs (in the ramdisk), then copies it to the target
<clever> joko: previously (a few months ago), it was basically just a script to run nix-build under a chroot, after using rsync to get just nix inside /mnt/nix/store/
<clever> so that module is probably in scope and allowing it
<clever> this also forcibly sets sshd to not run on boot
<clever> joko: thats a special thing in the installation images
<clever> by default, nixos doesnt allow password auth for root
<clever> hyper_ch: you can also add it to /ssh_pubkey on the debian host, before you run the kexec script
<clever> an example is already in place
<clever> hyper_ch: you need to add your ssh pubkey to configuration.nix
<clever> joko: for example, you can add kexec.justdoit.rootDevice = "/dev/vda"; in https://github.com/cleverca22/nix-tests/blob/master/kexec/configuration.nix
<clever> joko: currently, it has a range of nixos options, which you can then set in the configuration.nix nearby
<clever> joko: i could add an if statement near the top to just check both sda and vda, and use whichever exists
<clever> that also explains the lack of problems when i did some maintaince on my laptop
<clever> ah yeah
<clever> and you cant just set forceimportroot once, because thats state
<clever> currently, you would need to discover what the right id is for that install (or generate a new one, and set forceimportroot)
<clever> how does nixops know what id to bake into the image?
<clever> idealy, every machine should have a unique hostid, generated at install time
<clever> which reminds me, dealing with zfs and nixops looks like it could be tricky
<clever> only issue, is that you still dont know the predictable name, and have to continue to do that for the nixops config forever into the future
<clever> yeah, that can also help, just flip it on and shove an IP onto eth0
<clever> was trying to remember the magic name for it
<clever> ah, thats what it was called: https://nixos.org/nixos/options.html#predictable
<clever> infinisil: yeah, if your building a kexec image for digitalocean, just drop this into the imports list, and it should just work
<clever> infinisil: and i think its just a matter of configuring the interface to 169.254.0.1/16 and downloading http://169.254.169.254/metadata/v1.json
<clever> so it could be used any time systemd is available
<clever> infinisil: its just a small daemon written in go, that generates systemd config on the fly
<clever> infinisil: there is also a service you can run in nixos, that will query the same info over 169.something
<clever> infinisil: this is a pci device on bus 4, slot 2, function 1
<clever> 4: enp4s2f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
<clever> 04:02.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
<clever> infinisil: with the modern systemd config, the interface name maps to the pci device location within the hardware
<clever> Yaniel: and the dhcp server is configured to allow netboot, complete with tftpd and nginx, serving a nixos installer
<clever> Yaniel: the wifi is the WAN port, the ethernet is the LAN port, complete with dhcp, bind, and NAT
<clever> Yaniel: the above module sets the laptop up sort of like a reverse router
<clever> so its not really possible to get them swapped
<clever> Yaniel: in my most recent NAT case, i was dealing with 2 different types, wifi and ethernet: https://github.com/cleverca22/nixos-configs/blob/master/netboot_server.nix
<clever> Yaniel: that is an old rack-mount server with a dual port gigabit on the motherboard, and an extra gigabit in a pci slot
<clever> Yaniel: i can see the 2nd and 3rd card, are on bus 4, slot 2, function 0 and 1
<clever> Yaniel: this machine is a little more busy: https://gist.github.com/cleverca22/c0a498de27d3931711b5a7ccb11e63da
<clever> dragon__: try nix-shell -p gcc
<clever> hyper_ch: look at session.md
<clever> hyper_ch: did you read the session.md file yet?
<clever> hyper_ch: its designed to be used without any nix on the target
<clever> but make sure you eval that within the nix-shell
<clever> it should still be at $NIX_CC/nix-support/dynamic-linker
<clever> dragon__: where are you looking for it exactly?
<clever> the 3 and 0 match up between the name and lspci
<clever> 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
<clever> 03:00.0 Ethernet controller: Intel Corporation 82583V Gigabit Network Connection
<clever> and the bash script will just magically depend on the nix file
<clever> it will import a copy of that nix file into the store, and insert in the storepath
<clever> < ${./target-config.nix}
<clever> and because i did this at the nix level
<clever> joko: its applying sed to target-config.nix (in the same directory) to create the final working configuration.nix of the install
<clever> joko: and every machine should have a unique value, so they cant import eachothers pools by mistake
<clever> joko: zfs expects a networking.hostId option in the nixos config, which is just a random blob of hex
<clever> in the old days, there was udev rules to bind a given name to a given mac, so it would be random on the first boot, and stick to that random layout
<clever> hyper_ch: which driver loads first?
<clever> hyper_ch: what about when you have 2 network cards?
<clever> it wasnt using the new naming style
<clever> the last machine i used it on, still called the card eth0
<clever> then i can make another guess and try again
<clever> hyper_ch: so if i do get the network config wrong and loose all control, it will reboot itself, restoring control to the original OS
<clever> hyper_ch: one trick, i have configured the kexec image to reboot the machine every hour on the hour
<clever> joko: DO is also special, in that the static ip is unique to the instance, and they try to edit your /etc/networking/interfaces file to fix the config for you
<clever> joko: and you must know the name systemd will assign if you want to configure the static ip
<clever> joko: if the datacenter supports dhcp, thats easy, but with some, you have to configure a static ip
<clever> joko: the main issue right now with the kexec trick, is getting the network online
<clever> infinisil: nox has a cache built into it, and i also just use tab-completion in nix-repl
<clever> dragon__: what about when you add --pure to nix-shell?
<clever> hyper_ch: the machine has to be able to read the swap after a cold boot, to restore the contents of ram
<clever> hyper_ch: random key doesnt play nicely with hibernation
<clever> dragon__: nix-shell -p openssl stdenv
<clever> joko: mainly planning ahead for hibernation
<clever> hyper_ch: zfs needs to allocate ram to do IO, and allocating ram inside the swap thread is bad
<clever> hyper_ch: thats swap on a zvol, which has had deadlocking issues in the past
<clever> hyper_ch: 2: that wont encrypt swap, and i dont trust a zvol with swap
<clever> hyper_ch: 1: i havent tested zfs encryption on my end yet
<clever> joko: yep
<clever> infinisil: in this case, i wanted a single luks to protect both swap and zfs
<clever> dragon__: ld will never find things you have installed, you must use nix-shell
<clever> infinisil: i have also added zfs on lvm on luks to justdoit
<clever> joko: and its written as a nixos module, so you add it to the imports for the installer (methods 1-3 above), and it will already be "installed" when you boot the installer
<clever> joko: this is a bash script, that does the entire install with 1 command
<clever> joko: thats where justdoit.nix comes in
<clever> but you only get 1 chance to do it right
<clever> and if the bios obeys the MBR, you can easily install nixos to the drive
<clever> with #1, you can boot the nixos installer onto any remote machine that you have root on
<clever> so you can now boot into the installer at any time
<clever> this just copies the same files to /boot/ and adds them to grub
<clever> this sets up a full netboot server on my laptop, so any machine plugged into the ethernet jack can netboot into the installer
<clever> this uses kexec to forcibly hijack any running linux machine
<clever> i now have 3 variants of that ramdisk installer
<clever> joko: the kexec trick gives you the full nixos installer, running from a ramdisk, so you are free to then format the drive and install nixos normally
<clever> it may need other libraries added to the fhs
<clever> srhb: so attempting to debug anything on the system, breaks that software and forces you to reboot the entire machine
<clever> srhb: there is a windows util similar to strace, and i have discovered at least one application, that fails all license checks if that util has been ran even once, until you reboot to clear the state
<clever> fearlessKim[m]: its simpler to remove it from home-manager first
<clever> adamt: that may have options to just unpack things to the current directory
<clever> adamt: does it accept anything like --help now?
<clever> srhb: but you could potentialy run that wrapper at build time, within another derivation
<clever> srhb: all .env does is setup a shellHook, to run the namespacing wrapper when you enter nix-shell
<clever> fearlessKim[m]: try the nix-store -qR on the readlink'd version
<clever> srhb: hmmmm, yeah, maybe
<clever> fearlessKim[m]: what is the output of which msmtp?
<clever> fearlessKim[m]: you want -qR i believe
<clever> CcxWrk: something within nixpkgs would have to be changed, to replace libc with musl
<clever> CcxWrk: and if you build an arm copy of nix with this, you can use nix-copy-closure to shuffle things between the 2 devices
<clever> CcxWrk: once its confirmed working, you can use nix to build anything in nixpkgs
<clever> CcxWrk: the next step, would be to grab the closure of hello with "nix-store -qR /nix/store/hash-hello", tar the whole thing up, then unpack it on the phone at /nix/ (optionaly with a chroot to get it in the right spot) and try to run hello-world
<clever> CcxWrk: that will build the entire compiler toolchain and also confirm that the compiler is working
<clever> MichaelRaskin: i dont know how, but the FHSenv is able to mess with the root dir without uid 0
<clever> srhb: if you have a non-nixos machine, you could try running binwalk over the installer
<clever> yeah
<clever> MichaelRaskin: there is still the difference between needing the FHS at build time, vs at runtime
<clever> there is another util i know of that can help, but i have yet to get it working under nix
<clever> avn: is the file publicly downloadable?
<clever> and libredirect wont work either, because its static!
<clever> avn: i dont think that will work, because the resulting binary is hard-coded to open /lib64/ld-linux-x86-64.so.2
<clever> srhb: or just upx -d
<clever> it might be a different packer
<clever> try running strings or --version over it, and see what the contents are
<clever> and patchelf cant patch the compressed sections
<clever> upx will unpack the real binary in ram, then run /lib64/ld-linux-x86-64.so.2 against the unpacked result
<clever> srhb: "nix-shell -p upx" and then "upx -l installer"
<clever> srhb: one min
<clever> srhb: aha, i think i know what it is
<clever> srhb: strace -f ./installer
<clever> srhb: strace the installer
<clever> CcxWrk: yeah
<clever> since patchelf cant patch static's (and they dont need patching)
<clever> when just running the installer directly
<clever> srhb: what error does it fail with when ran?
<clever> patchelf only works on things with dynamic linking
<clever> srhb: what does "file" say about the binary?
<clever> fearlessKim[m]: oops, the clang msg was for you
<clever> CcxWrk: ah, that works
<clever> CcxWrk: that causes a 300mb size difference in my clang
<clever> 576M /nix/store/yi8cw982zkjc738r0xq9px6w5700frzz-clang-4.0.1
<clever> fearlessKim[m]: and if your using a compressing filesystem, you may also want to give du a --apparent-size
<clever> and that should have been --max=0
<clever> fearlessKim[m]: this will show you the entire closure, and what the fattest things are
<clever> 3.4G total
<clever> 269M /nix/store/yi8cw982zkjc738r0xq9px6w5700frzz-clang-4.0.1
<clever> $ du --max=1 -h -c $(nix-store -qR /run/current-system) | sort -h | tail
<clever> CcxWrk: you can either find the gentoo version of it, or just do "nix-build -A qemu-user-arm -o qemu-user && ./qemu-user/bin/register" to build it with nix and auto-register it
<clever> fearlessKim[m]: thats only the size of msmtp itself
<clever> CcxWrk: something like this will have to be ran, with the absolute path to your qemu-user-arm binary
<clever> echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\x00\xff\xfe\xff\xff\xff:$out/bin/qemu-wrap:P' > /proc/sys/fs/binfmt_misc/register
<clever> CcxWrk: then binfmt-misc isnt configured to auto-run qemu-user
<clever> b: stop nix-daemon, then run the patched nix-daemon from the nix-misc/result symlink as root
<clever> a: stop nix-daemon temporarily, and use the patched nix-build as root
<clever> you can either
<clever> its the daemon that does that safety, so it has to run the patched version to allow bypassing it
<clever> you must run the nix-daemon from the result symlink
<clever> also
<clever> yep
<clever> CcxWrk: are you using nix-daemon?
<clever> which would normally result in errors, but qemu-user makes it work
<clever> CcxWrk: that just silences the safety check that just failed, and tells nix to blindly try running any armv7l-linux binary it needs
<clever> "build-extra-platforms = armv7l-linux" in /etc/nix/nix.conf
<clever> CcxWrk: your missing the extra platforms in nix.conf
<clever> CcxWrk: did you also pass --argstr system ... ?
<clever> CcxWrk: and --option is just a generic way to override anything in nix.conf
<clever> CcxWrk: i believe build-max-jobs is the default for the nix level -j
<clever> CcxWrk: and both cause heavy interleaving of the output, making it rather unreadable, so -Q will silence all output
<clever> CcxWrk: "-j 8" runs 8 packages in parallel, and "--option build-cores 8" passes "-j 8" to make, within each package
<clever> CcxWrk: the -j flags above can also be used to speed that arm build up
<clever> CcxWrk: now add the extra platforms to nix.conf, and then try to build hello-world with the resulting nix
<clever> CcxWrk: but you can also use "-j 8 -Q --option build-cores 8" to force it to use the cores
<clever> CcxWrk: it will obey the core config in your existing /etc/nix/nix.conf
<clever> CcxWrk: yeah
<clever> yep
<clever> so they have different hashes
<clever> and the 2nd one you added is the original with the defaults
<clever> so it may install a copy without the xorg components
<clever> gleber_: the service installs a modified copy of the vbox package, based on your hardening and headless options
<clever> gleber_: removing the virtualbox under systemPackages should silence the warning
<clever> gleber_: the service options add it to systemPackages for you
<clever> gleber_: what lines have you added to configuration.nix that reference virtualbox?
<clever> CcxWrk: oh, and it needs build-extra-platforms = armv7l-linux in /etc/nix/nix.conf
<clever> CcxWrk: which will run the native arm7 -> arm7 compiler to build hello world
<clever> CcxWrk: after nix is done building nix, you can do something like: ./result/bin/nix-build '<nixpkgs>' -A hello --argstr system armv7l-linux
<clever> though with android, that doesnt matter much
<clever> CcxWrk: dynamic breaks ldd, which messes up the initrd generation for nixos
<clever> CcxWrk: oh, and the qemu-user binary you have from portage, is it static or dynamic linking?
<clever> CcxWrk: git clone the nix-misc repo i linked previously, and run "nix-build -A nix" and let me know when that finishes
<clever> CcxWrk: ah, thats half the work
<clever> CcxWrk: to start with, are you going to use a nixos or other linux for the build host?
<clever> CcxWrk: the parts i linked, purely make an x86 machine capable of running arm code, so you can use an x86 machine instead of an arm machine
<clever> CcxWrk: the musl stuff would come afterwards, and this part wouldnt have to change any
<clever> jluttine: the next thing to check would be "nixos-rebuild build -vvvvvv" and go over every .nix file its reading
<clever> joko: i have done most of that before, it just had a few kinks with the kernel and xargs, they may have since been resolved
<clever> jluttine: i can also see that you have that commented out on line 27-ish
<clever> jluttine: and that nextcloud derivation is the root for something in nginx
<clever> jluttine: reading the nextcloud .drv file, i can see calendar.tar.gz is in its $src
<clever> CcxWrk: there is also a cross-compile framework in nixpkgs, but its got some kinks in it, and nix-env on the arm wont use the cross-compiled libraries, so it would have to rebuild it all again
<clever> CcxWrk: when the 2 are combined properly, the machine can just run any arm binary, including an arm compiler
<clever> CcxWrk: and the nix on line 12, is a patched copy of nix, that supports "build-extra-platforms = armv7l-linux" in /etc/nix/nix.conf, which will convince nix-daemon that the x86 machine can "just run" arm binaries
<clever> CcxWrk: this build of qemu allows you to run armv7 binaries on an x86 machine, without any kernel/system emulation, just build qemu-user-arm, and run the register script as root
<clever> jluttine: can you gist the files involved in nextcloud and the contents of /nix/store/hl95ln7vif73kiz13wsf3ydq7nn97xfb-nginx.conf.drv and /nix/store/b3k0ivqdiasar8k618l4vbxdqzr7zqwn-nextcloud-12.0.2.drv
<clever> CcxWrk: ah, thats compatible with the rasberry pi 2 and 3, and also the qemu emulation i have, one min
<clever> ah
<clever> or add it to the existing gist
<clever> jluttine: can you gist your configuration.nix file?
<clever> jluttine: nginx depends on nextcloud which depends on calendar.tar.gz
<clever> CcxWrk: do you know if its armv6, armv7 or aarch64?
<clever> CcxWrk: ah, you could use a different arm device with a compatible cpu
<clever> jluttine: can you gist the full error?
<clever> CcxWrk: and what prevents you from running normal glibc based nix on it?
<clever> CcxWrk: which device are you trying to target?
<clever> avn: as long as you move the entire /nix to /nix on another device, it will survive
<clever> CcxWrk: nix has its own build slave setup, but it assumes you can run nix on the target machine
<clever> CcxWrk: which resulted in a normal nix build inside /nix/store/
<clever> CcxWrk: i believe i had built nix from source with ./configure, then i used that nix to build nix with nix
<clever> CcxWrk: i have nix running on one of my raspberry pi's, ive given my hydra a kick to get it going again
<clever> bebarker: and then just a dummy derivation i can shell into: https://gist.github.com/cleverca22/9c4a83b06121108607b54771a38ebbaa
<clever> bebarker: as a nixos module that installs vim: https://github.com/cleverca22/nixos-configs/blob/master/vim.nix#L37
<clever> bebarker: that allows me to just "nix-shell vim.nix" and i get a fully configured editor, without any lasting changes to the machine
<clever> bebarker: another option is to just write a second file, that does nothing and depends on gurobi
<clever> and its just dumb string manipulation, so you can inject code into that
<clever> all -p does, is generate a dummy derivation to "build", and puts all of the arguments into the buildInputs
<clever> bebarker: nix-shell -p '(import ./gurobi.nix)'
<clever> bebarker: ahh, you want to use the result of it, not build it under the shell
<clever> if the file doesnt need any arguments
<clever> bebarker: nix-shell vim.nix

2017-10-20

<clever> deliciousmayo: environment.systemPackages = [ (pkgs.haskellPackages.callPackage ./foo.nix {}) ]; on the result of cabal2nix
<clever> deliciousmayo: then you can just load it in configuration.nix and pop it into systemPackages
<clever> deliciousmayo: if you make a derivation using cabal2nix, you can then install it with nix-env, and it will be available in PATH
<clever> and the fact that the option was just docker-containers, without any of the normal prefixes