2018-07-11

<clever> logzet: yeah, thats normal, lets start with just the classes
<clever> samueldr: that looks like a native arm build
<clever> logzet: can you pastebin the full output of lspci ?
<clever> logzet: let me check something
<clever> logzet: does lsusb change when you add/remove the usb stick?
<clever> logzet: and can you still see sdb in blkid, after unplugging the stick?
<clever> logzet: what about fdisk -l /dev/sdb
<clever> logzet: try unplugging the usb stick, and plugging it into different usb ports, and checking blkid after each port
<clever> logzet: hmmm, and if you mkdir /mnt; mount -v /dev/sdb1 /mnt; ls /mnt/; what do you see
<clever> more about the labels and other minor things
<clever> logzet: can you take a photo of the blkid output, and upload it somewhere?
<clever> logzet: yeah, those are under by-partlabel, not by-label
<clever> lrwxrwxrwx 1 root root 10 Jul 5 05:09 /dev/disk/by-partlabel/ZFS1 -> ../../sdb2
<clever> /dev/sdb2: LABEL="amd" UUID="14989079359259406011" UUID_SUB="17123459550043989470" TYPE="zfs_member" PARTLABEL="ZFS1" PARTUUID="13e57ae8-4788-4a71-a0eb-e9d62644da67"
<clever> does blkid show the label?
<clever> logzet: what about lsusb and lspci?
<clever> logzet: any of those the usb?
<clever> logzet: and lsblk or blkid outputs?
<clever> logzet: launch that shell, then check `ls -lh /dev/root`, what does it say?
<clever> logzet: does the initrd give you the option to launch a shell in the initrd?
<clever> logzet: there should be a root=something arg to the kernel, which configures what it waits for
<clever> could you compile nix to x86 native binary?
<clever> this gives me a thought, llvm ....
<clever> but yeah, a static language makes it much easier to catch
<clever> infinisil: hydra could also have caught it, with the right release.nix entry
<clever> list*
<clever> infinisil: lidy
<clever> and conflicts will arise if i want to run both copies at once
<clever> samueldr: the uuid's of FS's is going to change if i ever made a replacement
<clever> samueldr: i keep the boot related stuff seperate from the git managed things
<clever> no need for variables in paths
<clever> and then everything else starts from that, which forms a tree of modules
<clever> i make configuration.nix do imports = [ ./nixcfg/amd-nixos.nix ];
<clever> samueldr: the imports list must not depend on any value from the config or options trees
<clever> sounds normal
<clever> samueldr: it probably depends on if the target is a dir or not
<clever> bash tab-completes the wrong one
<clever> `rm result` deletes the symlink, `rm result/` tries to delete the storepath the link points to
<clever> logzet: did you dd to sdb or sdb1?
<clever> WilliamHamilton: oh, but the makeFlags on 67 dont do anything, line 71 replaces the default buildPhase
<clever> but the cause cant be located
<clever> WilliamHamilton: line 101 is already doing exactly that
<clever> WilliamHamilton: for x in $out/pakcs/bin/*; do
<clever> WilliamHamilton: dont parse the output of ls, that will fail in a dozen different ways
<clever> for b in $(ls $out/pakcs/bin) ; do
<clever> infinisil: oddly, it doesnt have an xlib_xcb.pc file though
<clever> ,locate xlib_xcb
<clever> gchristensen: still fails on this end
<clever> gchristensen: hasnt expired from the cache just yet
<clever> grahamc.com. 1450 IN AAAA 2a04:4e42::403
<clever> gchristensen: its supposed to both cache a binary cache, and mux several caches into a single URL
<clever> gchristensen: ive also got a project ive been wanting to resume, that is related to that post, https://github.com/cleverca22/cachecache
<clever> gchristensen: will take an hour for it to expire from my cache
<clever> and then your entire firewall stops working
<clever> chessai: without that, you wind up adding to a chain before the chain has been created
<clever> chessai: yes
<clever> samueldr: i have also seen what some local ISP's have tried to do in the past: https://imgur.com/a/YWcKxri
<clever> now they check, and i cant watch ANYTHING
<clever> samueldr: previously, they didnt check, so i was able to watch the american lineup
<clever> samueldr: my HE tunnel also breaks netflix, because they think i'm trying to evade the region lockouts
<clever> samueldr: i usually have v6 disabled in the browser itself, not sure how it turned back on
<clever> samueldr: and since your v4 only, that explains why you dont have an error
<clever> i havent gotten openssl to use 6 yet
<clever> gchristensen: checking the network console in chrome, both machines with the problem are using ipv6
<clever> gchristensen: all 4 IP's now return the correct lets encrypt cert
<clever> `openssl s_client -connect 185.199.111.153:443 -servername grahamc.com` now gives a lets encrypt cerr
<clever> oh no, i wanted -servername
<clever> gchristensen: i think, double-checking the man page
<clever> gchristensen: this tells it to open an SSL socket, and claim that domain for SNI purposes
<clever> openssl s_client -connect 185.199.111.153:443 -host grahamc.com
<clever> gchristensen: thats why i passed -host grahamc.com
<clever> LnL: do both of your machines have v6 support?
<clever> all 4 V4 IP's return github certs and should trigger cert warnings
<clever> gchristensen: 185.199.108.153 returns a github cert for me
<clever> let me check each...
<clever> i see 8 IP's behind that domain
<clever> gchristensen: what IP do you see behind the domain?
<clever> gchristensen: This server could not prove that it is grahamc.com; its security certificate is from www.github.com. This may be caused by a misconfiguration or an attacker intercepting your connection.
<clever> gchristensen: Attackers might be trying to steal your information from grahamc.com (for example, passwords, messages, or credit cards). Learn more
<clever> adelbertc: thats something else i believe
<clever> adelbertc: apple doesnt update $HOME when you do that, so it operates on the wrong user
<clever> adelbertc: and you cant `sudo nix-channel --update` because apple
<clever> adelbertc: yep
<clever> adelbertc: sudo -i ; nix-channel --update ; nix-env -iA nixpkgs.nix
<clever> chessai: in this case, its restricting it to coming from a certain subnet, over a certain interface
<clever> mightybyte: you need a nixbld group, with a number of build users within it
<clever> mightybyte: last i checked, the linux installer only does single-user installs, which only work as the user that installed it, which cant be root
<clever> mightybyte: if you lack a nixbld group, then it only works when ran as a non-root user
<clever> kalbasit: yeah, that looks like its all good now
<clever> kalbasit: and `cat /root/.nix-channels` ?
<clever> kalbasit: you forgot to run `nix-channel --update` after adding a channel
<clever> kalbasit: ls /root/.nix-defexpr/channels/nixos/
<clever> kalbasit: and as root, what does `nix-channel --list` say?
<clever> kalbasit: and as root, what does `nix-channel --list` say?
<clever> kalbasit: what if you instead run `sudo -i` then `nixos-rebuild test`
<clever> tenten8401: nope
<clever> and then the default buildPhase will run make with that param for you
<clever> you could set: makeFlags = [ "CURRYFRONTEND=${curryBase}" ];
<clever> WilliamHamilton: why do you need that path in the nix shell?
<clever> WilliamHamilton: thats because its part of $buildInputs
<clever> WilliamHamilton: your already doing that on lines 52, 56, and 59
<clever> WilliamHamilton: just put curryBase in buildInputs
<clever> WilliamHamilton: buildInputs is an array of nix values
<clever> WilliamHamilton: it doesnt have to be an attribute to use it in buildInputs
<clever> WilliamHamilton: so its not a bash variable, only a nix value
<clever> WilliamHamilton: its no longer an attribute on the derivation
<clever> WilliamHamilton: this is how most things do it
<clever> postUnpack = "sourceRoot+=/engine-io-wai; echo source root reset to $sourceRoot";
<clever> yeah
<clever> WilliamHamilton: because the default sourceRoot is the name of the directory tar -xf made
<clever> WilliamHamilton: sourceRoot
<clever> nbathum: user not found? lol
<clever> zduch4c: did you set isNormalUser = true; when creating the user?
<clever> WilliamHamilton: in any of the phases/hooks
<clever> WilliamHamilton: and every attribute on the derivation becomes an env var for that derivation
<clever> WilliamHamilton: every derivation in nix has a builder and some args, typically the builder is a bash script
<clever> WilliamHamilton: at the bash level
<clever> it will search the pkgs attribute set for each of the args
<clever> yeah
<clever> nix-build -E 'with import <nixpkgs> {}; callPackage ./example.nix {}'
<clever> WilliamHamilton: it still has to be loaded with callPackage
<clever> WilliamHamilton: you can put each of those derivations into their own files, and just run nix-build on the parts
<clever> tester123: nixpkgs.overlays is a nixos option
<clever> WilliamHamilton: the default unpackPhase will handle directories and .tar.gz files automatically
<clever> WilliamHamilton: depends on which fetch function was used
<clever> WilliamHamilton: usually is, but you can also do src = ./.;
<clever> if those are moved into the let block, the rec can likely be removed
<clever> yeah
<clever> he instead refers to them at the nix level, on lines 61, 65, 68, and 109
<clever> the author of this file sort of messed up, and never actually uses those bash variables
<clever> and because 26 and 50 are inside the set for line 22, they become env variables inside that derivation, so you can access them at $curryBase and $curryFront
<clever> 50 defines how to build curry front
<clever> so it must build line 7, before it can start building line 26
<clever> 26 then defines how to build currybase, and it refers to 7 at line 33
<clever> because 15 is refered to by 12, it will always build 15 before it starts to build 12
<clever> line 15 creates another derivation to fetch a .tar.gz
<clever> line 12 creates a modified version of swiProlog
<clever> WilliamHamilton: line 7 creates a derivation that fetches a .tar.gz
<clever> WilliamHamilton: there are a total of 5 derivations in that file
<clever> they should have probably used sourceRoot, not a symlink
<clever> and then postUnpack will modify the unpacked source
<clever> the unpackPhase will unpack $src
<clever> WilliamHamilton: because ${fsrc} is the path to a .tar.gz, not a directory
<clever> WilliamHamilton: all arguments passed to mkDerivation become env vars within the derivation, and the stdenv will run a bash script that will process them all
<clever> WilliamHamilton: postUnpack is called after unpacking the source, within the derivations builder
<clever> WilliamHamilton: after unpacking the source, it will rename it, then make a symlink
<clever> WilliamHamilton: ah, lines 42-45
<clever> WilliamHamilton: does that subdirectory even exist within the tar on line 8?
<clever> WilliamHamilton: that just sets the src for curry-base to be the result from line 7
<clever> Taneb: AGDA_DIR = makeAgdaDir [ package1 package2 package2 ];
<clever> Taneb: you can easily have a derivation that generates that directory, and then set that as an attribute in the derivation you run nix-shell on
<clever> Taneb: you could use a shellHook for that
<clever> Taneb: only nix-build, not nix-shell
<clever> Taneb: every nix build happens in a directory under /tmp/ that is auto-created, and deleted when the build finishes
<clever> Taneb: nix-build always does that
<clever> gchristensen: that is strange
<clever> and you reinstall daily to change
<clever> not what you happened to install last
<clever> nix-shell always provides the one that shell.nix asks for
<clever> it also entirely avoids the problem of different projects needing different versions of ruby
<clever> kalbasit: thats what nix requires, for developing with any language
<clever> kalbasit: make a shell.nix that has ruby in the buildInputs, and run nix-shell to get access to ruby
<clever> when using nix
<clever> kalbasit: things like ruby usually arent supposed to be installed
<clever> yeah, that would also work out well
<clever> kalbasit: you could make an override that joins the 2 packages using buildEnv, and set ignore collisions to true, then install that override instead
<clever> just note that the symlinks will be resolved, so you need to read the links in /run/opengl-driver and confirm its loading the right one, one not from -qR
<clever> acowley: you can check /proc/<PID>/maps to see what libraries it has loaded while running
<clever> acowley: and check with nix-store -qR to see if libGL is somehow winding up as a runtime dep anyways
<clever> acowley: you could try to diff the good and bad derivation, both with `diff -u -r` on the results, and nix-diff on the .drv's
<clever> but thats all at build time
<clever> setup hooks within libGL still run, and can mutate the stdenv of whatever was depending on SDL2
<clever> acowley: all that does, is automatically add libGL to the buildInputs of anything that has SDL2 in the buildInputs
<clever> acowley: note that propagatedBuildInput's are not available at runtime
<clever> ToxicFrog: [root@amd-nixos:~]# nix-env -p /nix/var/nix/profiles/per-user/root/channels --list-generations

2018-07-10

<clever> makeCustomizable just calls the above function on the config you gave it
<clever> countoren: this generates a vimrc config file
<clever> nix-repl> :b vimUtils.vimrcFile { customRC = "foo"; vam.pluginDictionaries = [ { names = [ "vim-nix" ]; } ]; }
<clever> countoren: pkgs.vim_configurable.customize can still build on darwin
<clever> countoren: you would need to look into how nixpkgs generates it
<clever> countoren: so its not really possible to access the config derivation in an automated manner
<clever> countoren: the derivation returned by `pkgs.vim_configurable.customize { ..}` is just a pkgs.writeTextFile call, to generate a $out/bin/vim with contents like "#!/bin/sh\nexec /nix/store/9p4kzfi2kg5hfhh1j3dbjz96arpcd4b3-vim_configurable-8.0.1451/bin/vim -u /nix/store/39wqqljfmvhv2v59k59jkn80pa4n02k9-vimrc \"$@\"\n"
<clever> countoren: i dont see any easy way to do it from the nix side, what do you want to do with it?
<clever> vajralambda: if you want to edit things, you need to clone nixpkgs from github
<clever> vajralambda: you cant edit either one, the entire /nix/store is read-only
<clever> Edes: yeah, mount the existing efi partition to /mnt/boot after mounting your rootfs to /mnt/
<clever> Edes: i think you can share the efi partition between both systems
<clever> srk: lets take this to #nixos-aarch64
<clever> srk: i put the rpi ontop of the desk fan, since its overheating before it even gets to start.elf
<clever> that will show the logs from the previous bootup
<clever> ambro718: after it fails to boot, connect a monitor and reboot, then run `journalctl -b -1`
<clever> or dvi
<clever> ambro718: hdmi or vga?
<clever> switching from generation 26 to 27
<clever> srk: [root@router:/tftproot/try2]# nix-env -p /nix/var/nix/profiles/per-user/root/rpi3-netboot --switch-generation 27
<clever> bpye: the branches on the nixpkgs-channels repo mirror the channels exactly
<clever> tenten8401: correct
<clever> bpye: that is what hydra is testing, and may become the current stable
<clever> bpye: no
<clever> its malfunctioning, before it can even load the kernel
<clever> srk: simply at boot
<clever> "2018-07-10 18:11:55 bedroom temp: 27.88c(82.18f), kitchen: 26.94c(80.49f), living room: 26.94c(80.49f), outdoor: 21.25c(70.25f), server: 29.94c(85.89f) VCC: over 4.5 volts portb: 00000000"
<clever> srk: its overheating to the point of malfunctioning, lol
<clever> srk: got distracted, then i found the pi sitting at kgdb (kernel debugger), with a thermometer in the corner
<clever> bpye: not currently
<clever> srk: changing absolutely nothing on the netboot server, replugging the the rpi, and watching tftp, results in it loading the 1st file pattern again
<clever> bpye: i lookup the rev of a channel i want to use, and then run this with the rev
<clever> bpye: # nixops modify -d router -I nixpkgs=https://github.com/nixos/nixpkgs/archive/ce0d9d638de.tar.gz deployments/router_deployment.nix
<clever> so it makes no sense for it to have such a different file pattern being loaded
<clever> srk: and a diff confirms that the only change is in cmdline.txt
<clever> [root@router:/tftproot/try2]# diff -r /nix/var/nix/profiles/per-user/root/rpi3-netboot-2{6,7}-link/ -u
<clever> srk: i'm building this image with a clone of the firmware repo nearby
<clever> and i'm using a kernel from nixpkgs
<clever> srk: the dtbo is a device tree blob overlay
<clever> the dtbo is the correct one
<clever> -r--r--r-- 16 root root 810 Jan 1 1970 ../9080d9b6/overlays/pi3-disable-bt.dtbo
<clever> srk: and changed the filenames for the overlays
<clever> srk: also, just removing " iomem=relaxed" from cmdline.txt, caused it to not even read kernel7.img!
<clever> srk: still 7 blinks
<clever> switching from generation 27 to 26
<clever> [root@router:/tftproot/try2]# nix-env -p /nix/var/nix/profiles/per-user/root/rpi3-netboot --rollback
<clever> but i can revert the only thing i changed
<clever> i dont think i have a uboot built for this nixpkgs
<clever> and the ftp logs also show not-found files it tried to open
<clever> srk: this model only loads kernel7.img
<clever> srk: also, tftp says it loaded kernel7.img, and it was found
<clever> 7 Blinks means that kernel.img isn't found.
<clever> srk: aha, it blinks status 7 times
<clever> some of them are not documented
<clever> srk: you can see files that dont exist, which the firmware is trying to read
<clever> srk: also, a handy thing with netboot: Jul 10 20:47:06 router tftpd[24595]: tftpd: trying to get file: 9080d9b6/armstub.bin
<clever> it either doesnt get to the rainbow, or it hangs at the rainbow
<clever> unknown
<clever> srk: and now my pi wont boot again
<clever> srk: i believe at least some of it is, i was probing the SMI with a scope while trying to get it to do something
<clever> you want to add .x86_64-linux to the end, to test it only on linux
<clever> grp: release.nix is normally ran by hydra, and should test the module on every platform at once
<clever> grp: its a set, containing one derivation for every platform nixos supports
<clever> without :b
<clever> grp: when you eval that in nix repl, what does it print?
<clever> grp: run nix-build against that, or use :b in nix repl
<clever> and to drive NAND flash over SMI
<clever> srk: it looks like they have since added a linux driver to allow userland to access the SMI
<clever> srk: its on the main gpio header i believe
<clever> srk: once you know the attribute path, you can just `nix-build nixos/release.nix -A tests.foo`
<clever> grp: run `nix repl nixos/release.nix` and try to evaluate the tests attribute set, and navigate thru it
<clever> so you could address the framebuffer on an external chip
<clever> srk: i think the SMI was a 12 bit wide memory region, meant for driving certain types of displays
<clever> srk: there is something else, let me find it
<clever> srk: i have considered abusing the LCD and camera connectors as high-bandwidth
<clever> srk: the connector on the compute modules gives you access to hdmi, gpio, the camera and lcd connectors, a single usb port, jtag and composite video
<clever> srk: the address bus isnt on the connector
<clever> srk: 1gig of ram, 4gig of eMMC, 1.2ghz quad core
<clever> srk: i believe there is a 64bit compute module
<clever> srk: this is the tool used to boot the compute module over usb
<clever> srk: the compute module saves you from having to deal with the fine pin-pitch and picky signal routing of ram lines, so you can just work with "low-bandwidth" usb and hdmi
<clever> srk: the compute module is more for when you want to make a custom device, and dont need half the junk on an rpi
<clever> srk: oh, and for the model A's and compute module, you can boot over USB, with the rpi rom acting as a usb slave
<clever> srk: there is also the compute module, which has an eMMC chip soldered onto the SD bus
<clever> but there is no published bootcode.bin that is capable of loading start.elf from there, and there is no documentation on the pinout required
<clever> the boot rom is capable of loading bootcode.bin from both of those
<clever> srk: look at the NAND and SPI sections
<clever> srk: it does support booting from a serial flash chip
<clever> if you have an sd card with ONLY bootcode.bin (it must not have ANY other file), then it will act like it has no card at all, and try other enabled modes
<clever> the docs claim that is possible, but a bug in the boot rom stops it from working on mine
<clever> bootcode.bin starts the dram controller, and then requests start.elf over tftp
<clever> thats the rpi3 firmware
<clever> srk: so every pi can have its own image
<clever> srk: in my setup, the rpi firmware uses its serial# to uniquely address a tftp directory
<clever> Jul 10 20:00:29 router tftpd[17554]: tftpd: trying to get file: 9080d9b6/root.squashfs
<clever> Jul 10 20:00:06 router tftpd[17500]: tftpd: trying to get file: 9080d9b6/kernel7.img
<clever> Jul 10 20:00:01 router tftpd[17438]: tftpd: trying to get file: 9080d9b6/start.elf
<clever> srk: in my case, it saves every build in a nix profile, so i have rollback support
<clever> srk: the above command will build the rpi_image derivation of release.nix, then create a new generation of the rpi3-netboot profile, pointing to the result
<clever> srk: and here is the incantation i used for the not-os image: [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> pip3000: and in addition to that, i also have zfs snapshots enabled, so i can diff any file on the entire machine, over almost any time-period
<clever> pip3000: so after a rollback, i can look in there to see what the old config was
<clever> pip3000: that saves a complete copy of the directory containing core.nix at /run/current-system/nixcfg
<clever> pip3000: in addition to the git repo, i also have this line: https://github.com/cleverca22/nixos-configs/blob/master/core.nix#L119-L121
<clever> not sure what the trigger is with zfs
<clever> for xfs, it happens with any volume over 2tb in size
<clever> it only happens when a 64bit capable FS is shared to a 32bit client over NFS
<clever> srk: so all of your builds claim file not found, when the file clearly exists
<clever> srk: the inode numbers dont fit into a 32bit field, and half the packages on nixos tread EOVERFLOW as an empty directory
<clever> srk: zfs/xfs totally break 32bit nixos over nfs
<clever> srk: i ran tgtd on gentoo, i tried to do some fancy things with the tgtd nixos module but it never worked 100% right
<clever> pip3000: i keep a git repo at /etc/nixos/nixcfg/ with 1 file for each host, and then configuration.nix is just the bare-minimum required to boot, and imports = [ ./nixcfg/hostname.nix ];
<clever> srk: it pre-dates the network support in the initrd, so it may need updating