<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>
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>
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>
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>
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