2018-09-24

<clever> kandinski: do you have any overlays or overrides?
<clever> so unstable still has 100% cache coverage
<clever> kandinski: all non-small channels refuse to update until hydra has cached everything that can build
<clever> kandinski: hydra pre-compiles things so it shouldnt be building as much, and i just dont update that often
<clever> kandinski: rollbacks allow you to undo any upgrade, as long as the disk is not corrupt
<clever> i just run nixos-unstable on most of my machines
<clever> kandinski: probably, but then you also get warnings about collisions on channel names
<clever> -i (without A) and -u will search all channels
<clever> but if the names dont collide, you can select between the 2 sets
<clever> if the channel names collide, yes
<clever> you need to use -iA nixpkgs.foo to select from unstable
<clever> and use the exact version you pointed it to
<clever> if you try to install something you already have, it will instead upgrade it
<clever> but you can also just `nix-env -iA nixpkgs.libreoffice-fresh` to force it to grab from the channel you named nixpkgs
<clever> i'm not sure what rules -u uses, to solve the conflict
<clever> but -u doesnt accept a channel name, and just searches both
<clever> kandinski: when using -iA, you can do nixos.hello or nixpkgs.hello, and use channel names to pick a channel
<clever> the -small channels omit the non-queued requirement
<clever> kandinski: channels update when a certain subset of builds pass (testing), and every build is non-queued (failed or passing)
<clever> and i dont know which channel `nix-env -u` gets it from, so it will be unpredictable what version you get
<clever> kandinski: you have channels on both users, so you need to run `nix-channel --update` as both, to update both of them
<clever> nix-env ignores NIX_PATH
<clever> what does `nix-channel --list` report, for both your user, and root
<clever> and nix-env -u will just search all channels, and install whatever matches
<clever> nix-env doesnt remember which channel it came from
<clever> shreyansh_k: the binary cache is never garbage collected

2018-09-23

<clever> Ericson2314: ah, its been bothering me that one of them took it in the other order, and i also couldnt remember what
<clever> EternalZenith: services.xserver.modules
<clever> they have to be correctly added to the nixos module for xorg
<clever> installing things wont fix it
<clever> yep
<clever> thats the last thing i said
<clever> 2018-09-22 21:55:38 < haslersn> ah
<clever> 2018-09-22 21:55:28 < clever> oh, and you may want nixos-rebuild switch --install-bootloader
<clever> oh, and you may want nixos-rebuild switch --install-bootloader
<clever> also double-check that /boot is mounted when running nixos-rebuild
<clever> if the firmware is even capable of that
<clever> it will also give the OS a cleaner name in the firmware, when you are selecting between EFI based OS's
<clever> its more proper i believe
<clever> once it boots like that, you can try switching the vars back around, and confirm it worked with efibootmgr -v
<clever> it must be set to false
<clever> only thing i can think of then is to temporarily try the installAsRemovable flag instead
<clever> haslersn: is canTouchEfiVars enabled?
<clever> haslersn: that would be the problem then

2018-09-22

<clever> haslersn: does efibootmgr -v list it? is the partition type code correct?
<clever> steveeJ: do /ctcp clever time
<clever> steveeJ: i can check it in the morning, heading off to bed now
<clever> so you can just jack into any machine and netboot nixos, and leech the laptop wifi
<clever> avn: it runs a dhcp+ipxe+dns server on the ethernet jack, with NAT into the wifi
<clever> avn: netboot_server in its current configuration, is actually perfect for a laptop
<clever> avn: that lets you netboot into the installer
<clever> avn: ipxe also helps there
<clever> avn: the rescue system will always use the same nixpkgs as the host its installed on, so that likely wont be an issue
<clever> avn: probably
<clever> haslersn: i originally used rescue_boot.nix on my laptop (with luks encrypted zfs) to move /nix/store into its own zfs dataset
<clever> the config also has to be altered if /boot is on zfs
<clever> yep
<clever> but if you pinn the pkgs.path on lines 3&5, you could avoid that
<clever> so if your main nixos upgrades to a bad zfs that corrupts things, the rescue env does as well
<clever> infinisil: only major issue, is that the "rescue" env is updated on every nixos-rebuild
<clever> infinisil: yes
<clever> JonReed: that wont do anything with /boot or systemd
<clever> JonReed: and hardware-configuration.nix?
<clever> JonReed: i believe its auto-generated when you set fileSystems."/boot"
<clever> haslersn: https://github.com/NixOS/nix/issues/2405 i believe
<clever> haslersn: that tends to happen if you use builtins.fetchTarball during nixos-install
<clever> yeah
<clever> pointfourone: they remain in the store, and you can use rollback or absolute paths to access them
<clever> pointfourone: they are only removed from the newly made generation of the profile
<clever> steveeJ: hh
<clever> pointfourone: nix-env can only have one version of emacs installed in the profile at once, but several emacs can live in /nix/store
<clever> steveeJ: you may need to mount /proc
<clever> pointfourone: and you can use that path to run that version, at any time
<clever> pointfourone: if you run `realpath $(which emacs)` you can see the absolute path for emacs
<clever> alex``: nix-locate is the backend for that, and bash has a command-not-found script somewhere that runs it
<clever> pointfourone: when you install or remove anything with nix-env, it keeps the old profile, and you can use `nix-env --rollback` to undo the last operation
<clever> pointfourone: rollbacks and generations already do exactly that
<clever> pointfourone: the conflicting version stuff only really plays nicely when dealing with multiple users, or in the build or shell environments
<clever> pointfourone: yeah, it wil likely fail because there are 2 binaries with the same name in the profile
<clever> steveeJ: cant remember off the top of my head, check the stage-1-init.sh in nixpkgs
<clever> pointfourone: that is one thing it can be used for
<clever> pointfourone: nix run or nix-shell would be better for that i think, since nix-env will have collisions on the binaries
<clever> pointfourone: why do you want to install both?
<clever> pointfourone: all nix-env operations are atomic, if the command fails, it will not make any changes to the profile
<clever> EternalZenith: youll probably want to file a pr then, once you find out what special stuff it needs
<clever> steveeJ: you may need to run something like udev trigger or settle to update /dev/
<clever> EternalZenith: that just makes things like jsoncpp being null a fatal error, if i3GapsSupport is true, i believe
<clever> steveeJ: it may also break the ability to nixos-rebuild that image after it has been written to a sata disk
<clever> and if any mass-rebuilds happen
<clever> depends on if other things are breaking master or not
<clever> pointfourone: http://howoldis.herokuapp.com/
<clever> as far as linux users are concerned
<clever> pointfourone: the only differemce between nixos-unstable and nixpkgs-unstable is which tests it waits for
<clever> pointfourone: yes
<clever> s/wacom/xorg/
<clever> its possible that wacom is assuming full control, and its not an EV input device
<clever> zduch4c: journalctl -u display-manager
<clever> zduch4c: oh, `ls -l /proc/PID/fd/` for xorg's pid
<clever> zduch4c: anything about wacom in the xorg logs?
<clever> pointfourone: oops, ^^^
<clever> patrl: the nixpkgs-unstable channel is the latest version of master to pass a certain set of tests
<clever> cant get anything below 20, other then 0
<clever> a light touch is 20-63, lol
<clever> neat, pressure, it can go up to 70-ish
<clever> [root@system76:~]# evtest /dev/input/event7 | grep ABS_PRE
<clever> my laptops touchpad (not screen) shows up in evtest
<clever> /dev/input/event7: SynPS/2 Synaptics TouchPad
<clever> any process related to wacom running?
<clever> which DE did you switch to?
<clever> zduch4c: thats strange, gnome shouldnt, ah
<clever> zduch4c: evtest even finds it?
<clever> steveeJ: when -nographic is used, the serial port links to the stdio of qemu
<clever> then boot with that instead
<clever> steveeJ: you can use qemu-img to create a writable qcow2, that uses the readonly qcow2 as a backing file
<clever> and if you re-run that after using --keep-failed, it will drop you into a shell in the vm
<clever> steveeJ: i think i saw something about the build-in-vm script leaving a shell script behind in $NIX_BUILD_TOP
<clever> ah
<clever> steveeJ: thats the 9plan fs sharing stuff
<clever> jmsb: try the menu in minicom to play with some of its options, no hardware flow control
<clever> jmsb: do you have a scope?
<clever> might even explain why libvirtd went the more complex way
<clever> that even has bootindex in it already!
<clever> -drive file=foo.qcow2,format=qcow2,if=none,id=disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
<clever> ah, perfect
<clever> steveeJ: but he deleted the gist with the full qemu args
<clever> steveeJ: this is a fragment of a convo from when i was helping somebody boot nixos under libvirtd (which was running qemu)
<clever> steveeJ: dang, he deleted the gist!
<clever> jmsb: what about with minicom, as root?
<clever> jmsb: is the baud rate correct? is the remote end running a getty on the serial port?
<clever> steveeJ: almost got an example, these logs are a bit slow to search
<clever> near this timestamp...
<clever> 2018-09-19 03:58:47< clever> and then there are matching -device entries to create pci nodes for each disk
<clever> yep, finding an example of that
<clever> steveeJ: one min
<clever> ah
<clever> etu: steam or osomething else?
<clever> steveeJ: your screenshot shows 2 pci devices
<clever> steveeJ: i also see a bootindex param in the docs
<clever> steveeJ: and you must have tried -boot order= already?
<clever> oh, that explains why i never saw it in the docs, lol
<clever> oh neat, never noticed -boot menu=on
<clever> greymalkin: what error did it have?
<clever> greymalkin: why did the directions i gave not work?
<clever> > "nix-store -r ${nix} ; export PATH=${nix}/bin:$PATH"
<clever> oops, typo'd the 2nd one
<clever> greymalkin: run the 2 commands the bot gave, then use `nixos-rebuild boot --fast`
<clever> > "nix-store -r ${nix} ; export PATH=${nix}/bin"
<clever> ,library
<clever> > builtins.langVersion
<clever> yeah, an override on emacs25 should do it then
<clever> you missed which version emacsPackagesNg uses
<clever> [clever@system76:~]$ nix-instantiate --find-file 'nixos/pkgs/top-level/all-packages.nix'
<clever> double-check your version of all-packages.nix to see what your emacsWithPackages is using
<clever> zduch4c: which version of emacs are you using?
<clever> and if you override emacs, then emacs26PackagesNg wont notice, and it wont get passed on ti emacsWithPackages
<clever> infinisil: i just opened all-packages.nix in vim
<clever> zduch4c: then it will also have an impact on emacsWithPackages
<clever> zduch4c: if you use an override to change `emacs26 = super.emacs26.override { withXwidgets = true; };`
<clever> 16245 emacs26PackagesNg = emacsPackagesNgFor emacs26;
<clever> 16030 emacsPackagesNg = emacs26PackagesNg;
<clever> 16247 emacsWithPackages = emacsPackagesNg.emacsWithPackages;
<clever> though i have a feeling he is using the emacs irc client, and has to restart to update that
<clever> like that? lol
<clever> zduch4c: you need to install (emacs.override { withXwidgets = true; })
<clever> sphalerite: wtf! that option was added to nixpkgs a month before i made that gist, lol
<clever> sphalerite: i wonder how similar it is to https://gist.github.com/cleverca22/5711322b5a12311571d8e828f40f0603 ....
<clever> thats an option?
<clever> i guess i dont update often enough :P
<clever> mkaito: somebody else made a commit adding python3
<clever> its also not in my main PATH
<clever> oh, and i needed python3 in the steam sandbox
<clever> which lets you test the things they havent approved it for
<clever> steam->settings->steam play->enable steam play for all titles, this option disables the whitelist of games that are known to work
<clever> mkaito: ive not tried packaging proton, but the proton within steam works
<clever> vodurden: and then confirm if libredirect covers it
<clever> vodurden: check with strace to see what syscall its using to refer to the binary
<clever> via /proc/<pid>/proc/net/foo
<clever> it can also let you peek at private /proc mounts inside a namespace
<clever> even if that dir is outside your own mount namespace
<clever> also fun, /proc/<pid>/root is a magic symlink, that points to the root of that processes mount namespace
<clever> didnt notice what the original need for namespacing was
<clever> heh, your the one that started the previous convo on namespaces
<clever> vodurden: libredirect
<clever> pie_: nix-shell -p '(import ./shell.nix {})' would work with your previously wrong file
<clever> your shell.nix must contain a derivation, that has withPackages in the buildInputs
<clever> thats an env suitable for building withPackages, not using withPackages
<clever> pie_: you cant mix -p and shell.nix
<clever> Myrl-saki: stat /
<clever> its the normal root owns / thing
<clever> wdanilo: you can manually create and chown /nix, and then the install script wont try to sudo
<clever> elvishjerricco: you need ownership of /nix/ to install nix without root
<clever> research what namespacing options darwin has, now the nix sandbox works, and write a variant of nix-user-chroot for darwin
<clever> wdanilo: dual-boot to nixos
<clever> wdanilo: install docker, and then use a docker image with nix?
<clever> wdanilo: the stuff above is all using linux specific syscalls
<clever> nix-user-chroot from above would probably have helped a lot in those experiments
<clever> and i was avoiding use of systemd-nspawn, so i could enter it without any special deps
<clever> this was an experiment i was doing, to enter a full nixos container (i think it even had systemd)
<clever> elvishjerricco: yeah, you could use the unshare binary to do it
<clever> but you do need ownership of /nix/
<clever> that does the same rootless namespacing, but aims at /nix as a whole, rather then just /nix/store/
<clever> you need to use nix-user-chroot and/or nix-bundle
<clever> so /nix itself, along with profiles and the db are missing
<clever> i checked `mount` while inside the above `nix run` sandbox, and it only mounted /nix/store
<clever> so even if you fool a setuid binary with a fake /etc/shadow, it gains you nothing
<clever> so setuid binaries are not actually getting root
<clever> which means the uid 0 inside the namespace, isnt the real root
<clever> wdanilo: using mount namespaces without root, requires you to also use a user namespace
<clever> mount namespaces and usernamespacing

2018-09-21

<clever> id checkout a copy of nixpkgs matching nixos-version, and then just edit the expression to add --enable-debug
<clever> all i can think of then is to head off to #zfs or #zfsonlinux
<clever> did you hear about the 0.7.10 issue?
<clever> what version of zfs did you previously run?
<clever> more strongly then -f
<clever> -F forces it to import
<clever> infinisil: what about with -Fn ?
<clever> ive even used it to inspect vdev's i have entirely removed from the pool
<clever> infinisil: that shows metadata about a vdev, even if you dont import it
<clever> infinisil: zdb -l /dev/mapper/root
<clever> infinisil: nope, but i have used zdb a bit, one min
<clever> catern: it may work
<clever> probably
<clever> so it wont use non-nix libraries
<clever> the nix provided gcc has been modified to not look in /usr/lib and friends
<clever> which discards a lot of the trash not needed in an initrd
<clever> and runs patchelf on all files, to point them to that new derivation
<clever> rather then depend on all of glibc in the initrd, it copies libc.so to a new derivation
<clever> the nixos initrd is even doing a form of that
<clever> yeah, you can use patchelf to un-nix the files
<clever> but lack GC roots, so they can even break locally if you garbage collect
<clever> nix-shell products still refer to the store in the same way
<clever> even the ld.so in dynamic elf files is in the nix store
<clever> catern: the ELF files nix will produce refer to /nix/store/ and will break when copied to another machine manually
<clever> betaboon: the fs will resize itself
<clever> betaboon: nixops cant resize an EBS, you need to go into the aws console and resize it there, then reboot the machine 1 or 2 times
<clever> betaboon: disk size is unrelated to the instance type, you can freely resize the disk
<clever> betaboon: disk or ram? which hoster?
<clever> betaboon: try just installing ncdu, and running `ncdu /nix`, what is the largest path?
<clever> old generations
<clever> betaboon: because you already ran it with -d, it deleted all garbage and generations
<clever> ah good idea, optimize should work even with a full disk
<clever> betaboon: what happens if you just run `nix-collect-garbage` with no args?
<clever> rauno: its a bug in the detection code, not dealing with symlinks under a chroot
<clever> rauno: tell it to continue even though it doesnt exist

2018-09-20

<clever> gamble: continue, and treat it as a bios machine
<clever> resources is also part of nixops
<clever> but some args like nodes are specific to nixops
<clever> jackjennings: in the nixos docs i believe
<clever> and the error will then guide you towards finding at least the name of each
<clever> jackjennings: if you omit the ..., then it will fail for any args you didnt name
<clever> with older bios's, the bios boot partition has to be near the start of the disk
<clever> LnL: from my undestanding, with grub, it will just load and execute the blob in the first 512 bytes, which must then be able to read the stage 1.5 in the bios boot partition
<clever> my desktop is also rather dumb, it ran a .efi file on a vfat, that i forgot to tag as the ESP
<clever> Dezgeg: oh, you mean the bios is too smart, and refuses to run the MBR in the gpt disk?
<clever> gpt is still an option with legacy, just need a bios boot partition, 1mb, no fs, not mounted
<clever> simplest thing is to just say "screw efi" and do a full legacy install
<clever> if you booted in legacy mode, then you cant modify the efi vars, so a normal efi install wont work
<clever> uefi is always a gamble, you never know what your going to get
<clever> and now windows cant chainload from grub
<clever> i recently switched my desktop from legacy to efi
<clever> i'm also fighting my own boot issues here
<clever> yeah, that sounds like it should help
<clever> my desktop only has the M$ key or off
<clever> my laptop gives me full control over secure boot
<clever> colemickens: there is one that entirely ignores the efi vars, and only boots the path windows puts the binary at
<clever> colemickens: some bios's are stupid
<clever> gamble: i found you have to disable uefi entirely to boot legacy, on some machines
<clever> colemickens: nuke ~/.cache/nix on root
<clever> gamble: you need to just write the image directly to the usb in dd mode
<clever> gamble: the iso file is already a valid usb image, and tools like rufus tend to break it
<clever> grep all of the narinfo files you have for the name of the missing file
<clever> ah
<clever> colemickens: nix will cache the existance of things locally, and try to download them later
<clever> colemickens: oh, and if you delete anything from the cache, bad things happen
<clever> and it declares the hash to be the same as the name of the .nar.xz
<clever> FileHash: sha256:15gabh5pdnr6afsp49vb0ym02r09p27b50pinn9phsy366cx2rgb
<clever> in my case, 58r35bqb4f3lxbnbabq718svq9i2pda3.narinfo points to nar/15gabh5pdnr6afsp49vb0ym02r09p27b50pinn9phsy366cx2rgb.nar.xz
<clever> colemickens: the narinfo will have a different hash in it
<clever> colemickens: for that protocol, the .nar.xz files are named after their hash
<clever> one min
<clever> ah, so its `nix copy` with `file://` that actually makes the dir
<clever> colemickens: how did you make the binary cache?
<clever> zduch4c: dang, 4.10 isnt an option on nixos-unstable
<clever> zduch4c: my only other idea is to try the same kernel version as ubuntu
<clever> zduch4c: ah, serio sounds like the ps2 family of protocols
<clever> zduch4c: which serio driver is loaded on each?
<clever> infinisil: but if the serio driver isnt working right
<clever> infinisil: udev should detect what the device is, over the serio channel, and then auto-load it via the alias: serio:ty02pr39id*ex*
<clever> zduch4c: so we need to see if ubuntu shows any serio modules in lsmod