2020-11-06

<clever> 560 { inherit bootStage1 initialRamdisk initialRamdiskSecretAppender extraUtils; };
<clever> 559 system.build =
<clever> bqv: if you read that file, you can see which parts are exposed under config.system.build
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ vi nixos/modules/system/boot/stage-1.nix
<clever> thibm: you can merge the nix-env and nix-build into one step
<clever> thibm: nix-env -f '<nixpkgs/nixos>' -iA config.system.build.toplevel --set --profile /nix/var/nix/profiles/system && --profile /nix/var/nix/profiles/system/bin/switch-to-configuration switch
<clever> bqv: it sounds like you have something very wrong with the fileSystems. setup in it
<clever> bqv: what was the configuration.nix you used to build the system?
<clever> bqv: and why is it trying to touch .ro-store, what are happening with /nix/store?
<clever> bqv: double-check what you have in the fileSystems for the config you just built
<clever> bqv: master goes thru less testing, and could have problems that make it unable to boot
<clever> bqv: which nixpkgs channel did you build from?
<clever> bqv: but you can now try to reboot into that new entry
<clever> fkv: so grub forces the build to be default, even if it wasnt a choice, while systemd-boot only makes it the default if its already a generation
<clever> generation*
<clever> fkv: yep bingo, systemd-boot figures out which one is default, by iterating over every GENERATE, and comparing it to where switch-to-configuration came from
<clever> 210 if os.readlink(system_dir(*gen)) == args.default_config:
<clever> 208 for gen in gens:
<clever> yeah, there it is, grub will default to the path switch-to-configuration came from
<clever> 15 # system.build.toplevel path
<clever> 16 my $defaultConfig = $ARGV[1] or die;
<clever> fkv: so you must run something like `nix-env --profile /nix/var/nix/profiles/system --set -i /nix/store/foo` to update the profile first
<clever> fkv: but systemd-boot's builder, is dumber, and only ever puts the generations into the cfg
<clever> fkv: so result/bin/switch-to-configuration boot, works with grub
<clever> fkv: i think the problem, is that grub's config builder, allows you to boot from a random storepath, that isnt in any generation
<clever> but you can do it manually as well
<clever> fkv: nixos-rebuild handles the generations
<clever> fkv: switch-to-configuration never creates a generation
<clever> fkv: why do you expect system-310 to be created?
<clever> fkv: i think thats the problem, i'm confirming it in the source now
<clever> fkv: let me double-check the source...
<clever> fkv: then at 2246, i can see that its going over generations 296-309 of your system, and generating config
<clever> fkv: down on line ~2221 of logfiles.2764, i can see it has started to poke around inside /boot/efi/nixos and /boot/loader/entries
<clever> fkv: logfiles.2764 is when it ran the systemd-boot-builder.py script, which should copy your generations into the systemd-boot cfg files
<clever> bqv: looks like your using systemd-boot
<clever> fkv: `strace -o logfiles -ff result/bin/switch-to-configuration boot`, and then pastebin all of the logfiles it made
<clever> fkv: what happens when you run `result/bin/switch-to-configuration boot ; echo $?` ?
<clever> fkv: what are the contents of switch-to-configuration?
<clever> fkv: did it output anything?
<clever> fkv: what happens if you run `bash -v result/bin/switch-to-configuration boot` ?
<clever> cole-h: and if you tripple click, but hold the 3rd and drag, it always selects whole lines
<clever> cole-h: if you double-click on text, but hold the 2nd click, and drag, it will always select whole words as you drag
<clever> cole-h: double and triple click add a lot of neat features that more people should use
<clever> and middle-click in linux, pastes whatever you last selected
<clever> cole-h: triple-click in most programs, selects the entire line
<clever> felix[m]2: python3Minimal is a version without openssl, readlink, ncurses, sqlite, and several things disabled at compile time
<clever> felix[m]2: python3Full is a variant with x11 support enabled
<clever> 9313 python3 = python37;
<clever> 9336 inherit (pythonInterpreters) python27 python35 python36 python37 python38 python39 python3Minimal pypy27 pypy36;
<clever> 9335 pythonInterpreters = callPackage ./../development/interpreters/python {};
<clever> 9323 python3Full = python3.override{x11Support=true;};

2020-11-05

<clever> numkem: check with wireshark to see whats going on
<clever> numkem: i would expect it to still work
<clever> correct
<clever> numkem: you want to run nix-build inside of docker, and that nix-build should use the buildDockerImage in nixpkgs
<clever> as far as nix is concerned, your on a normal linux machine
<clever> and nix itself doesnt need access to the unix socket then
<clever> numkem: so you want to run nix-build inside docker, to produce the docker image
<clever> numkem: the problem is that you need a linux builder to build the derivations
<clever> numkem: giving it a unix socket like that isnt pure, its better to built the tar without the docker tools
<clever> Unode: you dont need to rebuilt the index much, once you know the attribute, you can run `nix-build '<nixpkgs>' -A foo`, to find the latest path
<clever> Unode: ^
<clever> ,locate
<clever> simpler to just use nix normally on the host
<clever> i find mixing nix inside docker to be troublesome
<clever> not sure then
<clever> was docker told to bind-mount things?
<clever> when building $out, you have write access to $out
<clever> so the sandbox wont matter there
<clever> that one should have write to its own output
<clever> which derivation is failing to build?
<clever> yeah
<clever> you need nix-daemon running as root, to let it enforce the rules
<clever> psy3497: if the sandbox is fully off, then you can do nasty things like that, and nothing will stop you
<clever> `sudo HOME=/root aws ...` may force it
<clever> its a setting in /etc/sudoers
<clever> jophish: sudo sometimes keeps $HOME unchanged to "help you"
<clever> and look to see what the parent of the builder is
<clever> check `ps -eH x`
<clever> double-check that nix-daemon is actually running
<clever> yeah, that would be nix
<clever> jophish: is it nix doing the s3 access, or a builder?
<clever> jophish: if /nix/store is writable by the current user, it wont use the daemon, and will look in the current users home
<clever> jophish: is nix-daemon actually being used?
<clever> yep :)
<clever> root's home
<clever> jophish: i just put them in ~/.aws/
<clever> Jamaikos: the value of the imports array cant depend on the config set
<clever> Jamaikos: so you always put the same version of the module in imports, but use a .package override to change the binary being ran
<clever> Jamaikos: then use a services.foo.package to change the built used
<clever> Jamaikos: are the modules actually different, or is it just the source for the program?
<clever> Jamaikos: yeah, they would conflict
<clever> Jamaikos: the only way to really do it with modules, is to always put both versions in imports, then use an enable flag to turn them on/off
<clever> danderson: shell.nix can just import the flake
<clever> Jamaikos: instead of setting the hostname and having it magically do something, you should instead have a hostname.nix file, which does the right thing (including setting the hostname)
<clever> both host1.nix and host2.nix do `imports = [ ./common.nix ];`
<clever> Jamaikos: host2.nix does networking.hostName = "host2"; and uses another version from niv
<clever> Jamaikos: host1.nix does networking.hostName = "host1"; and uses one version from niv
<clever> Jamaikos: create 2 files, host1.nix and host2.nix
<clever> Jamaikos: imports must never depend on config
<clever> Jamaikos: line 5, DbSyncSources depends on testnet
<clever> Jamaikos: line 4, testnet, depends on config
<clever> Jamaikos: oh wiat, i see your problem
<clever> Jamaikos: what does it output, if you insert a `builtins.trace "path is ${DbSyncSources}"` between lines 6 and 7?
<clever> psy3497: the ? operator returns a bool saying if an attr exists, while the or operator lets you supply a default for when it doesnt exist
<clever> > let x = {a=5;}; in x.b or "default"
<clever> > let x = {a=5;}; in x ? b
<clever> knotteye: ${pkgs.nodejs-14_x}/bin/npm would give you an absolute path, but .path and .script are just as good
<clever> knotteye: .script will have nixos auto-generate a bash script for you, and then ExecStart points to that bash script
<clever> thats a limitation of systemd itself
<clever> knotteye: ExecStart must be an absolute path, you want systemd.services.satyr.script instead
<clever> knotteye: oh, i see the problem
<clever> knotteye: journalctl -f -u satyr
<clever> knotteye: what is the actual error message when you run it?
<clever> knotteye: and where is the symlink coming from?
<clever> knotteye: can you put all of the relevant nix files into a gist?
<clever> knotteye: what do the symlinks point to?
<clever> jophish: rpi-open-firmware also includes a ~40kb arm bootloader, that sits at that address, and deals with loading linux into ram and launching it
<clever> jophish: rpi-open-firmware already had drivers to bring the dram and arm cores online, and the arm then begins executing from physical address 0, on all 4 cores at once
<clever> jophish: the first stage that can be edited on VC4, is bootcode.bin, that runs on the GPU, and ram isnt online yet
<clever> danderson: it lets you do things like fileSystems.anything.options
<clever> jophish: i just havent setup the code to pass control of the cores on to linux
<clever> jophish: currently, the open-firmware only works on pi2 and pi3, and you loose video output and 3 arm cores
<clever> jophish: the second is an android-auto gadget, so the rpi can use a car as a touchscreen monitor
<clever> jophish: mostly focusing on 2 projects right now, the 1st is rpi-open-firmware, booting nixos without any blobs
<clever> they may be on the old arch
<clever> only other thing to worry about, is things in nix-env
<clever> but once aarch64 is deleted, getting back to 64 is tricky
<clever> as long as you dont GC the aarch64 build, you can also boot that again, to go forwards again
<clever> since the aarch64 kernel can run armv7 binaries
<clever> your going backwards, that should be fine
<clever> oh wait
<clever> and more, that an aarch64 perl is used to update the uboot config
<clever> the problem is less uboot
<clever> it needs an aarch64 machine, to generate the aarch64 builds
<clever> jophish: ive ran into the exact same problems upgrading an x86 laptop from 32bit->64bit
<clever> jophish: if you only change nixpkgs.system, then it will need an aarch64 build machine setup in /etc/nix/builders, to deal with the building, and the switching of the bootloader may fail
<clever> jophish: good, been working on some fun pi stuff lately
<clever> jophish: there is also just `pkgs.extend` to apply an overlay to it

2020-11-04

<clever> thats glibc, not glib
<clever> freezeboy: then the libc++ your patching in, is the wrong version
<clever> freezeboy: are you linking with ld, gcc, or g++?
<clever> [nix-shell:~/apps/rpi/aa]$ c++filt _ZdlPvm
<clever> operator delete(void*, unsigned long)
<clever> freezeboy: run that thru the c++filt program
<clever> thats harder to mix&match
<clever> ah
<clever> betaboon: and then it will ignore the system-wide copy
<clever> betaboon: you can often just `nix-env -i /nix/store/steam` to grab an old version, and add it to the users profile
<clever> betaboon: yeah, and boot.loader.grub.configurationLimit can limit how many, so you wont have to delete generations either
<clever> azazel: so --arg key '[ "foo" "bar" 1 ]'
<clever> azazel: --arg takes raw nix expressions, and you must quote them to stop bash from eating it
<clever> betaboon: nixos-rebuild will only put the last N generations into /boot
<clever> boot.loader.grub.configurationLimit
<clever> betaboon: also...
<clever> betaboon: nixos-rebuild will put back the files that matter
<clever> betaboon: yeah
<clever> (recursively, all the way down)
<clever> azazel: or the attribute your refering to with -A can also define the function
<clever> azazel: the file you open (usually shell.nix) must define a function, that accepts the arg you are giving
<clever> azazel: nix-shell accepts --arg, but it functions the same as --arg elsewhere
<clever> betaboon: instead, nixos-rebuild deletes the ones not tied to a generation, after you switch, without any need to gc
<clever> betaboon: but for /boot, nix-collect-garbage never deletes anything from /boot/
<clever> betaboon: run `nix-store --query --roots` on a given path, to see why its not being deleted
<clever> inquisitiv3: i would do it before you start it
<clever> inquisitiv3: that will create a symlink called jdk, that points to jdk
<clever> inquisitiv3: you would want to instead do something like `nix-build '<nixpkgs>' -A jdk -o jdk
<clever> betaboon: nixos-rebuild is just a shell script that runs nix-env on the system profile
<clever> ,locate
<clever> ,locate bin make
<clever> JaakkoLuttinen[m: so it never even had a .git to keep
<clever> JaakkoLuttinen[m: fetchFromGitHub just fetches from https://github.com/${owner}/${repo}/archive/${rev}.tar.gz
<clever> lightandlight: then it shouldnt be using the cache anymore
<clever> lightandlight: does it show in `nix show-config` ?

2020-11-03

<clever> siraben: it might be in nix-build, not nix build
<clever> yeah, that should also work
<clever> siraben: i think it was maybe `nix-store --repair-path` ?
<clever> siraben: but if you modify the source in any way, it will want a different build, and the problem can just vanish under the rug
<clever> siraben: the binary will just be gone, until you force a rebuild
<clever> dminuoso: enless your on darwin
<clever> siraben: the store is mounted read-only to prevent that
<clever> but git in yarn.lock, uses the commit sha1, which doesnt work, so you still have to fetch&hash those
<clever> flat mode, lets you reuse the hashes from a yarn.lock for example, so you dont have to fetch&hash everything when generating nix
<clever> outputHashMode="recursive" means $out can be a file, directory, or even symlink, and you are reporting the hash of the nar (nix-store --dump $out > foo.nar)
<clever> outputHashMode="flat" means that $out must be a single file, and you are reporting the hash of the file
<clever> by the old standards, outputHashAlgo has the algo name, and its split between 2 fields
<clever> if a derivation has outputHash and outputHashMode, then it will be considered fixed-output by the new standards, and outputHash must contain the hash algo
<clever> "outputHash" "outputHashAlgo" "outputHashMode"
<clever> you can always write your own custom fetcher though
<clever> so you can only do http(s) based git now
<clever> and sadly, the ssh based pkgs.fetchgitPrivate was removed from nixpkgs
<clever> if you want to avoid fetching the src if its already built, then you must use a derivation
<clever> if you supply a sha256, it will compute the storepath, and check if it already exists, then maybe skip the fetching
<clever> as-if you had done src = ./foo;
<clever> typetetris: all of the builtin based fetchers will download at eval time, and then just insert the path to the result as a plain path
<clever> its not a derivation, but it can accept a sha256
<clever> typetetris: builtins.fetchGit will

2020-11-02

<clever> vs that one, which has a -bin-env added on
<clever> > weechat.name
<clever> because its name matches the closest
<clever> > weechat-unwrapped.pname
<clever> ptotter[m]: -i likely installed weechat-unwrapped
<clever> ,-A
<clever> energizer: theres also #nixos-aarch64 which may be less busy
<clever> energizer: sure
<clever> pushqrdx: nix-env -i ./result to install it, but you can run it without installing
<clever> pushqrdx: stdenv.mkDerivation provides you with make and gcc by default
<clever> pushqrdx: nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}'
<clever> pushqrdx: you must load the file with pkgs.callPackage
<clever> bqv: and then things can fail at runtime when installed without nix
<clever> bqv: the problem of symlinking like the FHS env's do, is that the libraries you compile/link against will be the wrong version
<clever> bqv: this will download a bunch of .deb packages, then unpack them, creating an env that is basically identical to ubuntu, then do a non-nix build within that env
<clever> bqv: something like that already exists
<clever> normally, you would expect that cmd to destroy a system, not fix it
<clever> and it was rather fun to fix the system with `rm -rf /bin /usr /lib` lol
<clever> i had initially done that without LUSTRATE, and then dbus and other things broke, because of gentoo binaries in /bin and config in /etc
<clever> so you can still recover things afterwards
<clever> "wiped" by moving it to /old-root/
<clever> matthewcroughan_: the kexec route lets you change the partitions and filesystem
<clever> matthewcroughan_: yeah, but with the restriction that you need to keep the same partition layout
<clever> and NIXOS_LUSTRATE, somebody added, based on how i manually repaired things the first time i did it :P
<clever> the boot flag, rewrites the bootloader
<clever> the NIXOS file convinces switch-to-configuration to work
<clever> bqv: basically, `touch /etc/NIXOS_LUSTRATE /etc/NIXOS && ./result/bin/switch-to-configuration boot`, is a viable way to install nixos
<clever> oops
<clever> bqv: basically, `touch /NIXOS_LUSTRATE /etc/NIXOS && ./result/bin/switch-to-configuration boot`, is a viable way to install nixos
<clever> bqv: i have ran switch-to-configuration on gentoo before

2020-11-01

<clever> i just always use grub for my bootloader
<clever> tsujp69: i dont think systemd-boot can run windows
<clever> and once you exit nix-shell, its basically gone
<clever> that will add firefox to $PATH for only that shell
<clever> tsujp69: nix-shell -p firefox
<clever> tsujp69: nixos-install is basically just a script to run nixos-rebuild in a chroot, to target the non-current os
<clever> tsujp69: if you want to modify the current os, you use nixos-rebuild
<clever> my laptop is using zfs+swap on lvm, then lvm on luks
<clever> but older drives dont support it
<clever> that tells the drive firmware to just assume the block is worthless, and to return 0's next time you try to read
<clever> i prefer using blkdiscard to completely massacre the disk
<clever> if you still have some channels, they will update, but have no effect on the actual nixos build
<clever> if you have no channels setup, thats right
<clever> matthewcroughan_: --upgrade just tells it to run `nix-channel --update` first
<clever> yeah
<clever> but the default NIX_PATH does say to search the current channels
<clever> channeels is more in the ~/.nix-defexpr/ area
<clever> NIX_PATH isnt directly channels
<clever> pushqrdx: systemPackages would put it instead in /run/current-system/sw/
<clever> pushqrdx: nix-env adds things to ~/.nix-profile/

2020-10-31

<clever> [root@nas:~]# du -hsc $(nix-store -qR /run/current-system) | sort -h
<clever> bqv: i think thats only needed when using the newer outputHash syntax, where the outputHashAlgo is absent
<clever> you can also just do `sha256 = "sha256-aS2KIclwCbsOxkU0qIv+fPm7YIzpq21S4Q/NH9bbL7g=";`

2020-10-30

<clever> and then new problems crop up
<clever> and then /boot doesnt mount on startup
<clever> a lot of people fix that, but dont re-run generate
<clever> and you probably want to re-run nixos-generate-config --root /home/nixos/mnt/128gbsd/fsroot
<clever> you have to mount it to /home/nixos/mnt/128gbsd/fsroot/boot/ when installing
<clever> that would explain it
<clever> yeah
<clever> is start4.elf in that filesystem at the root?
<clever> probably close enough
<clever> and fat32 on sda1?
<clever> energizer: GPT?
<clever> energizer: https://gist.github.com/cleverca22/ad65d9f54e5ef507bd1c5e52d139b247 this is how ive been reflashing my pi4 lately
<clever> boot the installer stick again, and check `fdisk -l` on the SD card, what partitions does it have?
<clever> then your firmware is missing
<clever> energizer: or was it doing that, even with an SD card?
<clever> energizer: if you have no sd card and no usb-stick plugged in, then its obvious it wont find start4.elf
<clever> one min
<clever> the new version gives debug on hdmi also
<clever> but if your not getting any video out, then your eeprom is out of date
<clever> thats the normal start4.elf not found error, which makes sense
<clever> how many blinks does the green one give?
<clever> if both are blinking, your power supply needs to be replaced
<clever> red should never blink, so they are fine
<clever> does the green led blink at all when you do that?
<clever> what else is plugged into the pi4?
<clever> which hdmi port are you on?
<clever> although, i can see stage-1 without having set that
<clever> energizer: you may need to include the vc4 driver in the initrd
<clever> ahh
<clever> energizer: does that directory contain a bin dir?
<clever> $root/etc/nixos/configuration.nix is the target, via the --root you gave nixos-install
<clever> /etc/nixos/configuration.nix is the host
<clever> energizer: which is not what you showed with the tail cmd
<clever> energizer: nixos-install reads from /home/nixos/mnt/128gbsd/fsroot/etc/nixos/configuration.nix
<clever> energizer: what path is the file at? what cmd did you run?
<clever> samueldr: i recently dd'd the .img to a usb stick, and booted it up, i never ran nixos-install, i just did nixos-generate-config, fixed configuration.nix, and nixos-rebuild
<clever> after what is in the pastebin
<clever> samueldr: so there could be a } // { fileSystems."/notroot" = ...; } breaking it
<clever> energizer: doesnotwork.nix is missing the tail end of the file
<clever> energizer: did you use // in a weird place?
<clever> the bootloader stuff in the paste looks close enough
<clever> energizer: which model of pi?
<clever> sounds good
<clever> Ericson2314: i was helping siraben with adding a z80 cross-compile to nixpkgs yesterday, but we are a bit stuck, because its not gcc based

2020-10-29

<clever> dont think so
<clever> you may need to wait for Ericson2314 to come online then