2019-07-14

<clever> yep
<clever> efiInstallAsRemovable = true; is required if efi vars are not available
<clever> you must boot via efi to configure efi vars
<clever> your trying to configure it to both legacy and efi at the same time
<clever> oborot: then you want device = "nodev";
<clever> oborot: does sda have a bios boot partition?
<clever> device = "/dev/sda";
<clever> oborot: the only problem i can see is that the uuid isnt set correctly for the luks device, but it is the right uuid
<clever> oborot: the uuid for / is correct
<clever> nixos cant find it with only a uuid and nothing else
<clever> oborot: and the luks uuid, should be in the form you have commented out
<clever> oborot: what is the uuid for sda1 and vg-root?
<clever> oborot: and what uuid is nixos-generate-config giving wrongly?
<clever> oborot: what exactly did mount say for those 2 devices?
<clever> and what does blkid /dev/sda1 say?
<clever> why is it showing 2 devices?
<clever> blkid /dev/mapper/vg-root
<clever> oborot: mount | grep mnt
<clever> oborot: what does mount say is at /mnt ?
<clever> oborot: did you run nixos-generate-config with the right --root, after mounting the rootfs?
<clever> oborot: it should be the uuid of the filesystem inside the luks, not the luks device itself
<clever> oborot: yeah, that should use the uuid
<clever> oborot: ^^
<clever> orivej: boot.loader.grub.device ?
<clever> mostly personal preference
<clever> not very often
<clever> hyper_ch: what part should i look at?
<clever> hello
<clever> then you just need to tell the bios what to boot
<clever> so the legacy MBR works, and the efi binaries in the ESP work
<clever> if you set both boot.loader.grub.devices and enable efi support, then grub installs both at once
<clever> for extra redundancy, you can do both efi and legacy
<clever> both will work the same
<clever> i dont really trust grub's zfs support, so i always make /boot either fat32 or ext4
<clever> grub can do the same thing, with both efi and legacy
<clever> and then you can put kernels there, and the bootloader wont need to know zfs
<clever> any time your doing efi, you must have a vfat ESP, that is in cleartext
<clever> systemd-boot doesnt support zfs
<clever> efi fails at a lot of things
<clever> systemd-boot is efi only
<clever> boot.loader.grub.devices is legacy boot only
<clever> systemd-boot doesnt have very many options
<clever> correct
<clever> but only grub supports it
<clever> it names the files specially, so it works without efi vars
<clever> boot.loader.grub.efiInstallAsRemovable is what i would use in that situation
<clever> so if that partition is lost, efi cant find the bootloader
<clever> the efi vars contain the gpt partition uuid for the efi system partition
<clever> adamantium: nixos-rebuild switch --install-bootloader
<clever> oborot: so your better off just doing a legacy grub install
<clever> oborot: i think adding uefi to coreboot would require reflashing the coreboot image
<clever> but not-os is booting under qemu x86 on my hydra
<clever> not recently
<clever> so i can now make nixos services run together in a docker image
<clever> i also recently made some nix code, to run systemd.services entries, under runit, under docker
<clever> i was trying to make a minimal image, without systemd
<clever> yep
<clever> yep
<clever> so once you can ssh into the machine, simply run justdoit, and it does it
<clever> and it will bake those options into a shell script called justdoit
<clever> aveltras: it defines some options, which you can set in kexec/configuration.nix
<clever> aveltras: justdoit, in the kexec directory
<clever> aveltras: you could even do it from the rescue environment
<clever> aveltras: yeah, it can be done on any machine with nix installed
<clever> aveltras: nope
<clever> ive not experimented with the cheaper options much
<clever> ah
<clever> packet.net has an option to install nixos for you
<clever> aveltras: what special needs do you need at install time?
<clever> for baremetal, i'm using OVH and packet.net
<clever> aveltras: yeah
<clever> aveltras: and youll want to make sure your ssh key is in configuration.nix
<clever> aveltras: check session.md for an example of how it works
<clever> aveltras: yep

2019-07-13

<clever> aveltras: kexec is your simplest option
<clever> ah, i'm using x11
<clever> try changing focus style back to normal just to see what happens?
<clever> that part works for me
<clever> so when you right click, you have to quickly move the mouse to where the menu will be, or it closes itself
<clever> alexarice[m]: when steam itself gets focus, it cancels the right click menu
<clever> alexarice[m]: do you have your window manager set for focus follows mouse?
<clever> oborot: the same way you installed, nixos-install --root /mnt/
<clever> oborot: if you mount the right things and re-run nixos-install, it will only change what has been modified
<clever> oborot: or just reboot and go into the bios
<clever> oborot: hwclock and date are the only commands you need, check their man pages
<clever> bbl
<clever> Thra11: nix-store --query --roots /nix/store/path
<clever> oborot: fix the date, then `rm ~/.cache/nix/binary-cache*` and try again
<clever> oborot: it thinks the ssl certs have expired, so it doesnt trust any website!
<clever> oborot: yes
<clever> oborot: what does `date` say the date is?
<clever> oborot: you should look into why ssl is broken before continuing
<clever> oborot: that sounds like the binary cache is broken, so its trying to build EVERYTHING from source
<clever> oborot: re-run nixos-install, it will go directly to the failing part
<clever> oborot: what is the error above that?
<clever> ajs124: yeah
<clever> ajs124: yes
<clever> why-depends needs a finished build
<clever> Thra11: on failure, it will be a single path from the failure to what you requested
<clever> Thra11: when the build fails, it gives the whole dependency chain

2019-07-12

<clever> colemickens: tree doesnt follow symlinks, so thats not complete
<clever> timokau[m]: your welcome
<clever> timokau[m]: same :P
<clever> eval-time problems are trivial compare to darwin-only build problems
<clever> it has had 13 revs left for hours
<clever> and this is the 2nd python thing i'm bisecting now, the other one is still stuck in mass-rebuild territory :P
<clever> Bisecting: 13 revisions left to test after this (roughly 4 steps)
<clever> who wants to make a PR? :D
<clever> and as a result, the $out depends on how you fetched nixpkgs
<clever> so it inherits the wrong version
<clever> and they forgot a rec
<clever> somebody put an override in, that does inherit version;
<clever> aha
<clever> timokau[m]: ive yet to use `git bisect run`, lol
<clever> 28554b17a93db76db7b303a7808e57a3f0c6babb is the first bad commit
<clever> Bisecting: 16742 revisions left to test after this (roughly 14 steps)
<clever> its a race!
<clever> already prepared for that
<clever> "scipy-19.09pre-git.tar.gz"
<clever> [clever@amd-nixos:~/apps/nixpkgs-scipy]$ nix-instantiate --eval -A pythonPackages.scipy.src.name
<clever> yeah, i would also expect this to not do that
<clever> yeah, thats just scipy.src
<clever> pkgs/development/python-modules/scipy/default.nix: pname = "scipy";
<clever> i have a feeling something is very wrong here...
<clever> nix-repl> pythonPackages.scipy.src
<clever> «derivation /nix/store/falq08s2a2yxzw13zqfrsbg9qyy1jj7c-scipy-19.09pre-git.tar.gz.drv»
<clever> + /nix/store/r2y9igc1w62r0cql6wklmjif8b4ihdcy-python2.7-scipy-1.2.1.drv:{out}
<clever> - /nix/store/zacsph0qf2dli7lrwiab2wgdzh1vzqzz-python2.7-scipy-1.2.1.drv:{out}
<clever> timokau[m]: run `nix-store -q --binding src` on both scipy .drv files
<clever> timokau[m]: the src= on the scipy dont match
<clever> that should answer things
<clever> timokau[m]: if you are getting 2 different .drv files for the same nixpkgs rev, run nix-diff on both drv files
<clever> timokau[m]: so, uhhh, what was the original problem? lol, i didnt see it
<clever> infinisil: maybe
<clever> used to how hydra-eval-jobset works, where -I is the only thing it can access
<clever> what does the error say?
<clever> timokau[m]: also, diff -ru between the 2 copies of nixpkgs
<clever> timokau[m]: -I . to allow it
<clever> it disables using NIX_PATH and other things
<clever> timokau[m]: its also a nix-instantiate arg i believe
<clever> timokau[m]: what is the storepath for the thing its trying to build?
<clever> timokau[m]: --pure?
<clever> timokau[m]: nix-store --verify --check-contents ?
<clever> git status?
<clever> timokau[m]: git diff --staged ?
<clever> nix-instantiate -E 'with import (builtins.fetchTarball https://github.com/nixos/nixpkgs/archive/95395fbf549908e8fe59922653e9dadd4da4792e.tar.gz) { config = {}; overlays = []; }; sage'
<clever> timokau[m]: nix-instantiate -E '(import ./. { overlays = []; config = {}; }).sage'
<clever> toppler: then have a keeper package using runCommand or buildEnv, to merge the 2 together
<clever> toppler: you could have one derivation called keeper-unwrapped, that contains just the raw game, then something like keeper-assets or keeper-map, that uses requireFile to download it
<clever> «derivation /nix/store/aivx4wy6sk1xs0w77aay923p3bx0dwrq-Nuget-3.4.3.drv»
<clever> nix-repl> pkgs.dotnetPackages.Nuget
<clever> ldlework: have you tried tab completion in `nix repl '<nixpkgs>'` ?
<clever> arcnmx: and sadly, the failure is darwin only!
<clever> arcnmx: bisect is getting stalled in some mass-rebuilds
<clever> look at the rev for nixpkgs
<clever> for both the failing and passing one, click the inputs tab
<clever> Bisecting: 574 revisions left to test after this (roughly 9 steps)
<clever> arcnmx: and with the nixpkgs rev on the green build, its in the binary cache
<clever> arcnmx: i can reproduce the failure on master
<clever> arcnmx: dont think so yet, that will just confirm it
<clever> in a checkout of nixpkgs master
<clever> arcnmx: try nix-build pkgs/top-level/release.nix -A perl528Packages.StringShellQuote.x86_64-darwin
<clever> nakkle: i usually start with pinning nixpkgs to whatever i'm currently on
<clever> sauyon: i'm not sure what the right way is to get both 32 and 64 at once
<clever> sauyon: pkgs.pkgsi686Linux is the 32bit version of nixpkgs, so pkgs.pkgsi686Linux.callPackage and pkgs.pkgsi686Linux.stdenv will just give you 32bit everything
<clever> grabb0id: that will dynamically create a wan and ipvt interface, that use vlans from the enp4s2f0 interface
<clever> that will always print it in my zone, and ignore whatever zone your in
<clever> TZ='America/Moncton' date
<clever> abathur: the TZ env var can override /etc/localtime
<clever> __monty__: --show-trace?
<clever> no-n: you generally want to do that with configuration.nix
<clever> y
<clever> abbec: possiblt
<clever> abbec: nix-instantiate the drv, then nix-copy-closure that drv
<clever> cachix does something similar, and could be used on travis
<clever> hydra knows to upload each part of the closure as it builds
<clever> abbec: ah, thats the kind of problem hydra and cachix can solve
<clever> abbec: you can run it on the main drv, and it will copy the closure for you
<clever> abbec: i think you want nix-copy-closure --include-outputs, with the .drv file
<clever> but not all of the inputs are in buildInputs
<clever> abbec: nix copy will only get the runtime deps, but not all of the build time deps

2019-07-11

<clever> spaark: not sure on the nix-channel --update problem, but you can just clone the nixpkgs repo, and `nix-env -f ~/nixpkgs -iA vim`
<clever> spaark: ahh
<clever> spaark: why are you building nix from source?
<clever> spaark: .nix-defexpr/channels is fixed the first time you run nix-channel --update
<clever> spaark: .nix-profile is automatically fixed when you firs tinstall something with nix-env
<clever> it will silence the errors about "i am aarch, but wanted armv6"
<clever> Thra11: extra-platforms in nix.conf, is a list of extra nix systems to claim suppot for
<clever> Thra11: just have to deal with the odd purity issue, and set one nix flag
<clever> $$ is the pid of busybox itself, and /proc/PID/exe shows the real binary behind a given pid
<clever> $ ls -l /proc/$$/exe
<clever> lrwxrwxrwx 1 clever users 0 Jul 11 16:00 /proc/13752/exe -> /nix/store/w4mlkxdflgrdi1cgdc3v42g9q1kmw3j2-qemu-user-arm-3.1.0/bin/qemu-arm
<clever> ./sh should then attempt to run it
<clever> Thra11: this will fetch a pre-build busybox, for armv6l and make an sh symlink to it
<clever> nix-build '<nixpkgs/pkgs/stdenv/linux/bootstrap-files/armv6l.nix>' -A busybox -o sh
<clever> Thra11: if your not running nixos on the aarch64 host, you will need to read this, and manually configure the kernel to know where qemu-user-arm is
<clever> Thra11: some aarch64 cpu's can run armv6l code natively
<clever> Thra11: and the tables at lines 6-19, plus
<clever> i can also reproduce your issue with x86-64 host
<clever> builder for '/nix/store/0c8xyv10gklav6isrib8i6chbn15l8ny-glib-2.60.3.drv' failed with exit code 1
<clever> ERROR: Got argument default_library as both -Ddefault_library and --default-library. Pick one.
<clever> Thra11: i once emulated x86_64 on a v7, lol
<clever> Thra11: ive not tried that yet, but with the right archmap, it should work
<clever> Thra11: oh, your trying to emulate v7 on aarch64?
<clever> Thra11: and there is already an entry in the overlay for aarch64
<clever> Thra11: it obeys $TMP
<clever> Thra11: emulating a 32bit guest on a 64bit host has performance costs, so its faster to do 32bit on 32bit
<clever> Thra11: it also loads the arm qemu from pkgsi686Linux, so its based on a 32bit gcc and 32bit libc
<clever> Thra11: and the arch_map converts from guest arch to host arch
<clever> Thra11: qemu's configure script has a --cpu= flag, that takes a host cpu arch
<clever> matt`: and that gets into the stdenv bootstrap stuff, which is tricky to mess with
<clever> matt`: it would also need to exclude everything ccache depends on
<clever> Thra11: building...
<clever> matt`: i think its only for use with nix-shell, to make ccache work when in a nix-shell
<clever> matt`: and the sandbox for nix wont allow it to actually access to the cache directory, so you likely wont benefit from it any
<clever> matt`: the problem, is that ccache itself is built using stdenv, so now you need ccache to build ccache
<clever> Thra11: checking...
<clever> matt`: that will just make performance worse for you, it will force nix to rebuild EVERYTHING from source, starting from gcc
<clever> Thra11: what nixpkgs rev are you on?
<clever> sbj: nix-instantiate --find-file nixpkgs/nixos/modules/installer/cd-dvd/system-tarball-pc.nix
<clever> yep
<clever> sbj: so just kill that entire line in system-tarball-pc.nix
<clever> sbj: boot.crashdump.kernelPackages was removed in oct of 2017
<clever> sbj: we must both be missing something, because kernelPackages isnt an option here
<clever> sbj: line 52 and 53 will need adjustment, to build a 2nd initrd, against the new kernel
<clever> then you can freely modify that copy to support new features
<clever> sbj: youll need to use disabledModules to disable this, then put a copy into /etc/nixos, and imports = [ ./crashdump.nix ];
<clever> sbj: dang, no, it currently just loads /run/current-system/kernel
<clever> i think
<clever> sbj: it already supports changing the kernelPackages
<clever> dminuoso: run unpackPhase
<clever> sbj: search the nixos manual for disabledModules
<clever> Zer0xp: enabling is based on the directDelivery flag
<clever> Zer0xp: no enable option exists
<clever> tjg1: basically every nixos module is an example of that
<clever> tjg1: you could also define your own helper module, that creates an inputs type, and then sets extraConfig.inputs based on the result
<clever> tjg1: the nixos module will need to be restructured to support defining inputs as its own nixos option, and can then merge multiple inputs for you
<clever> tjg1: the problem, is that only extraConfig is an option, and it doesnt support merging of any attrs below that level
<clever> Taneb: i dont think the fix has hit nixpkgs yet, so its simplest to just wait
<clever> Taneb: thats a bug that has been fixed in the latest nix
<clever> hpfr[m]: nixos also has dedicated options to set env vars for you
<clever> hpfr[m]: ive found it a bit confusing, one file is sourced on login shells, another is source for non-login shells
<clever> nix, nixpkgs, nixos, nixops
<clever> it can be confusing to have the info split over 4 manuals
<clever> when you reboot, just re-run nix-shell, make modules, and continue
<clever> then just unload and reload until it works, or the machine crashes hard due to a silly typo
<clever> dminuoso: so you just nix-shell into the kernel, make oldconfig after copying it over from /proc/config.gz, and them `make modules` to build the modules
<clever> dminuoso: just rmmod ; insmod
<clever> dminuoso: ah, you dont even have to reboot then, sometimes
<clever> dminuoso: i would just boot it under qemu in that kind of situation
<clever> dminuoso: building the package under nix-shell lets you keep the intermediate files, but it cant install to /nix/store/
<clever> dminuoso: nix cant cache a partial build, and will start over from the begining
<clever> cizra: zfs on nixos is somewhat better then other distros, the modules just automatically deal with building out-of-tree kernel stuff, and the kernel has even been patched to support zfs, which some other distros arent doing
<clever> dminuoso: thats only possible if the nix-build is running under something like screen
<clever> cizra: i also prefer zfs, because / and /home share the free space, and i dont have to resize things constantly
<clever> depends on if you want to keep some undo's available or not
<clever> `nix-collect-garbage -d` just deletes EVERY generation your not using
<clever> cizra: these 2 commands let you safely remove a single generation of system
<clever> removing generation 505
<clever> [root@amd-nixos:~]# nix-env --profile /nix/var/nix/profiles/system --delete-generations 505
<clever> [root@amd-nixos:~]# nix-env --profile /nix/var/nix/profiles/system --list-generations
<clever> cizra: so you can check each mono, and see which one you can maybe GC
<clever> cizra: another factor, is that you might have 6 copies of mono, from rollbacks
<clever> colemickens: ah
<clever> cizra: to see why a given root depends on something
<clever> cizra: and also nix why-depends /some/root /nix/store/fat-package
<clever> cizra: nix-store --query --roots /nix/store/foo
<clever> cizra: nix-store --query --tree /nix/store/foo
<clever> colemickens: also, i think you want (nixpkgs + "/nixos/lib/make-disk-image.nix") to make it obey the right nixpkgs version
<clever> pkgs/lib for ex
<clever> colemickens: make-disk-image.nix is meant to be opened with callPackage, and that will supply most of the args for you
<clever> colemickens: looking...
<clever> turion: nix-store -qR ~/.nix-profile
<clever> colemickens: how did you make it use a custom nixpkgs?
<clever> mtp76: nixos-rebuild --install-grub
<clever> mtp76: you can also force it without changing it back and forth
<clever> mtp76: if sda is using gpt, you must also have a bios boot partition, 1mb, not formated, not mounted
<clever> mtp76: if you set boot.loader.grub.device = "/dev/sda" it will install to the MBR of sda
<clever> hpfr[m]: depends on if you want to manage it with networkmanager, or raw wpa_supplicant.conf
<clever> hpfr[m]: network manager handles wireless itself, which conflicts with networking.wireless.enable
<clever> busybox is mainly just a quick&dirty way to test qemu-user
<clever> file -L sh` will show its aarch64