<clever>
mikky: i think its a fully self-contained nixos, so you can do .config = { config, ... }: { ... config.networking.hostname
<clever>
and the file i listed, is the cache of what is on a cache
<clever>
duairc: that can happen any time a binary cache gets GC'd
<clever>
duairc: try doing `rm ~/.cache/nix/binary-cache-v6.sqlite*` as root
<clever>
peelz_: i think there is a checkbox in one of the menu bars to hold ctrl and/or shift
<clever>
switch wont work inside the vm, but you can just shutdown, edit the host config, and build-vm again
<clever>
just run that, and thats it
<clever>
it will run your entire config, in a vm, with much more limited ram usage
<clever>
`nixos-rebuild build-vm` would also help test faster
<clever>
then file an issue
<clever>
try breaking it again, for science!
<clever>
maybe the perl/json encoder got upset?
<clever>
that solves issues like another user winding up with that uid, and owning 2 /home folders
<clever>
peelz_: the main purpose of that file, is for when you delete a user from configuration.nix, then re-add the user, it regains its old uid
<clever>
peelz_: it could also have been an improper shutdown
<clever>
peelz: do it!
<clever>
peelz: delete uid-map, and nixos should repair itself
<clever>
peelz: this perl script also runs on boot, as an activation script, its likely chewing up 60gig of ram, and getting OOM'd, before you can boot
<clever>
peelz: sounds like disk corruption
<clever>
peelz: what do the contents look like in a text editor?
<clever>
peelz: that aint right
<clever>
peelz: in the directory i just pasted
<clever>
peelz: they should be json i believe
<clever>
peelz: how do these 4 files look? are they fairly small?
<clever>
[root@nas:~]# ls -ltrh /var/lib/nixos/
<clever>
peelz: check the json file it got ran on
<clever>
peelz: why is perl using 20gig of ram? lol
<clever>
peelz: what does top say is using it all?
<clever>
newuser99: weird
<clever>
newuser99: is it in your .bash_profile or .bashrc?
<clever>
weird
<clever>
peelz: top
<clever>
peelz: free -m
<clever>
peelz: what does `dmesg` show at the end?
<clever>
immae: microcode gets prepended to the initrd, and the kernel applies it before virtualmemory is even enabled
<clever>
peelz: maybe also try disabling that, and see if its faster or not
<clever>
peelz: try rebooting again, make note of the exact time it seems to hang, and when it resumes, and then pastebin the `journalctl -b 0` again, and report what timestamps is was hung during
<clever>
peelz: which would be all of stage1, and the activation scripts
<clever>
peelz: that is everything before systemd gained control
<clever>
peelz: what about `systemd-analyze plot > boot.svg` and then look at that?
<clever>
peelz: what about further up in the log?
<clever>
around the timestamp of the hang
<clever>
peelz: what do you see in `journalctl -b 0` ?
<clever>
peelz: activation scripts happen before systemd is started
<clever>
peelz: any custom activation scripts?
<clever>
karantan: 67 defines a custom option, and then you can read it like any other nixos option
<clever>
karantan: making it a module with options would be better
<clever>
karantan: you could either define a custom nixos option and use it, or just start the file with `domain:` and then do `import ./file.nix "example.com"`
<clever>
newuser99: simplest answer is to not include nix in the buildEnv
<clever>
newuser99: you have nix inside the buildEnv, and its conflicting with the nix installed normally
<clever>
newuser99: and they could be messing with some things elsewhere
<clever>
newuser99: lines 19-29 dont do anything, becuase they arent in a derivation
<clever>
newuser99: building with -Q will make the output more readable in some cases
<clever>
newuser99: what kinds of things is it building?
<clever>
newuser99: thats the issue, `NIX_REMOTE=daemon` says to connect to a nix-daemon process, which isnt used in single-user mode
<clever>
newuser99: and the env var `$NIX_REMOTE` shouldnt be set
<clever>
newuser99: looks like a single-user install, so user should own everything in /nix
<clever>
newuser99: ls -lh /nix/var/nix/db/
<clever>
newuser99: what distro are you on?
<clever>
newuser99: is it a single-user or multi-user install of nix?
<clever>
you can also install that tool locally
<clever>
,locate
<clever>
NoctisLa1: tftp-hpa might be an option
<clever>
,locate bin tftp
<clever>
NoctisLa1: you can also use `nix-shell` or `nix-env` to get one of those into PATH temporarily
<clever>
NoctisLa1: if its due to you installing things, then its less of a bug
<clever>
NoctisLa1: yeah, i would consider that a bug, somebody will have to decide if we want net-tools, inetutils, or both, and then somehow block one of the ifconfig's if we want both
<clever>
NoctisLa1: depends on what is having a collision
<clever>
its just pkgs.dvc
<clever>
newuser99: its not in nixpkgs master, so its unlikely to be in any channel
<clever>
newuser99: why do you think its in nixpkgs-unstable?
<clever>
newuser99: and which package is missing?
<clever>
newuser99: when is the last time you dod `nix-channel --update` ?
<clever>
newuser99: what does `nix-instantiate --find-file nixpkgs` say?
<clever>
newuser99: or edit shell.nix to use <nixpkgs-unstable> instead of <nixpkgs>
<clever>
newuser99: use `-I nixpkgs=something` to map <nixpkgs> elsewhere
<clever>
justan0theruser: you must put (dunst.override { dunstify = true; }) into your shell instead
<clever>
pbb: youll need a custom linux .config file, or at least a few custom config entries, to force it down to 586
<clever>
pbb: i686-linux is the codename for all 32bit x86 cpu's
<clever>
ilya_g: figure out where your code is calling runInLinuxVM, within nixpkgs, and override that
<clever>
ilya_g: import a second copy of nixpkgs, and get runInLinuxVM from that
<clever>
ilya_g: use an older nixpkgs rev, or use a fork of nixpkgs with it fixed
<clever>
ilya_g: crap, pkgs/build-support/vm/default.nix directly imports that file, you have no way to overlay it
<clever>
ilya_g: 11 with import ../../../nixos/lib/qemu-flags.nix { inherit pkgs; };
<clever>
evanjs: fixed-output and non-fixed use a different algo to compute $out
<clever>
evanjs: now most things in nixpkgs use name = "source"; which i feel makes things worse
<clever>
evanjs: previously, fetchFromGitHub included the rev in the name, but that caused some issues where nix-prefetch-git doesnt use the same name, and the sha256 isnt right
<clever>
evanjs: so if the name changes, the hash totally changes, and it cant find the old $out, even with the same sha256
<clever>
evanjs: basically, the algo is /nix/store/${hash sha256 name}-${name}
<clever>
evanjs: the fetch name, not the main name
<clever>
evanjs: if the name is set correctly, you dont have to
<clever>
evanjs: and this lets you add another custom out-of-tree thing to a set
<clever>
ilya_g: i dont see a -cpu host, on nixpkgs master
<clever>
195 qemuCommandLinux = ''
<clever>
197 -nographic -no-reboot \
<clever>
196 ${qemuBinary qemu} \
<clever>
$ vi pkgs/build-support/vm/default.nix
<clever>
ilya_g: you will also want to read the original nix expr for this
<clever>
ilya_g: the problem is the -cpu host, which isnt as smart, you may be able to use -cpu again to overwrite it
<clever>
ilya_g: the shell script qemu-kvm will test if /dev/kvm exists, and automatically omit -kvm if it doesnt
<clever>
ilya_g: the gist contains a script that generates a script
<clever>
ilya_g: but we want the output, not the buildCommand, which is in line 1 of your gist, now /nix/store/7cf2ziyfwd7r4dpxy46mf8fpcblgscgk-vm-run
<clever>
ilya_g: that will extract 1 field for you
<clever>
ilya_g: b: run `nix-store --query --binding buildCommand /nix/store/hash-vm-run.drv`
<clever>
ilya_g: a: the path i gave you was the output, not the .drv file, that one is much cleaner
<clever>
yeah
<clever>
ilya_g: manually run the same nix-build in the container, to create the file
<clever>
ilya_g: you have to run it in a container that has attempted to build the disk image
<clever>
and then it "just works" without poluting your $PATH with things
<clever>
boogiewoogie[m]: and 51-73 defines a psd-resync, that runs at a set interval
<clever>
boogiewoogie[m]: line 34-49 defines a psd service, that will always be running, and it runs sync on startup, and unsync on shutdown
<clever>
boogiewoogie[m]: step 3, read lines 30-77, and see that it never adds anything to systemPackages, it just configures a usermode timer, to run it at a given interval
<clever>
ilya_g: what does `nix show-derivation /nix/store/cz3pxdglzyfq6nf6mxd8hcpdck9x6m3v-nixos-disk-image.drv` reveal?
<clever>
ilya_g: thats weird, lines 1-8 show part of qemu did work, so why is it failing on 12
<clever>
ilya_g: that gist says nothing about if kvm is working or not
<clever>
ilya_g: does the old configuration still work? with the old nixpkgs
<clever>
ilya_g: do you have the old code that used to work? how has it changed since then? does the old code still work?
<clever>
ilya_g: but nested virtualisation likely isnt enabled, so you cant get kvm to work in darwin docker
<clever>
ilya_g: docker on darwin lies to you, its running a full linux distro, in a vm, and then running linux docker within that
<clever>
ilya_g: does it exist on the host?
<clever>
ilya_g: does /dev/kvm exist within the docker container?
<clever>
ilya_g: you either need to tell qemu to not use kvm, or ensure that /dev/kvm exists within the docker container
<clever>
marek: as long as you ensure you only replace the right bytes, and dont change the lenght of the thing your replacing, you can patch almost any compiled binary like that
<clever>
marek: the binary patching, is basically just replacing a char *foo="biglongstring"; with "small\0\0\0\0\0" (of the same length)
<clever>
marek: haskell solves this with file-embed, build it once, with a magic string in the binary, then have a cheap derivation that will basically sed a new version into the raw binary
<clever>
jared-w: once it lands in /nix/store, the dynamic stuff will keep working
<clever>
jared-w: they dont have to be staticly linked, just import them the same way your importing this closure
<clever>
that also sounds like an improvement
<clever>
jared-w: but if your crappy UI lacks recursive upload, thats going to be even worse :P
<clever>
jared-w: the benefit that has over --export, is that it only copies what is missing from the usb stick, so changes are incremental
<clever>
jared-w: one idea i have had in the past, to deal with air-gapped machines, is to `nix copy --to local?root=/mnt/usb` then physically move the usb stick over the air gap, and --from on the other end
<clever>
marek: you can then route that string down to whatever is building the version file
<clever>
jared-w: the --export lacks signatures by default, and you need to either sign everything yourself, or disable signatures when importing
<clever>
marek: this code is providing a default, for when hydra wasnt in use
<clever>
marek: if you have an input named foo in hydra, then hydra will pass release.nix an attrset named foo, that contains the revision
<clever>
jared-w: step 1, fix whatever is forcing you to jump thru such hoops :P
<clever>
marek: hydra passes the git revision to release.nix as an argument
<clever>
jared-w: there can be more optimal ways
<clever>
jared-w: although, how are you uploading it to the machine?
<clever>
jared-w: thats where i prefer `nix copy --to local?root=/dir`, then you can tar it up or rsync it over
<clever>
jared-w: i use code like this, to bundle all of the things from niv into a single derivation (called ifd-pins here), and then you can nix-build and copy-closure that
<clever>
but the --export doesnt include the eval-time closure and IFD stuff
<clever>
jared-w: that would be the pinned nixpkgs, which niv is downloading
<clever>
jared-w: and why do you think its trying to download a channel?
<clever>
jared-w: you can also --option substituters 'local?root=/mnt https://cache.nixos.org' to make nix look in there, and grab what it can
<clever>
jared-w: nix copy --to local?root=/mnt/ might be simpler to manage
<clever>
jared-w: --export doesnt generate a nar, it generates a stream containing many nar's
<clever>
evanjs: what does --show-trace show?
<clever>
heh
<clever>
evanjs: --show-trace
<clever>
evanjs: something must be adding it to extraKernelModules
<clever>
gchristensen: i was also experimenting with a method of forking, to reduce heap and speed up eval, when we where at nixcon, its currently stalled in segfaults and concurrency bugs
<clever>
rnhmjoj: something is -9'ing the entire eval
<clever>
pie_[bnc]: the phase functions still exist
<clever>
pie_[bnc]: you can do patches with runCommand
<clever>
pie_[bnc]: probably
<clever>
gchristensen: i dumped a bunch of stuff in #nixos-on-your-router
<clever>
ah
<clever>
Profpatsch: when something like sudo or ssh asks for a pw, it opens /dev/tty, which bypasses any redirections, and goes to the tty that spawned it
<clever>
gchristensen: i have the powah!
<clever>
xavierzwirtz[m]: libredirect should work on any dynamic library, its using LD_PRELOAD to overwrite the open() function