<clever>
the kernel/initrd itself, comes from the netboot utils, which packages the whole rootfs up as a squashfs inside the initrd
<clever>
so you dont even need a working kexec installed on the victim
<clever>
in this case, its the closure of a shell script, containing kexec, a kernel, and an initrd
<clever>
patagonicus: the kexec stuff is a multi-stage trick, make-system-tarball.nix generate a tarball with a complete /nix/store containing the closure of anything
<clever>
wipe the disk and install as usual, like you used a livecd
<clever>
build a magic tarball on one machine, unpack it on the un-suspecting victim, and run /kexec_nixos, and boom, your now running nixos entirely from ram
<clever>
it lets you repartition the disk, and do anything
<clever>
justdoit and my kexec tool is more powerful then nixos-infect
<clever>
if you have control of the vm, you can create an entire virtual disk just for swap, and then you can freely throw it out and replace it with a bigger one
<clever>
a swap partition is better performance
<clever>
if you didnt have a dedicated partition
<clever>
and nixos will auto-create the file and swapon for you
<clever>
you can set swapDevices = [ { device = "/path/to/file"; size = 1024; } ];
<clever>
swapDevices.*.size
<clever>
?
<clever>
yep
<clever>
and nixos-generate-config will add the swap to hardware-configuration.nix
<clever>
ah, that works too
<clever>
[root@amd-nixos:~]# man configuration.nix
<clever>
you can add your own too, one sec
<clever>
`free -m` ?
<clever>
how much ram does this poor thing have??
<clever>
slap some swap on that sucker
<clever>
so its never actually rebuilt
<clever>
your nixos-rebuild was likely dying the same way
<clever>
check dmesg
<clever>
it should be the same as `nixos-rebuild build`
<clever>
what if you `nix-build '<nixpkgs/nixos>' -A system && ls -l result` ?
<clever>
what does `which --all weechat` say?
<clever>
nix-env can never appear in that list
<clever>
nope
<clever>
monokrome: if you run `nix repl '<nixpkgs/nixos>'` and then eval `config.environment.systemPackages`, do you see weechat?
<clever>
now try rebooting, and see if it stays the same or not
<clever>
what does `ls -l /run/current-system` report?
<clever>
that is also valid
<clever>
then you can see whats behind nix-env
<clever>
`which --all weechat`
<clever>
mount boot to the right place, nixos-generate-config, and then nixos-rebuild switch
<clever>
does weechat appear in $PATH when you nixos-rebuild switch, and DONT reboot?
<clever>
if /boot isnt mounted when you run switch, then a reboot will basically be a rollback
<clever>
if the packages are already built, it will reuse them
<clever>
ixxie: hydra.iohk.io's cache, but if you dont have the public key in your end machine, then that wont really impact things
<clever>
ixxie: the only real problems it has right now, is no config (upstream is always iohk + nixos), and no gc policy (i just randomly rm -rf the whole cache dir, whenever i want more space)
<clever>
ixxie: and on a 6 month scale, its almost 50/50, so its halving my download requirements
<clever>
ixxie: cachecache also includes prometheus exporters, which report that i have had a total of 5.3gig worth of misses, and 4.5gig worth of hits in the last week
<clever>
Ke: id say pin, but also test the latest regularly, and keep the pin moving
<clever>
ixxie: its currently chewing up 39gig on my nas, and lets me re-fetch things at full gigabit speeds
<clever>
[root@nas:~]# df -h /var/lib/cachecache/
<clever>
Filesystem Size Used Avail Use% Mounted on
<clever>
if you instead want nix to build it for you, and to just run it directly in the shell, you want:
<clever>
both, will give you an env suitable for building the package
<clever>
or if it needs callPackage, `nix-shell -E 'with import <nixpkgs> {}; callPackage ./package.nix {}`
<clever>
Ke: `nix-shell package.nix`
<clever>
zfs dedup is block level, and complicated by compression and encryption
<clever>
`nix-store --optimize` is a far cheaper file-level dedup
<clever>
yeah
<clever>
mayhew: zfs would only do it if you turned the dedup flag on before you did all of those --update's
<clever>
mayhew: `nix-store --optimize` will hardlink all of the duplicate files together, so they dont consume as much space, and the normal flags in `man nix-collect-garbage` can delete old generations, allowing gc to clear it up fully
<clever>
mayhew: based on the URL's in `nix-channel --list`
<clever>
winsome[m]: stangely, that commit is newer then where zsa got added, but is lacking the file, try switching to nixos-unstable to est that out?
<clever>
Date: Mon Jan 18 09:16:22 2021 +0000
<clever>
[clever@amd-nixos:~/apps/rpi/nixpkgs-test]$ git show 88f00e7e12d
<clever>
cat: nixos/modules/hardware/keyboard/zsa.nix: No such file or directory
<clever>
xwvvvvwx: i'm guessing that systemd may have been patched by nixpkgs, to look in a different place, the nix expr would be the next place to look
<clever>
[5828811.752095] mmc0: cannot verify signal voltage switch
<clever>
ixxie: watch `dmesg -w` output when you plug a card in, does it say anything?
<clever>
ashkitten: either set it to some context-specific no-op value ({} or null or []), or use lib.filterAttrs to remove it afterwards, or use lib.filterAttrs/filterAttrsRecursive to remove every attr with a magic value (such as null)
<clever>
yeah
<clever>
karantan: all nixos modules get passed the same args, the usual ones are config, pkgs, lib, and i think options, but others can be dynamically added
<clever>
karantan: i prefer pinning it within the project like that, so if others clone the project, they get the nixpkgs that i know worked
<clever>
which is the nixos channel on root by default
<clever>
karantan: its the nixpkgs= from $NIX_PATH
<clever>
not sure then
<clever>
lovesegfault: try without -d?
<clever>
lovesegfault: got an example of one from `ls -l` ?
<clever>
angerman: once those graphs are working, you can get concrete numbers for if a given change helps or hurts the eval
<clever>
`nix-collect-garbage --max-freed 1` would clean them up, then delete the minimum number
<clever>
lovesegfault: nix-collect-garbage cleans them up automatically
<clever>
angerman: hydra could record how much those went up, for each attr in release.nix
<clever>
angerman: nix itself, also has a wide range of performance metrics its counting internally
<clever>
angerman: then you can generate graphs like this, that show how long a given attr took to eval (not counting the shared state with other attrs)
<clever>
it doesnt default to [], there is a trick going on
<clever>
so you can have a 2nd file, that isnt managed by nix, in that env var
<clever>
angerman: but hydra is more flexible then nix itself, and can take a : seperated list of those files, allowing auto-scaling scripts to create&destroy build machines in aws
<clever>
angerman: nix.machines is what generates the contents of /etc/nix/machines
<clever>
angerman: and this will have logs from its attempts to ssh into each one
<clever>
andoriyu: check other out-of-tree stuff, to see how KERNEL_DIR gets a default
<clever>
andoriyu: probably
<clever>
andoriyu: $CC contains the name of the cross-compiler, which is already in $PATH, the nix cross-compile stuff sets all of that up for you
<clever>
but going any finer then that gets real messy
<clever>
then only the kernel&modules are native, but the rest remains cross
<clever>
andoriyu: you can get ugly, and do boot.kernelPackages = (import <nixpkgs> { system = "armv6l-linux"; }).linuxPackages; for example
<clever>
andoriyu: nix doesnt allow mixing native and cross compiled things
<clever>
andoriyu: then the problem is much deeper, you would have to see how the kernel cross-compile works, and then apply that fix to every module package
<clever>
maybe all out-of-tree cross compile is busted?
<clever>
andoriyu: double-check if you can cross compile the v4l loopback i linked earlier?
<clever>
yeah, i'm not sure whats going on there
<clever>
not sure where that problem is
<clever>
andoriyu: it must use $CC, not gcc
<clever>
sed time!
<clever>
and then THAT dir, is what is missing a Makefile!
<clever>
but its just assuming KERNEL_DIR is /lib/modules/$(uname_r)/build
<clever>
andoriyu: ah, line 37 should be respecting that
<clever>
andoriyu: i would expect that to work, though kmod isnt being used yet
<clever>
sshow: buildEnv will merge 2 packages using symlinks
<clever>
gpg is special, in that adding a key puts it into the gpg keyring, and it will persist after a reboot, which is why i also prefer it
<clever>
drozdziak1: `ssh-add -l` will list keys already in the agent, and $SSH_AUTH_SOCK must point to a socket made by gpg, like /run/user/1000/gnupg/S.gpg-agent.ssh
<clever>
drozdziak1: and sudo has a flag to leave $HOME "wrong" (pointing to your user, not root)
<clever>
drozdziak1: if nix is ran as root via sudo, it wont talk to nix-daemon, and then you can control its env vars
<clever>
drozdziak1: with the right combination of sudo flags, yes