<clever>
spotify is pre-compiled and patchelf'd, so there is no options or optional features
<clever>
infinisil: thats nixos only
<clever>
5gig free on my primary desktop
<clever>
infinisil: mine runs every day at midnight
<clever>
dtz: look up nix.gc in the docs
<clever>
symphorien: 1.11 also has `nix-store -l /nix/store/path` for successfull local builds
<clever>
jxf: you need to nix-env -iA nixos.spotify
<clever>
jxf: there is no default.nix inside .nix-defexpr, thats why it failed
<clever>
and machine1 = { ... }: hmmm, no nodes is passed to the nixos instances, not the deployment files
<clever>
infinisil: oh, i think you can cheat, nodes.machine1.config would let you store things in a random machine
<clever>
infinisil: in the example i linked, 2 files define nixos config for report-server
<clever>
but nixos definitions on each machine are merged as you would expect
<clever>
there is no way to pass sets between the files
<clever>
infinisil: it works identically to just listing several .nix files at `nixops create` or `nixops modify`, except you can manage the list with git
<clever>
infinisil: you can make a tree of deployment files with require, the same as imports, but you cant define custom options and pass them around between deployment files
<clever>
infinisil: yeah, the require trick in nixops is much more limited then imports
<clever>
infinisil: 110 instances of nixos (100 nixos containers over 10 ec2 machines) takes several minutes and several gig of ram
<clever>
infinisil: it evals all of them in the same process, one at a time
<clever>
infinisil: the memoize builtin also fixes that
<clever>
infinisil: i can only see it being useful in nixops, when you want to force all 10 machines to share a single instance of nixpkgs, so nix doesnt have to eval the same version 10 times
<clever>
blankhart: yeah, his docs suck, he never made the public key public!
<clever>
infinisil: and yeah, that attribute has no way to change service definitions
<clever>
infinisil: i think thats more about the services from <nixpkgs/nixos> expecting version A and your custom pkgs set have version B, and now everything breaks
<clever>
blankhart: yeah, you will need to either remove that binary cache, or add the caches public key to your nix.conf
<clever>
infinisil: why?
<clever>
infinisil: ah, i can see how that works
<clever>
blankhart: what is the contents of your nix.conf, and what output does nix give when ran?
<clever>
blankhart: did you add his public key to your nix.conf file?
<clever>
then you can just leave it at the current value
<clever>
fyuuri: if nothing has broken, then your probably just not using the software that is likely to break, so the new version is probably also good
<clever>
you cant
<clever>
if you want to upgrade to a new version, you need to run nix-channel --add as root, to add a new url, and give it the name nixos
<clever>
and it wont update anything
<clever>
if you mess with the stateVersion, it will break the things it was meant to fix
<clever>
things like the type of ssh host keys you had when you installed
<clever>
fyuuri: that is the version of the state on-disk, and must not be changed, and it has no effect on what version of nixpkgs you get
<clever>
but you cant declaratively control them, only use them
<clever>
fyuuri: if you have the channels on root, you can access them at <nixos> and <nixpkgs>
<clever>
fyuuri: those are channel names from nix-channel --list
<clever>
infinisil: thats likely also why inherit works inside there
<clever>
blankhart: how big is "du --max=0 shared server -c -h" ?
<clever>
greglearns: that doesnt work when using an nvme drive
<clever>
greglearns: the ami contains a 2gig disk image, on the first bootup, it has to auto-resize its own partitions and the FS within
<clever>
greglearns: i heard something about the auto-resize not supporting nvme drives at the moment
<clever>
greglearns: what does fdisk say about the root drive?
<clever>
kitttn: using small GC's like that lets you get X mb free, without destroying too much and loosing your dl cache
<clever>
kitttn: so if you do `nix-collect-garbage --max-freed 10M` it will delete 10mb worth of garbage, starting with the failed builds
<clever>
kitttn: and the garbage collector will delete those failed builds first
<clever>
kitttn: any build that fails will automatically be garbage
<clever>
greglearns: what does fdisk say about the drive?, and did you change ebsInitialRootDiskSize before or after the deployment?
<clever>
kitttn: but if you perfectly undo a change to the .nix file, the hash will match up, and nix will reuse some of the "garbage", making it not-garbage again
<clever>
kitttn: anything older then that is garbage and can be deleted
<clever>
kitttn: the last result nix-build made will be pointed to by a result symlink, which protects it from GC
<clever>
kitttn: yeah, the default is to run genericBuild, which handles unpack, patch, configure, make, and install
<clever>
kitttn: the buildInputs are flattened down to a simple string, and that string is what gets hashed
<clever>
the strings in the .nix file are part of that hash
<clever>
kitttn: every $out is unique, based on the inputs, so it will never be able to change a path that is already in use elsewhere
<clever>
kitttn: just do nix-build, it cant break things
<clever>
jwynn6: if grub was unable to read /boot, it would drop into a rescue shell
<clever>
kitttn: if you only want to read the source, you could just ls -lh $src
<clever>
kitttn: also, fetchFromGitHub does the unpacking in this case, and unpackPhase is just a recursive cp
<clever>
kitttn: its more that the directory lacks the +w bit by default, and even though you have permission to give yourself write, rm -rf cant delete it
<clever>
jwynn6: try using something like f12 to manually boot from each drive
<clever>
jwynn6: ah, then it should just work, which drive is it set to boot from?
<clever>
kitttn: chmod -R +w thatdir
<clever>
jwynn6: is legacy booting enabled in the bios?
<clever>
jwynn6: yeah, that looks like a normal grub stage 2
<clever>
jwynn6: at offset 0x120, do you see an the text from grub?
<clever>
jwynn6: hexdump -C /dev/sda2 | head -n30
<clever>
jwynn6: what partition is the bios boot partition?
<clever>
jwynn6: the strings command is part of binutils, but i wouldnt run it on a partition
<clever>
jwynn6: if you run something like this against the bios boot partition, do you see a string like 00000120 6e 67 00 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 61 |ng......Geom.Rea|
<clever>
[nix-shell:~]$ hexdump -C /dev/sde1 | head -n30
<clever>
jwynn6: and both those drives have bios boot partitions that are not mounted/formated?
<clever>
jwynn6: what is boot.loader.grub.device(s) set to?
<clever>
jwynn6: efi or legacy booting?
<clever>
nick_l: that is setting a config entry called data_subnet, so there must be a matching options.data_subnet to define its type
<clever>
nick_l: why are you using inherit then?
<clever>
nick_l: can you gist that file?
<clever>
nick_l: the config on line 15 refers to line 24, which is an empty set
<clever>
nick_l: can you gist all of the involved files?
<clever>
nick_l: quoting it breaks the path magic in nix
<clever>
nick_l: so your nixops file should look like this: { machine1 = { config, ... }: { nixos config; }; }
<clever>
nick_l: the config param is at the nixos level, not the nixops level
<clever>
nick_l: this allows most of nixos to just throw things into system.build.whatever, and then later read config.system.build.whatever in another file