<clever>
which prevents any other driver from claiming the card
<clever>
there was a kernel param to allocate it to the xen pci backend
<clever>
exactly what i did
<clever>
that was likely the legacy vesa mode drivers at fault
<clever>
EdLin: even if i blacklisted the drivers for the card, it still did it
<clever>
EdLin: rather then using old dos mode text consoles
<clever>
EdLin: thats what i was guessing, it switches to high-res graphical mode, and renders the fonts in software
<clever>
EdLin: but what is grub doing differently, that it doesnt screw things up?
<clever>
EdLin: in my case, if linux did any text mode console activity, the card was "spent" and windows refused to work
<clever>
notgne2: i had zero issues playing hot-potato with usb cards, trading it back&forth at runtime, without rebooting either os
<clever>
notgne2: also, weirdly, the gpu is the only card that gave me trouble
<clever>
zeta_0: yep
<clever>
notgne2: i was using xen at the time, which has commands to hot-add/remove pci devices, and config files to add them on bootup
<clever>
elvishjerricco: you can also `cat /proc/cmdline` to see the args it used at boot
<clever>
elvishjerricco: and if you try to `umount /iso` ?
<clever>
notgne2: you could even hotplug it between the 2 OS's, and just hit a magic button to switch to the other machine
<clever>
notgne2: if you can somehow save and restore the gpu state (or just reboot the card), then you can play hot-potato with it all you want
<clever>
notgne2: it may also vary wildly from card to card, how easily linux can undo state within the gpu
<clever>
notgne2: ive heard of per-slot reset lines, but my motherboard doesnt support it
<clever>
notgne2: that requires clearing the state in the gpu and basically soft-resetting the card
<clever>
notgne2: there was some kernel params to forcibly allocate the driver to the pci backend in xen, so the framebuffer never touched it
<clever>
notgne2: i was able to swap it, at boot time
<clever>
notgne2: so, while i can run both at once, dual-boot would be simpler and have the same stability, lol
<clever>
notgne2: also, if windows touches the gpu even once, you must reboot the entire host before windows can use it again
<clever>
notgne2: all control must be done over ssh!
<clever>
notgne2: so from an end-user viewpoint, the machine just hangs immediately after grub tries to execute the kernel
<clever>
notgne2: also, the gpu passthru required 100% banning linux from touching the gpu, not even the text mode console
<clever>
notgne2: and after increasing the size, i never got it to work again
<clever>
notgne2: i managed to just barely get it working, but accidentally made the disk only 4gig in size, so there was no room to install any games! lol
<clever>
notgne2: shortly before i got into nixos, i was looking into xen and gpu passthru, so i could boot windows, with full gfx performance, and then kill it when i didnt need it anymore
<clever>
zeta_0: i think so, try using ssh to connect to something, gpg should ask for a pw once
<clever>
then you dont have to co-operate over resources!
<clever>
kexec is just a slight change to colinux, perform a hostile-takeover, dont give it back :P
<clever>
popular*
<clever>
and when 64bit windows got populate, computers had proper virtualization extensions, so the cheat wasnt needed anymore
2019-12-11
<clever>
colinux was also 32bit only
<clever>
colinux never had smp support on the linux side, so it was limited to 1 core for linux
<clever>
WSL is just adding proper linux support to the windows kernel i think
<clever>
WSL is very different
<clever>
and windows just thinks the driver had disabled IRQ's for an abnormally long time
<clever>
then the driver undoes the take-over, and restores control back to the windows kernel
<clever>
and then linux runs for a short period of time
<clever>
but in reality, every time the "driver" gets control of the cpu, it performs a hostile take-over
<clever>
from the point of view of windows, its a driver that needs several gig of ram, and hoards the cpu a lot
<clever>
basically, it turned the entire linux kernel into a "windows network driver"
<clever>
elvishjerricco: also, colinux was a thing
<clever>
elvishjerricco: to windows, probably not, from windows, maybe
<clever>
i wanted to add linux to the M$ bootloader, so you could transition over like that, without a usb stick, and without dd'ing over the live disk
<clever>
and that is the rabbit hole that led me to learning the M$ bootloader, lol
<clever>
elvishjerricco: if another linux distro is currently working on that machine, you can just copy this magic tarball over, run 2 commands, and it will instantly be running nixos from ram
<clever>
zeta_0: you just need to add `export SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh` to your sessionCommands
<clever>
zeta_0: sounds like its working normally
<clever>
elvishjerricco: also, with kexec, you dont even need the usb at all
<clever>
zeta_0: and then do `ssh-add`
<clever>
zeta_0: for short-term testing, try `export SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh`
<clever>
zeta_0: you didnt paste any path
<clever>
elvishjerricco: thats also an option, depends on how confortable you are with grub
<clever>
zeta_0: `echo $SSH_AUTH_SOCK` ?
<clever>
zeta_0: gpg agent is listening for ssh stuff, but is SSH_AUTH_SOCK pointed to it?
<clever>
elvishjerricco: it was originally made for somebody that wanted a usb stick that can boot all the installers (multiple distro's in the grub menu)
<clever>
elvishjerricco: the rootfs is fully contained within nixos-initrd, so its always in a copytoram mode
<clever>
elvishjerricco: you then add that grub-fragment to a grub.cfg, and grub-install as usual
<clever>
elvishjerricco: if you run nix-build on this, it will generate a directory with 3 files, nixos-kernel, nixos-initrd, and grub-fragment.cfg
<clever>
elvishjerricco: the multi-boot helper i have may also work for that
<clever>
ornxka: yep
<clever>
zeta_0: 2019-12-11 19:39:28 < clever> zeta_0: 1481 is the new pid
<clever>
zeta_0: replace 2179 with the new pid
<clever>
ornxka: my fork has nix support, and if you just `nix-build -A helper`, it will generate all of the proper cross-compilers (line 3, it doesnt care which channel your on), then cross-compile the entire firmware, and generate a bash script that updates the vfat partition in your SD reader
<clever>
ornxka: currently, it only works on the rpi 1-3, and its even more baremetal then the examples, because the arm isnt online, neither is the ram!
<clever>
ornxka: if i copy that to an SD card, and rename to `bootcode.bin`, it prints hello world, from an rpi GPU
<clever>
zeta_0: then it will be saved into the gpg keyring forever, and any time an app wants to use it, gpg will ask you for the 2nd pw
<clever>
zeta_0: when you run `ssh-add` with the gpg ssh agent, it will ask for 2 passwords, first one to decrypt id_rsa, then a 2nd one, to re-encrypt it, within the gpg keyring
<clever>
zeta_0: gpg-agent can remember the gpg passphrase for a set period of time, before forgetting and asking again
<clever>
fresheyeball: the configure phase, use postConfigure = "exit 1"; to speed up iteration, and then try and figure out why cmake claims cuda is disabled
<clever>
kolaente_: we have the how, but not the why
<clever>
heh, that would explain half of it!
<clever>
kolaente_: but you simply havent updated home-manager yet
<clever>
kolaente_: its also possible that both configuration.nix and home-manager are installing the go from nixos-unstable
<clever>
kolaente_: double-check your home-manager config?
<clever>
kolaente_: but `users.users.<user>.packages in my configuration.nix` isnt home-manager, as far as i know? ...
<clever>
kolaente_: oh!, so its been installed by home-manager
<clever>
you may need to use the exact name `nix-env -q` shows
<clever>
you can use `which go` and `nix-env -q` to confirm
<clever>
nope, it should take effect immediately
<clever>
thats likely when you installed go to the user's profile
<clever>
that will show dates for each
<clever>
kolaente_: and then `nix-env --profile /nix/var/nix/profiles/per-user/user/profile --list-generations`
<clever>
yep
<clever>
kolaente_: what is the lowest <n> in the list?
<clever>
kolaente_: do you see which generation it was added at?
<clever>
kolaente_: ls /nix/var/nix/profiles/per-user/clever/profile*/bin/go
<clever>
kolaente_: yeah
<clever>
you must uninstall that copy with `nix-env -e go`
<clever>
you installed go with `nix-env -i`, so its ignoring what configuration.nix did
<clever>
yep, theres your problem
<clever>
try `command which --all go` ?
<clever>
we want the which in $PATH
<clever>
ah, thats why
<clever>
kolaente_: `which which` ?
<clever>
kolaente_: what does `which --all go` return?
<clever>
kolaente_: which user did you add the channel to? are you running `nix-channel --update` as that user?
<clever>
philipp[m]2: yep, there it is, it has an array of site-packages folders
<clever>
philipp[m]2: and what is within .psub-wrapped?
<clever>
so the PYTHONPATH persists at runtime
<clever>
does such a shell script exist?
<clever>
and something will create a shell-script wrapper, that uses the build-time $PYTHONPATH
<clever>
i think the magic, is that all inputs wind up in PYTHONPATH at build time
<clever>
mzabani: there is also `nix-channel --rollback`, since channels have their own generations
<clever>
which may be something you didnt want done
<clever>
mzabani: nixos-rebuild switch would also update the bootloader, but that also builds the current configuration.nix
<clever>
mzabani: `/run/current-system/bin/switch-to-configuration boot` will make whatever your currently running the default boot, and update the list to reflect what --list-generations prints
<clever>
mzabani: the bootloader config is not updated until you re-run switch or boot
<clever>
mzabani: do you have a large thing in /nix/store you know the path of, that you want deleted?
<clever>
mzabani: that would imply that they have already been deleted from the profile
<clever>
mzabani: which generation do you want to delete?
<clever>
but that depends on if you want to develop it more
<clever>
then nix-shell will let you build gridsync, and `nix-shell -A using` lets you use a copy nix built purely
<clever>
let foo = import ./. {}; foo // { using = stdenv.mkDerivation { name = "foo"; buildInputs = [ foo ]; }
<clever>
maybe something like this in shell.nix
<clever>
i would make it into an attribute
<clever>
exarkun: `nix-shell -p 'import ./. {}'` may also work
<clever>
exarkun: you must create another derivation, that has gridsync in the buildInputs, then nix-shell that other drv
<clever>
exarkun: nix-shell gives you a shell suitable for building gridsync, with that file
<clever>
exarkun: and do you expect it to give you a shell with a working copu of gridsync, or a shell suitable for building gridsync?
<clever>
exarkun: post the default.nix?
<clever>
exarkun: nix-shell -v ?
<clever>
keithy[m]: simplest way is to just mount it, and rerun nixos-generate-config with no args
<clever>
keithy[m]: you will want to fix hardware-configuration.nix, or bad thigns will happen
<clever>
fresheyeball: this was setting it, but the logs still said cuda not enabled
<clever>
fresheyeball: we want a `postConfigure = "exit1";` and then iterate until configurePhase says coda IS enabled
<clever>
fresheyeball: cuda isnt enabled, so cmake doesnt build c10, so cmake doesnt generate the header we want
<clever>
fresheyeball: correct
<clever>
fresheyeball: left a gist and some ideas above
<clever>
gchristensen: and ive put all changes of importance into the above gist, so the machine doesnt matter much
<clever>
gchristensen: the problem appears to be before the computation heavy phase
<clever>
gchristensen: the plan i have now doesnt require an insane core count
<clever>
fresheyeball: my current idea, is to edit it to fail after the configure script, skip the huge build, and then iterate until the configure phase says cuda is actually enabled
<clever>
fresheyeball: i can confirm that pytorch is not a split output derivation
<clever>
fresheyeball: turning on cuda support seems to slow it down heavily at the testing phase
<clever>
ive no clue how to do it purely
<clever>
samueldr: yeah, std was it, i used some impure cmd to download a build of std for windows and it just landed in $HOME
<clever>
samueldr: i basically used nix-shell to get a linux->windows cross-compiler, then used the standard rust tools to get a windows crate, and off it went
<clever>
samueldr: ive gotten it to work impurely, using rustup i think it was, in a nix-shell
<clever>
gchristensen: lol, i only have 32gig of ram each in my laptop&desktop
<clever>
fresheyeball: this will re-build it, with cuda support enabled
<clever>
fresheyeball: i'm in a screen session, `screen -x`
<clever>
fresheyeball: the race is on, can gchristensen's machine beat mine, even with a late start!
<clever>
mwdev: you should only ever use config.boot.kernelPackages within extraModulePackages
<clever>
mwdev: that might be mixing a 5.3 module with a 5.4 kernel, which will fail to load
<clever>
[1851/2983] Building CXX object caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/kernels/QuantizedOpKernels.cpp.AVX.cpp.o
<clever>
zeta_0: what error does it throw?
<clever>
mwdev: and then it gets simpler to use nixpkgs overlays, to do it in steps, one to add the linux_5_4 and linuxPackages_5_4, then a 2nd to modify linuxPackages_5_4
<clever>
mwdev: so you may want to do (linuxPackagesFor (callPackage ...)).extend, to apply an overlay to it
<clever>
mwdev: linuxPackagesFor (callPackage ...)` will ignore the overlay
<clever>
5 choices*
<clever>
5: rename both the directory and cabal file!
<clever>
4: rename both the cabal file and set name=!
<clever>
3: set name = "my-script"; in developPackage
<clever>
2: rename the directory to my-script
<clever>
1: rename the file to my_script.cabal
<clever>
zeta_0: you have 3 choices
<clever>
zeta_0: you can also pass `name = "my-script";` to `developPackage`, then the directory name wont matter (the name= must match the cabal file then)
<clever>
zeta_0: they must match (the _ vs -) or it wont work
<clever>
zeta_0: found your problem, the directory is my_script, but the cabal file is my-script.cabal
<clever>
zeta_0: so your already using callCabal2nix
<clever>
zeta_0: developPackage is just a giant fancy wrapper around callCabal2nix
<clever>
fresheyeball: dang is this a huge build, lol
<clever>
zeta_0: you need a my_script.cabal file, and i think `cabal init` will make one
<clever>
mwdev: examples are in all-packages.nix
<clever>
mwdev: i would not expect that line to work, you have to pass the linux packakage thru pkgs.linuxPackagesFor first
<clever>
zeta_0: cabal2nix only works if you have a cabal file
<clever>
fresheyeball: pytorch is building without cuda support
<clever>
-- USE_CUDA : OFF
<clever>
fresheyeball: does pytorch need git submodules to build?
<clever>
fresheyeball: ./. is basically the default for nix-build, so that part can be omitted
<clever>
fresheyeball: and what `nix-build` cmd to reproduce the error?
<clever>
hexa-: that filename is on line 37 of your pastebin, and its also in nixpkgs
<clever>
hexa-: youll need to read the install-grub.pl file, and see what exactly its doing when mirrored boots is set, what efiSysMountpoint does, and what it runs grub-install with
<clever>
mwdev: you must put a linuxPackages set into kernelPackages, such as pkgs.linuxPackages_5_3
<clever>
mwdev: then line 4 is a single derivation with linux, and line 8 is expecting a set of all linux packages, and thats where it fails
<clever>
hexa-: ive not tried mirrored efi yet, so i dont know how its setup properly
<clever>
hexa-: i think its upset that /boot isnt vfat tagged as the ESP
<clever>
mwdev: what is the contents of linux-5.3.nix?
<clever>
fresheyeball: double-check to see if the build system already did that, and your just copying the wrong path
<clever>
fresheyeball: you need to run something to turn it into a cuda_cmake_macros.h
<clever>
fresheyeball: can you push your nix code somewhere and i can try to reproduce it?
<clever>
mwdev: which nixos option did you set to what value?
<clever>
o1lo01ol1o: you can always start with `pwd ; ls -lh` in the installPhase, to figure out whats available and where you are
<clever>
zeta_0: relative to the file that contains the path
<clever>
zeta_0: and must end with something not a /
<clever>
zeta_0: paths start with either ./ (relative path) or / (absolute)
<clever>
zeta_0: its a path, pointing to whatever directory the nix file is in
<clever>
hexa-: and one thing i always worry about, somebody can just modify the initrd to phone-home with the pw, and then wait for you to ssh in and unlock it
<clever>
CMCDragonkai: i'm not sure there is a simple option for that
<clever>
hexa-: if you want remote unlock, then your /boot and /boot/efi must be plaintext
<clever>
something (havent checked what) will add luks support to grub, and grub will have its own pw prompt, before the initrd
<clever>
hexa-: and when using efiSysMountpoint, you could make /boot just a normal dir on /
<clever>
hexa-: efiSysMountpoint is only for the .efi binary, the kernel/initrd remain on /boot, outside of efiSysMountpoint
<clever>
hexa-: the efi binaries can optionally be on a /boot/efi partition, or a subdir of /boot
<clever>
hexa-: and nixos always puts the kernel/initrd on the /boot partition