<clever>
genesis: derivations will never use packages you have installed manually
<clever>
freeman42x[NixOS: something that just halts the virtual cpu, without saving the state anywhere, with the option to resume it shortly after
<clever>
freeman42x[NixOS: it would have to be a suspend to ram within the vm software, not the guest
<clever>
but it would obviously have to suspend to the host ram, and it wont survive a reboot of the host
<clever>
freeman42x[NixOS: and in cases like that, the best you can hope for is to suspend the guest, while retrying the writes, until enough space is freed up
<clever>
freeman42x[NixOS: and due to ext4 writing the metadata before the data, the data itself was lost
<clever>
freeman42x[NixOS: ahh, and any writes that where pending at that moment where just thrown out
<clever>
freeman42x[NixOS: this, for the most part
<clever>
nix/store/dhmqrk1mj2kmkq81i67qjpwjd4jdaxp2-findutils-4.6.0/bin/xargs: cannot execute binary file: Exec format error
<clever>
freeman42x[NixOS: plus the host OS for the VM may not obey the same rules about flushing data to disk, and could loose writes
<clever>
freeman42x[NixOS: ext4 only keeps the metadata in a journal by default, so an improper shutdown can null out half of a file
<clever>
freeman42x[NixOS: that can be done with `nix-store --verify --check-contents --repair` i believe
<clever>
freeman42x[NixOS: you can fix them with `nix-store --repair-path /nix/store/foo`
<clever>
freeman42x[NixOS: those are paths that got corrupted on-disk, probably due to not being fully written before the shutdown
<clever>
freeman42x[NixOS: what does this command say?
<clever>
nix-shell -E 'with import <nixpkgs> {}; let env2 = overrideCC stdenv gcc7; in env2.mkDerivation { name = "shell"; buildInputs = [ which ]; }' --pure
<clever>
vcunat: there must be a subtle difference, because your variant was actually a hit in the binary cache
<clever>
vcunat: and it fails to build the stdenv
<clever>
output ‘/nix/store/qs71y5nvcwxqpzs6y3rw4xc6szib4qp0-stdenv’ is not allowed to refer to path ‘/nix/store/49pgxxi59f65xsffpfjlvdsl49ihq9hv-gcc-7.2.0-lib’
<clever>
nix-shell -E 'with import <nixpkgs> {}; let env2 = stdenv.override { cc = gcc7; }; in env2.mkDerivation { name = "shell"; buildInputs = [ which ]; }'
<clever>
vcunat: but youll need to use -E, not -p, since -p uses the original stdenv
<clever>
vcunat: in theory, you can also do stdenv.override { cc = gcc7; } to create a variant that has gcc7
<clever>
vcunat: this creates a variant of stdenv, that has no cc
<clever>
stdenvNoCC = stdenv.override { cc = null; };
<clever>
vcunat: one min
<clever>
catern: id just generate a #!/bin/sh script that runs it on the main py file then
<clever>
catern: double-check that that python actually solves the problem
<clever>
catern: that nix-shell sets up PYTHONPATH automatically i believe
<clever>
troydm: for a simple thing, you can probably just use "nix-shell -p stdenv" and then use gcc inside that
<clever>
troydm: if you try to install gcc, it will just fail with errors like the one you gave
<clever>
troydm: the compiler only works inside nix-shell and nix-build
<clever>
troydm: are you building it inside nix-shell or nix-build?
<clever>
hyper_ch: bit busy right now
<clever>
as long as the namespace is configured to deal with that properly
<clever>
and then mount it
<clever>
or simply make a disk image with setuid root bash
<clever>
you could potentially use a malformed disk image to buffer-overflow the kernel
<clever>
aminechikhaoui: which doesnt allow you to mount things
<clever>
aminechikhaoui: that just lies about what uid your running as
<clever>
aminechikhaoui: so you have to run the whole thing in a linux vm, which gives you a fake root
<clever>
aminechikhaoui: you cant mount a disk image via loopback, because the nix build lacks root
<clever>
so adding a single config.something to the file disables the helper, causing the rest of the file to suddenly become invalid
<clever>
if its missing all 3, nixos will automatically wrap it in config = { ... }; for you
<clever>
all module modules must contain the following 3 keys, imports, options, config
<clever>
that breaks the entire configuration.nix file, due to other weirdness
<clever>
error: Package ‘hydra-2017-09-14’ in /nix/store/1ja644zdbff4n0zxpa7p3w40vqj8lxh7-nixpkgs-18.03pre118668.0e4be9e5f0/nixpkgs/pkgs/build-support/release/nix-build.nix:151 is not supported on ‘x86_64-darwin’, refusing to evaluate.
<clever>
it may
<clever>
so you can start spraying builtins.trace and lib.traceShowVal all over your code
<clever>
dhess: this does a hydra eval, without installing hydra
<clever>
ij: youll want to view the build log for that derivation
<clever>
ij: the configure script may have chosen to not enable it
<clever>
lexooohhh: by default, it uses the version of nixpkgs you currently have
<clever>
lexooohhh: if you specify the nixpkgs revision, and block access to config.nix, it will be a lot more reproducible
<clever>
if you used nix-env instead of nix-build, it would be added to the profile
<clever>
and yeah, file a PR to make the fix go public
<clever>
ldlework: and result is a symlink to that path
<clever>
ldlework: you can run "nix-env -i /nix/store/hash-foo" on a storepath to add it to your profile
<clever>
ldlework: look in the result/bin/ directory to see the binary, and confirm it works
<clever>
ldlework: nix-build doesnt install things, it only builds
<clever>
and try to just build it
<clever>
ldlework: if you add a second --arg config like this, it will just ignore the platform list
<clever>
[clever@amd-nixos:~]$ nix-build '<nixpkgs>' -A oraclejdk --argstr system x86_64-darwin --arg config '{ allowBroken = true; allowUnfree = true; }'
<clever>
on the mac machine
<clever>
ldlework: if you have a fork of nixpkgs already, just edit the platforms array for the package, and then run nix-build -A foo in the root of the nixpkgs clone
<clever>
ldlework: ah, one sec
<clever>
hyper_ch2: and if you mess up the dhcp config, it reboots itself and restores control to the original OS
<clever>
hyper_ch2: mainly, you want to stop it over ssh, to confirm you have control of the machine
<clever>
ldlework: this downloads the darwin build of coreutils from the binary cache
<clever>
ldlework: nix-build '<nixpkgs>' -A coreutils --argstr system x86_64-darwin
<clever>
hyper_ch2: 2 minutes ago, it would have given a warning to every open tty, and you could run `shutdown -c` to abort, and 5 minutes after that warning, it reboots
<clever>
hyper_ch2: 5 minutes after the end of the hour
<clever>
hyper_ch2: ah, then it wont fire
<clever>
hyper_ch2: but if your starting from a decade old debian
<clever>
hyper_ch2: its more predictable, when you can boot the same systemd and look at the names
<clever>
Lisanna: and when that string it placed into another derivation, nix combines the context from every string, to form the build-time deps of the new derivation
<clever>
Lisanna: yep
<clever>
Lisanna: yes
<clever>
Lisanna: every string in nix has some context attached to it, that says what derivations it depends on
<clever>
Lisanna: it discards the string context
<clever>
nixos: haskell.packages.ghc802.ghc-mod
<clever>
Lisanna: probably
<clever>
yet the code is in nixpkgs
<clever>
its in the nixos manual
<clever>
Lisanna: i think so
<clever>
Lisanna: it uses a function inside of nixpkgs to do the work
<clever>
pikajude: what is the root .drv after it does all the evals?
<clever>
pikajude: what does "du -h" say?
<clever>
pikajude: do you have any src = ./. in your expression?
2018-02-07
<clever>
need context, add -C10 to the grep command
<clever>
ndrei: its only valid if its at the start of a 512 byte block, so thats a false hit
<clever>
the LUKS should be at the start of a 16 byte wide block
<clever>
that doesnt sound like it
<clever>
ndrei: take that hex number, divide it by 512, then create a partition at that sector
<clever>
ndrei: which command found it, and what exactly did it output?
<clever>
ndrei: nix-env -iA nixos.testdisk && man testdisk
<clever>
ndrei: id just leave the grep running longer
<clever>
some filesystems will unsparsify when copying between them
<clever>
i think the nixos config doesnt force a redirect for the .well-known directory?
<clever>
ndrei2__: is there still a partition at the offset for the ntfs fs?
<clever>
ndrei2__: and alt+f1 lets you watch the grep again
<clever>
you have to read fdinfo to get the info
<clever>
watch -d cat /proc/1417/fdinfo/3
<clever>
this will let you see the progress
<clever>
ndrei2__: ls -l /proc/1417/fd/, which symlink is pointing to the nvme drive?
<clever>
ndrei2__: what PID is the grep process?
<clever>
ndrei2__: alt+f2 to change to tty2
<clever>
ndrei2__: what PID is the grep process?
<clever>
ndrei2__: one sec
<clever>
ndrei2__: ah, that complicates things then
<clever>
ndrei2__: do you know how big that filesystem was?
<clever>
ndrei2__: what was using the 0 to 40% range?
<clever>
and how big it is
<clever>
ndrei2__: depends on what position you put the luks partition at
<clever>
Ndrei2: divide by 512 i believe
<clever>
i can confirm that my luks starts with that header
<clever>
[root@system76:~]# hexdump -C /dev/nvme0n1p2 | head
<clever>
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
<clever>
Ndrei2: allowing the partition editor to use the same alignment it previously used
<clever>
Ndrei2: you can also try creating the 1st /boot one overly large, then use mount -o ro to find its real size, remake it at that, then make another after it, overly large, repeat