<clever>
nope, its not corruption on the binary cache
<clever>
checking something more...
<clever>
ah
<clever>
Mic92: it sounds more like random filesystem corruption truncated a file on you
<clever>
Mic92: and also the contents of /nix/store/3jkdkw431bxks3b3v8ah006ljipvk0hm-users-groups.json.drv
<clever>
ah right, its the drv hash, not the output hash
<clever>
Mic92: try without /mnt
<clever>
Mic92: can you gist the entire output of ls -lR /mnt/nix/var/log/nix/drvs
<clever>
Mic92: can you read the file at /mnt/nix/var/log/nix/drvs/42/jk6ir4k8fhrpn889qaz8lh1l8d6n6h.drv.bz2
<clever>
Mic92: what is the full storepath to users-groups.json
<clever>
Alling: is the internet on that host working?
<clever>
Alling: 6 Couldn't resolve host. The given remote host was not resolved.
<clever>
Mic92: and what was the output?
<clever>
which one was "is not" ?
<clever>
you have 2 "is"'s in there
<clever>
2017-09-15 11:09:06 < Mic92> *is not
<clever>
2017-09-15 11:09:00 < Mic92> clever: becomes even weirder looks like `pkgs.writeText` is function correctly the json I print with lib.traceVal is correct.
<clever>
what about the value passed to toJSON?
<clever>
Mic92: what is the full storepath to the users-groups.json?
<clever>
ah
<clever>
Mic92: after the install, did you umount /mnt and properly shutdown?
<clever>
Mic92: was the machine properly shutdown?
<clever>
tilpner: this allows you to nix-env -iA foo.hello
<clever>
then 2 people opened PR's to fix it within 12 hours of eachother :P
<clever>
the problem had existed in master for years (ghc being depended on wrongly)
<clever>
that looks like different multiple output changes
<clever>
i hadnt heard of it being reverted
<clever>
the haskell multiple outputs
<clever>
that change massively reduces disk usage for haskell programs
<clever>
might have been me ...
<clever>
*bisects*
<clever>
ah, i see
<clever>
eacameron: what versions of nixpkgs work and dont work?
<clever>
eacameron: have you tried a git bisect?
<clever>
or find the critical difference, and mkForce those changes in configuration.nix
<clever>
then as long as you only enable one of the versions, it will work
<clever>
alunduil: you can also download the module, rename its service a bit, then add it to the imports of configuration.nix
2017-09-11
<clever>
an x86 qemu-user that ran on x86 reproduced the problem without having to reboot linux constantly in a vm, without kvm speedups
<clever>
i was debugging a program that failed under qemu-system, when kvm was turned off
<clever>
or even more wonky, make a qemu-user for x86, that runs on x86!
<clever>
pre-compiled closed-source junk now "works" on a raspberry pi!
<clever>
also fun: make a qemu-user that runs x86 code on an arm
<clever>
with the patch to nix, you gain a build-extra-platforms field in nix.conf, where you can convince nix to just blindly run builds meant for the "wrong" arch
<clever>
without that patch, an x86 build of nix will just complain, armv7l-linux is required to build [...]
<clever>
the patch is on line 13
<clever>
you also need to patch the nix-daemon running on the machine that runs both arches
<clever>
the switch chip defaults into routing the wan and lan into the same network
<clever>
it also has some minor defects that make it a bit un-suitable as a router
<clever>
ive got an allwinner based switch/router here, but i can barely get it past u-boot, i suspect its voltage sags
<clever>
M-liberdiko: there is also activation scripts, just remember to use mkdir -p and make sure it never fails
2017-09-10
<clever>
Infinisil: ah, for /boot on usb that sounds like less of an issue
<clever>
Infinisil: because systemd un-mounted the directory from under me
<clever>
Infinisil: i often leave a shell cd'd into a nfs mount for hours, and then when i try to run anything nix in that directory, it hard fails
<clever>
Infinisil: systemd-automount breaks a number of things for me
<clever>
i see, just doing the cryptopen for 2 devices is costly
<clever>
ahh
<clever>
sphalerite: route 2, modify it to just blindly use the passphrase on all configured luks devices, and to keep asking for passphrases in a loop until everything is unlocked
<clever>
sphalerite: then bash can read one passphrase, and feed it to cryptsetup twice
<clever>
sphalerite: route 1: tell the name of each passphrase, and allow putting the same name on 2 devices
<clever>
sphalerite: another idea i just had, modify the luks code within nixos, to go one of 2 new routes
<clever>
and its a one-time cost (per boot) for the end-user
<clever>
the slower it is, the longer it will take to brute-force the passphrase
<clever>
turning the ascii string into a key that is used to decrypt the luks header
<clever>
and even if you have since changed the luks passphrase, the master key is the same, and they can read any current files, if they re-image your drive
<clever>
but in theory, if somebody was to image your entire drive, and then obtain your password at any point in the future, they can decrypt the luks header in that image
<clever>
so the performance penalty is only when unlocking
<clever>
luks -> lvm -> (root + swap)
<clever>
i use lvm to fix that
<clever>
sphalerite: only issue is if you ever let somebody get a shell, and things like nix-serve
<clever>
ah
<clever>
trailing / ?
<clever>
Infinisil: can you gist both files?
<clever>
it also means any non-root user can read it, while the machine is on
<clever>
sphalerite: so you need to either embed it into the initrd (which also puts it in the store), or add some custom commands to mount ESP, read, umount
<clever>
sphalerite: hmmm, i dont think /boot is mounted by the initrd until after it mounts /