<clever>
multiple starting points (hostnames), one ending point (core.nix) and many dead-end leaves (large features)
<clever>
and its sort of 2 trees weaved together
<clever>
all hostnames eventually lead to core.nix
<clever>
thats why my config forms a tree, with hostname.nix at one end, and core.nix at the other end
<clever>
yeah
<clever>
MtotheM: also, bootloader stuff isnt in the auto-generated file
<clever>
MtotheM: but you must reference that generated file, in the main configuration.nix
<clever>
and this lets me have 2 identical installs, without the different UUID's causing a conflict in git
<clever>
if the disk is lost and i have to re-install, the boot and fs stuff will be different anyways
<clever>
i prefer to have configuration.nix outside of revision control, it only does boot and fs related stuff, and imports = [ /path/to/repo/configuration.nix ];
<clever>
chiiba: the default unpackPhase will unpack $src to . for you, and cd into the directory it produced, which is writeable
<clever>
chiiba: the working directory and $out are both writable
<clever>
cant think of any thers
<clever>
numkem: i think i had to set some mime stuff in aws, cant remember
2020-06-20
<clever>
numkem: and things like ci-ops then pulls all of the otherlays together i believe
<clever>
numkem: each repo has its own default.nix, for loading a per-repo overlay, that defines the packages
<clever>
numkem: theres now one repo for each type of cluster, which may pull things from a shared repo, and also pull overlays from the repo that holds for src for each program
<clever>
numkem: and i think that gets the nixpkgs rev from niv, for most repos
<clever>
numkem: we are now using direnv to set $NIX_PATH when you cd into the right dir
<clever>
cole-h: exactly
<clever>
numkem: different repo, its now in things like ci-ops and cardano-ops
<clever>
cole-h: those arent derivations
<clever>
energizer: a: use mkForce to change the value to "", b: lookup disabledModules in the nixos manual
<clever>
yeah
<clever>
trusted users can also change it
<clever>
AmandaC: if your root, yes
<clever>
AmandaC: --option can override any nix.conf field
<clever>
jumper149: grep nixpkgs for callCabal2nix
<clever>
Baughn: ok, this is fishy, i grabbed a fresh memtest from memtest86.com, its EFI based, looks totally different, and it gets to test 4 without problems
<clever>
test0 can pass many times in a row
<clever>
test1 is fatal
<clever>
Baughn: memtest86+ 5.01
<clever>
coreboot 002
<clever>
it uses a more cpu intensive algo to decide which blocks to write to
<clever>
its rather full, why not upgrade?
<clever>
Filesystem Size Used Avail Use% Mounted on
<clever>
nas:/nas 6.6T 6.6T 17G 100% /nas
<clever>
i could just replace the failing 4tb with another 4tb, but
<clever>
Yaniel: i currently have 3x4tb, but one of the disks is begining to have write errors under zfs
<clever>
veleiro: it tries each url, until one works
<clever>
,tofu veleiro
<clever>
but now i need a sas controller
<clever>
$100 cheaper per disk
<clever>
Baughn: then discovered i had grabbed SAS disks by accident
<clever>
Baughn: i recently got 3x16tb drives to upgrade my nas
<clever>
Baughn: i want to test it a bit more first, let me try shuffling the ram around some more...
<clever>
veleiro: if you run wget on the url, and then file on the result, what does it say?
<clever>
2 hard lockups (journal just goes silent) and one general protection fault within zfs
<clever>
the system has begun having major stability problems
<clever>
yeah, and i believe i still am
<clever>
Baughn: and memtest has worked on this system in the past
<clever>
veleiro: --unpack
<clever>
6 year old system, with a mobo from 2012
<clever>
the nixos build
<clever>
Baughn: my desktop cant even run memtest now, it hard reboots itself!
<clever>
you need to run --update yourself
<clever>
so it wont fetch nixos-19.03, only nixos
<clever>
`nixos-rebuild --upgrade` only runs `nix-channel --update nixos`
<clever>
did you --update again?
<clever>
and root only uses root's list
<clever>
yeah, each user has its own channel list
<clever>
what about `nix-channel --list` without root
<clever>
then you didnt add 19.03
<clever>
jco: and `sudo nix-channel --list` ?
<clever>
jco: and what is within /nix/var/nix/profiles/per-user/root/channels ?
<clever>
jco: what does `echo $NIX_PATH` say?
<clever>
jco: did you nix-channel --update?
<clever>
gchristensen: ive been having ssh-agent trouble again lately, its disabled yet still starts, and hijacks SSH_AUTH_SOCK from gpg-agent!
<clever>
avn: but there is also some new experimental state-less stuff in nixops, which likely wont make such keys, or state
<clever>
avn: if you ignore the nixops state, then it may create new keypairs to let itself in, and change the keys when the state is lost
<clever>
but the hdd in those was too tiny to even hold 2 generations, so i retired them
<clever>
avn: the config that you deploy can still use everything nixos has, i was deploying full xfce to a pair of netbooks at one point
<clever>
when using the none backend, nixops creates its own private keypairs, and lets itself in as root
<clever>
it will ssh into the 2 IP's listed, and take deploy the config
<clever>
avn: as an example, just `nixops create -d house house.nix` and then `nixops deploy -d house` to deploy everything
<clever>
cole-h: if you treat test as a string, THEN it copies it, but if you `test + "/foo"` then you get a new path, that would only copy the foo subdir
<clever>
cole-h: test contains a path (a special type)
<clever>
cole-h: not exactly
<clever>
mtn: you often dont even need the ${, just foo = ./path;
<clever>
energizer: what does `config.services.jack.jackd.enable` say in nvm
<clever>
energizer: which rev of nixpkgs are you on?
<clever>
energizer: i can see the option when i do it
<clever>
gustavderdrache: you can still access that, nix-build '<nixpkgs/nixos>' -A vm -I nixos-config=configuration.nix
<clever>
__monty__: i have something similar
<clever>
gustavderdrache: and you cant use the existing `nixos-rebuild build-vm` stuff?
<clever>
gustavderdrache: search the scripts for qemu-img, and see where it gets the number from
<clever>
> 536870912/1024/1024
<clever>
if you read the script in result, what does it do?
<clever>
gustavderdrache: did you delete the old qcow file before booting it?
<clever>
typetetris: you can sometimes work around it by doing `cabal2nix = super.cabal2nix.override { cookie = super.cookie; };` to force it to use the old one
<clever>
typetetris: i think that can happen when callCabal2nix is using pkgs.cabal2nix or something like that
<clever>
munksgaard: the .override here might be undoing .overrideAttrs
<clever>
though i am also made out of human cells, lol
<clever>
munksgaard: yeah
<clever>
gmr: it also spams hard every time it goes down, lol
<clever>
gmr: i dont like the bridge, it leads to confusion when a user is showing as jtojnar to some, and Jan Tojnar to others, and its not always obvious the 2 are the same person
<clever>
munksgaard: just use .overrideAttrs to change the version= and src=
<clever>
jtojnar: not seeing any trace of that name on the irc end
<clever>
energizer: yeah, thats the bit that was missing, but startAt feels cleaner
<clever>
the iso will be more readonly, so you cant easily add secrets
<clever>
yep
<clever>
wedens[m]: nixos-generate-config --root /mnt will auto-detect the luks
<clever>
wedens[m]: use cryptsetup to format and open the root, then mkfs.ext4 the block device cryptsetup created (check lsblk), and then mount everything under /mnt/ as normal
<clever>
wedens[m]: if you want legacy+gpt (best compatability), make gpt with 3 partitions, 1mb bios boot partition, 512mb fat32 efi system, rest for root
<clever>
energizer: try setting startAt on the service instead, and it will auto-generate a timer for you
<clever>
marius851000[m]: that might be a bit more difficult, and is a bit of the reverse of what ive been doing
<clever>
marius851000[m]: and then i can just pkgsCross.vc4.callPackage or use things like `pkgsCross.vc4.extend overlay` or just import nixpkgs with overlays, and `pkgsCross.vc4.customStuff`
<clever>
xavierm02: and the history files in https://channels.nix.gsc.io/nixos-20.03 give you a history of past revisions the channel has been on, which are also going to be cached
<clever>
tnks_: something i often say, "luke, use the source" and "the docs can lie"
<clever>
tnks_: store-api.cc will put both options into a single list, nix-daemon.cc is doing something related to trusted users
<clever>
/home/clever/apps/nix/src/libstore/store-api.cc: for (auto uri : settings.extraSubstituters.get())
<clever>
/home/clever/apps/nix/src/nix-daemon/nix-daemon.cc: else if (setSubstituters(settings.extraSubstituters))
<clever>
tnks_: thats probably what extra-substituters is for
<clever>
tnks_: yep
<clever>
tnks_: `nix show-config` shows the result of parsing all config files and merging them as normal
<clever>
energizer: then you can check /dev/disk/by-uuid/ and /dev/sd*
<clever>
energizer: add boot.shell_on_fail to the kernel params, then you can get a shell when it does fail
<clever>
cole-h: its no longer waiting for a whole jobset or job
<clever>
cole-h: out of date, hydra now uploads everything to cache.nixos.org immediately upon the build finishing
<clever>
eyJhb: the rest is either support code to allow the above, or misc features like shutdown/terminate
<clever>
eyJhb: get_physical_spec() on line 236, will then generate a fragment of configuration.nix, that describes how to build this machine
<clever>
eyJhb: and if it has already been provisioned, the create() function will instead just modify things (such as iam instance profiles, and security groups, or cpu/ram selection)
<clever>
eyJhb: line 1213 will detect that the machine hasnt been provisioned yet (the state lacks a vm_id), and then use the aws API to provision new hw
<clever>
eyJhb: when you `nixops deploy`, it will run the create() function (line 1102) on every machine in the cluster
<clever>
eyJhb: if you try to read or write one of those params, it automatically goes to a field in the sqlite state, specific to this machine in the cluster
<clever>
eyJhb: the nixops.util.attr_property's you see on lines 109-151 are a bit confusing, those generate special objects with a getter/setter on them
<clever>
eyJhb: sub-classes of MachineState then take a MachineDefinition, and manage the actual state
<clever>
eyJhb: the sub-classes of MachineDefinition then take a subtree of that xml, and convert it into a subclass of MachineDefinition
<clever>
eyJhb: nixops will first use `nix-instantiate --eval --xml` to convert your deployment file into xml
<clever>
eyJhb: i think it was called terranix? it creates machines with terraform, but then uses the nixops "none" backend to update the nixos
<clever>
correct
<clever>
boot the iso on baremetal, set a pw, enable ssh, then tell nixops "do the rest for me"
<clever>
thats also part of the plan in my ticket
<clever>
eyJhb: partitioning and installing nixos from scratch
<clever>
but thats part of the plans in my ticket
<clever>
that feature doesnt exist yet
<clever>
yeah
<clever>
eyJhb: nixops should also automate that install step
<clever>
eyJhb: yeah, once you kexec, just wipe the partition table, and treat it like a fresh install, according to the manual
<clever>
eyJhb: pre-kexec, its only 3 commands, scp, ssh tar -x, ssh /kexec_nixos
<clever>
eyJhb: and most of the complex commands have to be ran after you kexec
<clever>
typetetris: in ghc, profiling changes the size of every single object on the heap, so everything has to be rebuilt to handle the larger objects
<clever>
eyJhb: but can cloud-init function when the hdd is still blank? or does it need an OS already installed?
<clever>
typetetris: you need to ensure nix builds all of the libraries with profiling also
<clever>
eyJhb: but the basic idea in my ticket, is to just partition, format, mount, then use `nix copy` to shove an entire closure into `/mnt`, and fixup the bootloader
<clever>
eyJhb: i'm not that familiar with cloud-init, to know what it can do
<clever>
typetetris: it can both staticly and dynamically link the haskell libs, and will usually link system libs dynamicly