<clever>
hooo: what error does it give when starting?
<clever>
hooo: what exactly is "ruined" with the vm now?, how is it failing?
<clever>
so its just "missing" and has to be build again
<clever>
tobiasBora: its less that it knows to rebuild, and more that if you change anything, the hash changes, and then it cant find $out in /nix/store/
<clever>
tobiasBora: the $out path is based on a hash of the .drv file, which includes every build-time input, and the recipe for building it
<clever>
gchristensen: yeah
<clever>
correct
<clever>
it doesnt care which var you got the input from
<clever>
its always a subset of all inputs
<clever>
tobiasBora: it will serialize $out into a nar, and then just search that whole blob for every hash that was in the input closure
<clever>
and generated when the build is finished
<clever>
yeah, that metadata is stored in db.sqlite
<clever>
can you pastebin the output of `fdisk -l` ?
<clever>
you can mount the existing ESP at /mnt/boot/ then
<clever>
did you make the efi system partition in fdisk?
<clever>
filesystem
<clever>
if your using efi, then it must be the efi system partition at /mnt/boot/
<clever>
mac10688: did you mount an FS to /mnt/boot/ ?
<clever>
mac10688: simplest thing is to give nixos full control of /boot/ and then use https://nixos.org/nixos/options.html#boot.loader.grub.extraentr to aextned the grub config
<clever>
and it will first search your set, then search pkgs
<clever>
the trick here, is that you can callPackage = pkgs.newScope { a = 42; };
<clever>
ah
<clever>
> (pkgs.newScope { a = 42; }).callPackage ({ a }: a) {}
<clever>
> (pkgs.newScope { a = 42; }).callPackage ({ a }: a)
<clever>
newScope is also of use
<clever>
tjay: obs and steam both work for me
<clever>
infinee: services.openssh in configuration.nix
<clever>
since the remote end has no way to ever unlock it
<clever>
i dont think it would support that mode
<clever>
hyper_ch: i suspect they share the master key then
<clever>
so you cant just run a zfs command to expose it to the world
<clever>
never revealed to the user
<clever>
pie__: the master key wont change, and it may be possible to undo a pw change
<clever>
so you may try to decrypt the wrong disk with that header, or accidentally format over it
<clever>
so there is no way to reasonably locate it, or even tell if its there
<clever>
but also, with a detached header, the luks partition wont even have a uuid
<clever>
yeah, luks has a detached header option
<clever>
and any of those passwords can unlock the master key
<clever>
rather then just storing a single encrypt(master,pw), it stores a list of them
<clever>
luks also takes advantage of that, to add more features
<clever>
seems like such an obvious problem, and no real cheap way to solve it, same reason luks has this issue
<clever>
but that doubles your usage
<clever>
and then maybe send|recv between the 2
<clever>
for zfs, you could just make a new dataset, which doesnt inherit the key from another dataset
<clever>
but that involves re-writting all data to disk
<clever>
the only solution is to change the master key at regular intervals
<clever>
yep
<clever>
pie__: when you change your passphrase, your basically just doing encrypt(decrypt(cipher,oldpw),newpw)
<clever>
pie__: the real key used for encryption of the entire disk, is encrypted with the passphrase, and stored somewhere on-disk
<clever>
and think that changing the passphrase is enough
<clever>
you may not even know such a clone exists
<clever>
and read any future data youve written
<clever>
an attacker with that initial clone, can just undo the password change next time they gain access
<clever>
ashkitten: and then 2 years more down the road (5 years after the clone), your password was leaked, and you immediately changed the phrase in zfs
<clever>
ashkitten: the problem, is what if an evil maid cloned your drive 3 years ago
<clever>
luks has the same issue
<clever>
then an attacker can undo a password change
<clever>
if you just protect the real key with a second passphrase, and your just re-encrypting it with a new passphrase
<clever>
if you change the main key, then any future data is safe, but you have to re-encrypt every single block
<clever>
ashkitten: thats the difference between changing the main key, vs wrapping the main key with a second passphrase
<clever>
they have the old master block, and can effectively undo your password change
<clever>
even if you change the password immediately
<clever>
and if your passphrase is ever leaked in the future, and the attacker has a copy of the master-key, encrypted with that, he can then break it
<clever>
if he also copied the (encrypted) master key block each time, and keeps an eye on leaked passwords
<clever>
but, the attacker would only have the cihpertext, initiallly
<clever>
reading the heckel.xyz blog
<clever>
pie__: since send|recv can cpy encrypted datasets, an attacker with physical access can clone your dataset, and use incremental sends to update his clones if he regains access
<clever>
pie__: and reveals something mildly scarry
<clever>
pie__: the master key part is very much like luks
<clever>
by default, it wont use more then 50%, and it can shrink down to as low as 32mb
<clever>
ashkitten: `arcstat.py -v` explains all the other fields
<clever>
for my system, its sitting at 1.1gig right now
<clever>
ashkitten: c is how much ram zfs wants to use, arcsz is how much its actually using
<clever>
definitely dont put a pools vdev onto a volume within the same pool :P
<clever>
pie__: no idea
<clever>
filesystems and encryption are then built ontop of that, and dont decide where to write things, just "save this block", "where did you put it?"
<clever>
if DDT is on, it does a lookup (based on hash), and may return an old location
<clever>
if DDT is off, thats the location
<clever>
you give it a block, and it returns a block-id
<clever>
also, i think the DDT operates at a low level, where you just have a raw block storage