<clever>
haslersn: that tends to happen if you use builtins.fetchTarball during nixos-install
<clever>
yeah
<clever>
pointfourone: they remain in the store, and you can use rollback or absolute paths to access them
<clever>
pointfourone: they are only removed from the newly made generation of the profile
<clever>
steveeJ: hh
<clever>
pointfourone: nix-env can only have one version of emacs installed in the profile at once, but several emacs can live in /nix/store
<clever>
steveeJ: you may need to mount /proc
<clever>
pointfourone: and you can use that path to run that version, at any time
<clever>
pointfourone: if you run `realpath $(which emacs)` you can see the absolute path for emacs
<clever>
alex``: nix-locate is the backend for that, and bash has a command-not-found script somewhere that runs it
<clever>
pointfourone: when you install or remove anything with nix-env, it keeps the old profile, and you can use `nix-env --rollback` to undo the last operation
<clever>
pointfourone: rollbacks and generations already do exactly that
<clever>
pointfourone: the conflicting version stuff only really plays nicely when dealing with multiple users, or in the build or shell environments
<clever>
pointfourone: yeah, it wil likely fail because there are 2 binaries with the same name in the profile
<clever>
steveeJ: cant remember off the top of my head, check the stage-1-init.sh in nixpkgs
<clever>
pointfourone: that is one thing it can be used for
<clever>
pointfourone: nix run or nix-shell would be better for that i think, since nix-env will have collisions on the binaries
<clever>
pointfourone: why do you want to install both?
<clever>
pointfourone: all nix-env operations are atomic, if the command fails, it will not make any changes to the profile
<clever>
EternalZenith: youll probably want to file a pr then, once you find out what special stuff it needs
<clever>
steveeJ: you may need to run something like udev trigger or settle to update /dev/
<clever>
you need to use nix-user-chroot and/or nix-bundle
<clever>
so /nix itself, along with profiles and the db are missing
<clever>
i checked `mount` while inside the above `nix run` sandbox, and it only mounted /nix/store
<clever>
so even if you fool a setuid binary with a fake /etc/shadow, it gains you nothing
<clever>
so setuid binaries are not actually getting root
<clever>
which means the uid 0 inside the namespace, isnt the real root
<clever>
wdanilo: using mount namespaces without root, requires you to also use a user namespace
<clever>
mount namespaces and usernamespacing
2018-09-21
<clever>
id checkout a copy of nixpkgs matching nixos-version, and then just edit the expression to add --enable-debug
<clever>
all i can think of then is to head off to #zfs or #zfsonlinux
<clever>
did you hear about the 0.7.10 issue?
<clever>
what version of zfs did you previously run?
<clever>
more strongly then -f
<clever>
-F forces it to import
<clever>
infinisil: what about with -Fn ?
<clever>
ive even used it to inspect vdev's i have entirely removed from the pool
<clever>
infinisil: that shows metadata about a vdev, even if you dont import it
<clever>
infinisil: zdb -l /dev/mapper/root
<clever>
infinisil: nope, but i have used zdb a bit, one min
<clever>
catern: it may work
<clever>
probably
<clever>
so it wont use non-nix libraries
<clever>
the nix provided gcc has been modified to not look in /usr/lib and friends
<clever>
which discards a lot of the trash not needed in an initrd
<clever>
and runs patchelf on all files, to point them to that new derivation
<clever>
rather then depend on all of glibc in the initrd, it copies libc.so to a new derivation
<clever>
the nixos initrd is even doing a form of that
<clever>
yeah, you can use patchelf to un-nix the files
<clever>
but lack GC roots, so they can even break locally if you garbage collect
<clever>
nix-shell products still refer to the store in the same way
<clever>
even the ld.so in dynamic elf files is in the nix store
<clever>
catern: the ELF files nix will produce refer to /nix/store/ and will break when copied to another machine manually
<clever>
betaboon: the fs will resize itself
<clever>
betaboon: nixops cant resize an EBS, you need to go into the aws console and resize it there, then reboot the machine 1 or 2 times
<clever>
betaboon: disk size is unrelated to the instance type, you can freely resize the disk
<clever>
betaboon: disk or ram? which hoster?
<clever>
betaboon: try just installing ncdu, and running `ncdu /nix`, what is the largest path?
<clever>
old generations
<clever>
betaboon: because you already ran it with -d, it deleted all garbage and generations
<clever>
ah good idea, optimize should work even with a full disk
<clever>
betaboon: what happens if you just run `nix-collect-garbage` with no args?
<clever>
rauno: its a bug in the detection code, not dealing with symlinks under a chroot
<clever>
rauno: tell it to continue even though it doesnt exist
2018-09-20
<clever>
gamble: continue, and treat it as a bios machine
<clever>
resources is also part of nixops
<clever>
but some args like nodes are specific to nixops
<clever>
jackjennings: in the nixos docs i believe
<clever>
and the error will then guide you towards finding at least the name of each
<clever>
jackjennings: if you omit the ..., then it will fail for any args you didnt name
<clever>
with older bios's, the bios boot partition has to be near the start of the disk
<clever>
LnL: from my undestanding, with grub, it will just load and execute the blob in the first 512 bytes, which must then be able to read the stage 1.5 in the bios boot partition
<clever>
my desktop is also rather dumb, it ran a .efi file on a vfat, that i forgot to tag as the ESP
<clever>
Dezgeg: oh, you mean the bios is too smart, and refuses to run the MBR in the gpt disk?
<clever>
gpt is still an option with legacy, just need a bios boot partition, 1mb, no fs, not mounted
<clever>
simplest thing is to just say "screw efi" and do a full legacy install
<clever>
if you booted in legacy mode, then you cant modify the efi vars, so a normal efi install wont work
<clever>
uefi is always a gamble, you never know what your going to get
<clever>
and now windows cant chainload from grub
<clever>
i recently switched my desktop from legacy to efi
<clever>
i'm also fighting my own boot issues here
<clever>
yeah, that sounds like it should help
<clever>
my desktop only has the M$ key or off
<clever>
my laptop gives me full control over secure boot
<clever>
colemickens: there is one that entirely ignores the efi vars, and only boots the path windows puts the binary at
<clever>
colemickens: some bios's are stupid
<clever>
gamble: i found you have to disable uefi entirely to boot legacy, on some machines
<clever>
colemickens: nuke ~/.cache/nix on root
<clever>
gamble: you need to just write the image directly to the usb in dd mode
<clever>
gamble: the iso file is already a valid usb image, and tools like rufus tend to break it
<clever>
grep all of the narinfo files you have for the name of the missing file
<clever>
ah
<clever>
colemickens: nix will cache the existance of things locally, and try to download them later
<clever>
colemickens: oh, and if you delete anything from the cache, bad things happen
<clever>
and it declares the hash to be the same as the name of the .nar.xz