<clever>
balsoft: what about `docker run -it --rm <image> bash` without a /bin/ ?
<clever>
balsoft: what exactly is failing? at which step?
<clever>
balsoft: how exactly does it not work?
<clever>
(linux works just fine though)
<clever>
but darwin lacks the usb drivers for its own touchpad mouse!!
<clever>
you can hotwire it to force it to stay in usb mode
<clever>
the problem, is that the spi traces are more likely to get water damage, downgrading it to usb only mode
<clever>
evelyn: but when in the os itself, it switches to a custom spi device, to get the full feature set out of the touchpad
<clever>
evelyn: in early boot, its a usb device, so it can work in the bios
<clever>
evelyn: ive heard (from lous rossman) about how funky the apple touchpad is
<clever>
Shouou: also, you dont want to use $src in the installPhase, the source has been copied to . for you
<clever>
Shouou: you want to use pkgs.fetchzip, the builtin fetch functions can be impure
<clever>
or for testing, just `cd /home/bob/nixpkgs ; nix-build -A ipfs-cluster`
<clever>
thats a package, so you want to use an overlay to do `ipfs-cluster = self.callPackage home/bob/nixpkgs/pkgs/applications/networking/ipfs-cluster {};`
<clever>
lordcirth_: the modules all live under nixpkgs/nixos/modules/
<clever>
lordcirth_: that file is not a nixos module
<clever>
and just chainload the windows mbr via grub
<clever>
so i was trying to keep the windows disk un-mutilated
<clever>
tyrion-mx: nixos has its own dedicated disk
<clever>
tyrion-mx: and now that ive poked around at the bootinfo script you linked, i notice, my nixos was configured to overwrite the windows MBR with grub!
<clever>
tyrion-mx: and you can just mount everything to the right place again, and re-run nixos-install, to repeat that
<clever>
tyrion-mx: when you run nixos-install, it always forces the bootloader to install
<clever>
tyrion-mx: its probably a bug in grub-install then, generating the wrong commands for grub to run on bootup
<clever>
tyrion-mx: if its set to "nodev" then it wont update the MBR
<clever>
tyrion-mx: boot.loader.grub.device must be pointing to the device you want grub installed on
<clever>
tyrion-mx: also, you would remove the whole initrd.keys.gz part, because /boot is now plaintext, and there is only one pw prompt to deal with
<clever>
just mount nvme0n1p1 to /boot instead of /boot/efi, and remove efiSysMountPoint from the config, and it should work
<clever>
tyrion-mx: and if you need a plaintext for /boot/efi, you might as well just make /boot plaintext
<clever>
tyrion-mx: ive seen others having trouble with luks + lvm for /boot/
<clever>
tyrion-mx: any lvm in the mix?
<clever>
tyrion-mx: do you have a non-encrypted /boot ?
<clever>
sphalerite: i think its something wonky with my binary cache, either cachecache or binary-cache-v6.sqlite, restarting and deleting them fixes it
<clever>
xwvvvvwx: the sub-commands of `nix-store --query`, which are all in the man page
<clever>
sphalerite: any idea how i can get this, after doing a `nix-build` on a nix expr?
<clever>
don't know how to build these paths: /nix/store/5ygl2l9m8h30p2ysc4p2alf5dv6spzp8-time-units-1.0.0-lib-time-units-doc
<clever>
s/also/algo/
<clever>
the exact also, is that nix-env will recursively search ~/.nix-defexpr/ until it either finds foo/default.nix or foo.nix
<clever>
and then create an entity named foo
<clever>
but you can still point a defexpr to that subtree, so nix-env can find it easily
<clever>
edef: nix-env -iA foo.hello will now work
<clever>
CGevo: the tar needs a default.nix in the root of it, that should return an attribute set
<clever>
and then each of those derivations, will do a make level -j, which runs that many gcc's
<clever>
nix level -j, will build that many derivations
<clever>
nix also complicates things, by having parallel in parallel
<clever>
yeah, the -j8 part is just to speed things up a bit, since -j1 will be slower
<clever>
the uid that owns that dir, is the uid that also owns the build processes
<clever>
the derivation name is in the temp dir name
<clever>
`ls -ltrh /tmp/`
<clever>
it can be tricky to tell which thing is in which build
<clever>
so you can do an un-restricted gc, of everything the build doesnt need
<clever>
also, if you do a GC while the build is running, it cant delete anything the build needs, or will need in the future
<clever>
then do it again with -j1, to see the errors, without it being in parallel
<clever>
that hides all logs, builds 8 at once, and keeps going when things fail (build whatever it can build without the failures)
<clever>
thats why i tend to start with `-Q -j8 --keep-going` (assuming 8 cores)
<clever>
it was building 2 things in parallel
<clever>
if you force the same failure for QT, you can see what dependended on qt
<clever>
then nixos-system depends on linux
<clever>
directly after, by 1 line
<clever>
and after that
<clever>
and what is nix printing after that?
<clever>
hpfr[m]: bit tricky to see that, but if the build fails (kill a pid within that build), it will say what else is failing due to deps not building
<clever>
any dependencies built along the way are un-rooted
<clever>
only the main thing you pointed nix-build to will get a result link
<clever>
a failed build wont create a result link
<clever>
hpfr[m]: --query --roots will point to eithe result symlinks from nix-build (decide if you want to keep it, and rm the symlink), or generations in a profile (--delete-generations from before)
<clever>
hpfr[m]: that lets you exclusively target the things that will give you the most space
<clever>
hpfr[m]: another trick, use `ndcu` on `/nix/store` to find the fattest thing, then `nix-store --query --roots /nix/store/fat-boy` to find out why it cant be GC'd, deal with those roots (depends on what they are), and `nix-store --delete /nix/store/fat-boy`
<clever>
`nixos-rebuild` is what updates the grub menu, and it looks at the `--list-generations` to see what should be in the menu
<clever>
also, grub wont update until you next do `nixos-rebuild`
<clever>
hpfr[m]: also, if either of these symlinks point to the old nixpkgs rev, you cant fully GC that old version, and may need a reboot before you can GC more
<clever>
[root@amd-nixos:~]# ls -l /run/booted-system /run/current-system
<clever>
and then a `nix-collect-garbage` (with optional --max-freed) must follow, to actually delete the things that have recently become garbage
<clever>
and yes, it will need root to modify the system profile
<clever>
they only differ in config files (and any changes you did to overlays)
<clever>
if they all share the same nixpkgs rev, then 99% of the software in those generations is shared, so you wont gain much from deleting one
<clever>
thats one of the examples from the man page
<clever>
$ nix-env --delete-generations 3 4 8
<clever>
so you still have some undo choices, if you notice things went horribly wrong
<clever>
while keeping the ones that do share a nixpkgs (the last 8 that are on f0fec244ca3)
<clever>
while reading the output from ls, and manually doing --delete-generations, lets you get rid of things that use a different nixpkgs (wont share much, and will gain more space)
<clever>
`nix-collect-garbage -d` is a bit of a nuclear option
<clever>
it just deletes all generations
<clever>
if ran without root, it cant delete generations for system
<clever>
`nix-collect-garbage -d` will just delete every old generation, for profiles it can write to
<clever>
hpfr[m]: oh, and you should also look into deleting old generations, one min
<clever>
hpfr[m]: it runs nginx, proxies a dozen subdomains and directories out to the various machines in the house, tftp for network booting, including netbooting rpi's, it runs a teamspeak server, a full hydra server
<clever>
hpfr[m]: would you run pfsense on this beast? :P
<clever>
hpfr[m]: i use the none backend to manage both my nas and router
<clever>
hpfr[m]: nixops will also automate building nixos on one box, and then deploying it to another, so you could use that too
<clever>
(though it may also use a different glibc, and take up more space)
<clever>
it wont obey the nixpkgs/overlays/config on the surface, but those dont matter much for ncdu
<clever>
`nix-build '<nixpkgs>' -A ncdu` to build it anywhere, then `nix-copy-closure` it over to the surface
<clever>
and if both ends are x86, for something simple like ncdu, you can skip half of that
<clever>
hpfr[m]: `nixos-rebuild dry-run` will print the .drv file you need
<clever>
then `nix-copy-closure /nix/store/foo --from user@host` or `nix-copy-closure /nix/store/foo --to user@host` to copy the product back
<clever>
then do `nix-store -r /nix/store/foo.drv` to build it on that other box, it will print a storepath at the very end
<clever>
hpfr[m]: you can use `nix-copy-closure /nix/store/foo.drv --to user@host` to copy a .drv file to another box
<clever>
hpfr[m]: arm?
<clever>
hpfr[m]: do you have another nixos machine with the same cpu arch handy?
<clever>
hpfr[m]: c: why is it building both a kernel and qt? is the cache setup broken?
<clever>
hpfr[m]: b: why is it building a kernel? temporarily switch to a kernel in the cache?
<clever>
hpfr[m]: a: comment out everything that depends on QT, so it wont build QT
<clever>
repeat until it does fit!
<clever>
and maybe it will fit in the space thats left
<clever>
the NEW build will be smaller
<clever>
remove it from configuration.nix, and rebuild
<clever>
if it fails, gc a bit, remove something else, try again
<clever>
so i had to keep removing software, until the new build fit
<clever>
i once ran into a problem on my netbook, where i just plain didnt have enough room to hold 2 generations of nixos
<clever>
hpfr[m]: you may have had enough garbage laying around, when you started, that you could delete enough to make things fit, how big is the disk and how much is free?
<clever>
so you have to start over with the downloads
<clever>
also, if you dont restrict the deletions, it will delete everything you jsut downloaded and compiled
<clever>
so you need to delete a small amount first
<clever>
when low on space, you can sometimes run out of space while deleting things
<clever>
Flambe: you must use nix-shell when compiling anything, installing make and gcc wont work
<clever>
,
<clever>
,nix-shell Flambe
<clever>
Flambe: what exactly is the error you are having?
<clever>
Flambe: do you have cmake in the nativeBuildInputs ?
<clever>
wedens[m]: so it can offload work to other machines, if configured to
<clever>
wedens[m]: nixops will try to just build it on the machine running nixops, but it will obey any build machines configured in /etc/nix/machines
<clever>
if you have keys loaded into your ssh-agent (via ssh-add) that can access root on the machines, those will also work
<clever>
wedens[m]: but once copied, its fairly safe to run independant copies of the state, with the none backend
<clever>
wedens[m]: oh, and the only other issue is the auto-generated keys, you should at least copy the state (or export | import) to sync those keys up
<clever>
but that url itself is held in the state file, so you still need to keep that in sync
<clever>
wedens[m]: `nixops create -d house house.nix -I nixpkgs=https://github.com/nixos/nixpkgs/archive/dae9cf6106d.tar.gz` (which can be modified with `nixops modify`, see line 2), lets you override that
<clever>
wedens[m]: just be aware that nixops will (by default) obey the <nixpkgs> and $NIX_PATH on the host, so you may cause wonky upgrades and downgrades as you roam about
<clever>
wedens[m]: as long as you can ssh to the targets, you can deploy nixops from any machine
<clever>
wedens[m]: nas.nix and router.nix (lines 11/15) are then normal nixos configs
<clever>
wedens[m]: line 10-13 defines the nas, 14-18 the router, 12/16, what IP nixops should ssh into
<clever>
wedens[m]: basically, just `nixops create -d house house.nix` and then `nixops deploy -d house`
<clever>
wedens[m]: nixops will then auto-generate its own ssh keys, and let itself in
<clever>
wedens[m]: you only need to mess with keys/passwords the first time you deploy
<clever>
wedens[m]: i use nixops to manage several machines in my house
<clever>
red[m]: you can also run `nix-shell /nix/store/whatever.drv` to get a shell inside that drv, then do the usual `unpackPhase ; cd $sourceRoot ; configurePhase ; buildPhase` to reproduce
<clever>
so you can skip directly to trying to reproduce!
<clever>
that will force it to build that drv again
<clever>
red[m]: another useful trick, nix clearly tells you the path to the .drv that failed, and its exit code
<clever>
red[m]: i tend to first do `-j 8 --keep-going`, so it builds anything that it can build, then repeat with `-j 1`, and the only things it can pick from, are those that have failed before
<clever>
you could even port-forward it at the router, if you wanted to
<clever>
when using bridging, the guest will basically be another machine on the LAN, it will get an ip from the router via dhcp, and all ports will be open to anyone on the LAN
<clever>
gyroninja: `-netdev bridge,br=br0` is the simplest, it will generate a tap interface, then enslave it to br0, but you must first configure the host to create br0, and to enslave your real NIC to br0
<clever>
gyroninja: i believe `-net tap` will create a tap device, and then you need to supply bash scripts that will bring the interface up and make it actually work
<clever>
if you want to forward everything, then you need tun/tap or a bridge, which will require root when launching qemu
<clever>
then look at the simple-test.nix above
<clever>
gyroninja: but the example in `simple-test.nix` above will forward port 2200 to 22 in the guest
<clever>
gyroninja: by default, `-net user` only allows outgoing traffic