2019-01-19

<clever> ive yet to find coreboot support for any hardware i have
<clever> ah, nice
<clever> in this case, with 2 completely isolated ethernet controllers
<clever> in that example, one of my pci devices is a multi-function pci card
<clever> next example is going into a pastebin
<clever> enp4s0 -> 04:00.0 Ethernet controller: Qualcomm Atheros QCA8171 Gigabit Ethernet (rev 10)
<clever> becomes enp3s0
<clever> 03:00.0 Ethernet controller: Intel Corporation 82583V Gigabit Network Connection
<clever> this disables that stuff, so nixos is also eth0
<clever> pbb: networking.usePredictableInterfaceNames
<clever> pbb: and i had the exact same problem!
<clever> or you can just do basic things, like totally format it from kexec
<clever> there is a util out there somewhere (forgot the name) that can luks a partition without data loss
<clever> another benefit to the kexec trick, is that the hdd isnt mounted, so your free to do more funky things
<clever> yeah, if your using over half the disk, you cant easily change it to encrypted
<clever> so my script causes an improper shutdown
<clever> i opted to not use things like "systemctl kexec" because what if the target lacks systemd?
<clever> kexec from rescue is also slightly safer
<clever> my kexec trick also works inside any rescue system with kexec enabled
<clever> and if it does, the original os wont be there anymore, and youll have a new brick
<clever> also, dont forget to stop the systemd timer, or it may reboot in the middle of your install
<clever> then copy it to the real config you use for installing
<clever> so you can test things in a non-destructive fasion
<clever> and when it does so, the original OS comes back online
<clever> and if you fail to ssh into it within an hour, it will reboot itself (a systemd time reboots at the end of every hour)
<clever> if your vps needs special network config, you must add it to the configuration.nix file, it the kexec env wont have networking
<clever> it gives you a chance to test things non-destructively
<clever> oh, and another thing with the kexec stuff
<clever> there is a test script in my kexec dir, to generate qemu VM's with/without uefi, luks, sata/nvme, and include a kexec image inside thats configured for that
<clever> yeah, network is where i had the most trouble too
<clever> so its ~200mb, rather then only 350 lines
<clever> though unlike vps2arch, the tar contains the entire closure, including the nixos rootfs
<clever> but, arx can turn the tar into a self-extracting executable
<clever> currently, you must unpack the tarball to /, then run /kexec_nixos
<clever> i have plans to add arx into things
<clever> the original usage, is to install nixos on servers in datacenters, remotely, from the rescue shell or pre-existing os
<clever> you build a special tarball on a different machine, then upload the tar to the target
<clever> pbb: this handles the entire kexec process, you dont even need nix on the target machine
<clever> pbb: another option, is kexec
<clever> NIXOS_LUSTRATE is safer, in that it moves everything to /old-root/
<clever> and the basic solution was just rm -rf /usr /lib /bin /etc
<clever> i believe i first did it on a netbook, andthen had to debug all the breakage from /lib and /etc and /bin having bits of gentoo in them
<clever> and the script in nixos was written from the story of how i did it
<clever> fun fact, i think i was the first one to do that, before it was automated
<clever> and remembering all the quirks of all the tools
<clever> part of it is being able to memorize exactly where nixos-generate-config comes from
<clever> part of it is just having OCD about how things work, and reading source code non-stop :P
<clever> you can also do clever ++ (without the space)
<clever> re-run the nix-env -iE you gave above, and it will actually "update" to the older nixos-generate-conifg
<clever> and you needed -E because its not in the main package set
<clever> -u is very dumb, it just searches all packages for something with a matching name
<clever> because it never saves that expression
<clever> anything you install using -E is imposible to update in an automated way
<clever> it doesnt exist in the main pkgs set, so it never finds an update
<clever> -u cant update nixos-generate-config
<clever> did you re-run the nix-env command, after changing the channel?
<clever> pbb: which in your case, is /nix/store/vrz9gkwk82c8dp83798nyhlsw862xzaj-nixpkgs-18.09.1922.97e0d53d669/nixpkgs/.version
<clever> 130 release = lib.strings.fileContents ../.version;
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ vi lib/trivial.nix
<clever> > lib.trivial.release
<clever> it comes from lib.trivial.release
<clever> nixos/modules/misc/version.nix: nixos.release = mkOption {
<clever> 41 inherit (config.system.nixos) release;
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ vi nixos/modules/installer/tools/tools.nix
<clever> 641 system.stateVersion = "${\(qw(@release@))}"; # Did you read the comment?
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ vi nixos/modules/installer/tools/nixos-generate-config.pl
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ git checkout 97e0d53d669
<clever> pbb: and realpath /home/pbb/.nix-defexpr/channels/nixpkgs
<clever> pbb: what does `nix-instantiate --find-file nixpkgs` return?
<clever> pbb: and nixos-generate-config will never overwrite configuration.nix
<clever> pbb: what rev of nixpkgs are you using?
<clever> so the binaries cabal produces wont have the profling rts, and wont use the profiled variants of libs
<clever> fresheyeball: i believe --disable-profiling refers to executables, not libraries
<clever> and typically, the libs are pre-build by hydra for you
<clever> fresheyeball: it builds libraries twice, with and without profiling, which saves you from having to rebuild the world with profiling when you decide to profile something
<clever> iqubic: why cant you get it to work?
<clever> 2019-01-18 14:20:18< LnL> iqubic: try nix-env -f https://github.com/NixOS/nixpkgs/archive/master.tar.gz -iA whatever
<clever> (non-efi)
<clever> other then iscsi being in the initrd, that disk image is basically identical to a legacy boot image
<clever> so zero netboot config is required in grub
<clever> then ipxe reads iscsi instead, and gives out the blocks
<clever> so grub thinks its asking the bios to read the disk
<clever> ipxe has a mode, where it hijacks the legacy bios api, and redirects it to iscsi
<clever> but that time, i put /boot on the iscsi as well!
<clever> and i later ported it to an x86 laptop, with basically zero changes
<clever> i originally wrote it for an rpi, with /boot/ on the SD card, and / on iscsi
<clever> and it will then connect the given iscsi device at boot
<clever> (and under swapDevices too!)
<clever> pbb: this seamlessly adds a fileSystems."/foo".iscsi set of options
<clever> yep
<clever> the default under options just sets config = mkDefault "foo"; i believe
<clever> it will behave more like you did fileSystems = [ { device = "/dev/sda1"; mountPoint = "/boot"; } ];
<clever> so when you fileSystems."/boot" = { device = "/dev/sda1"; };
<clever> and the config defines an mkDefault over the name
<clever> pbb: in this case, the function returns a set with both options and config
<clever> pbb: the function you give to that system, will take something in the form of { name, config, ... }: i think
<clever> and nixos-rebuild to remove will likely hang as well, so --option
<clever> fresheyeball: remove it from your config, and nixos-rebuild, or --option
<clever> yl[m]: read nix.conf, find the field cachix is in, and then --option a variant without cachix
<clever> yl[m]: you can use --option to overwrite any nix.conf flag
<clever> but more pure
<clever> IFD is also a form of unsafeperformio
<clever> (if you ignore IFD)
<clever> but all builds happen when the nix eval is done, and there is no more eval at play
<clever> yeah
<clever> gchristensen: builtins.exec
<clever> and then after booting, you just ssh in, and type justdoit
<clever> so you would add it to the build directions for your install media (iso, usb disk, netboot image, kexec image)
<clever> when used correctly, it will generate a bash script called justdoit, that is in $PATH at boot
<clever> muvlon: read line 13
<clever> rpi has different rules of course
<clever> no fs, never formated, never mounted
<clever> if EFI is off, then you must make a 1mb bios boot partition, if you want legacy on gpt
<clever> correction, optional bios boot partition
<clever> this will create 3-4 partitions, boot, swap, root, and an optional ESP
<clever> muvlon: the only time i have nix manage partitions, is via a bash script at install time
<clever> samueldr: that effectively does `nixos-rebuild build` in /mnt/img, without chroot, even if the arch is mismatched (relies on qemu-user-aarch64)
<clever> NIX_REMOTE=local?root=/mnt/img/ nix-env --profile /mnt/img/nix/var/nix/profiles/system --set -f '<nixpkgs/nixos>' -A system -I nixos-config=/mnt/img/etc/nixos/configuration.nix --option system aarch64-linux
<clever> where did i drop it...
<clever> ~2 days ago, i did some even more crazy things
<clever> then it cant find /boot/ on p2

2019-01-18

<clever> the `b` command
<clever> its just a one-time flag you have to set with fdisk
<clever> nope
<clever> muvlon: yeah, u-boot should be able to read ext4
<clever> muvlon: nix-env will persist, but everything in /run/current-system (via configuration.nix) will cease to update
<clever> and the rpi must have a fat32 partition to be able to boot
<clever> muvlon: yeah
<clever> so it just hard-fails if you forget to mount it
<clever> i also try to `chmod 0 /boot/` before i mount the partition
<clever> muvlon: you will need to add a fileSystems."/boot" = { device = "/dev/something"; }; and then manually mount it, and nixos-rebuild switch
<clever> muvlon: is hardware-configuration.nix un-modified?
<clever> muvlon: it must be on the fat32 partition
<clever> muvlon: /boot/ is not mounted
<clever> samueldr: oh yeah, the rpi firmware is mia
<clever> muvlon: and also `ls -ltrh /boot/{nixos,extlinux}/` ?
<clever> muvlon: `ls -ltrh /nix/var/nix/profiles/ /boot/` into a pastebin?
<clever> yeah, that should all be working
<clever> muvlon: and are you using the extlinux bootloader in the config?
<clever> muvlon: is it mounted?
<clever> muvlon: do you have a /boot/ partition?
<clever> muvlon: so all configuration.nix changes are undone at every reboot
<clever> muvlon: your /boot isnt mounted correctly
<clever> muvlon: group changes dont take effect until you relog
<clever> petersjt014: or use an initrd level script to resize before mounting /
<clever> petersjt014: so just shutdown, shove it into an SD<->usb adapter, and resize from another box
<clever> petersjt014: for most filesystems, the arch doesnt matter when resizing
<clever> petersjt014: online resizing just means the `resize2fs` step can be done while its mounted
<clever> so you must then run the right tool, like resize2fs, after expanding
<clever> petersjt014: sfdisk does absolutely nothing to the filesystem, its purely a partition level tool
<clever> petersjt014: there is an aws script that will automate expanding a partition, normally used on AMI's
<clever> danbst: reading the .name of a derivation involves first importing and parsing its default.nix
<clever> petersjt014: i usually use gparted (gui app) for paritition resizing
<clever> oh, and the patch is already in master!
<clever> and its already fixed upstream, https://github.com/obsproject/obs-studio/commit/5cf2b5fbf925412620e2a40552d6348203851cb3 just need to update obs-studio in nix
<clever> seems to have broken other things as far back as sept, https://github.com/mstorsjo/fdk-aac/issues/93
<clever> /build/source/plugins/obs-libfdk/obs-libfdk.c:266:27: error: 'AACENC_InfoStruct {aka struct <anonymous>}' has no member named 'encoderDelay'; did you mean 'nDelay'?
<clever> iqubic: when master passes a certain set of tests, that version becomes the new unstable
<clever> yeah
<clever> obs-studio and my qemu-user stuff
<clever> though it was build-time breakage, that forced me to just remove them from systemPackages, to even update
<clever> a couple things broke on my machine with the last unstable update
<clever> Synthetica: so i could do the entire install remotely
<clever> Synthetica: one time, i made a custom USB image, that launches my vpn on bootup, with ssh configured to allow me in
<clever> goibhniu: one such person recently thought of using an ubuntu vm to solve his in-ability ot patchelf :P
<clever> goibhniu: and then you get stuck supporting them :P
<clever> goibhniu: open the details page on hydra, find the output path, nix-store -r /nix/store/foo ; nix-env -i /nix/store/foo
<clever> iqubic: wait?
<clever> iqubic: it takes a few hours for changes to go from master to unstable
<clever> fusion809: thats the simplest thing
<clever> that could also do it
<clever> fusion809: something depends on it in db.sqlite, sounds like your db is a little corrupt
<clever> the old nix-copy-closure just disabled sig checks automatically if it was root
<clever> Taneb: you must be listed under the destinations trusted-users field (in nix.conf) to disable that safety (root is trusted by default)
<clever> Taneb: or use the unsafe --no-check-sigs flag to turn checks off

2019-01-17

<clever> superherointj: systemd-analyze plot
<clever> bbarker: if nix-channel --list calls it unstable, then you can just let unstable = import <unstable> {}; in ...
<clever> bbarker: you can use multiple channels in the same nix file
<clever> or remove nix from it and update that buildEnv
<clever> bbarker: ah, and that is where the duplicate nix is coming from, so change the nix inside it to be the new one
<clever> bbarker: what does nix-env -q list?
<clever> bbarker: what is causing you to need to set priority?
<clever> bbarker: --set-flag only works on things currently installed, so it cant be used on the name of something that fails to install with -i
<clever> but now you also have the source of truth for fixing all the docs
<clever> the user-env ones affect nix-env, the rest only affect build-time
<clever> phry: there are 3 or 4 different propagated flags, each going to its own file
<clever> phry: thats propagatedUserEnvPkgs
<clever> phry: propagatedBuildInputs only has an effect at build time
<clever> phry: propagatedUserEnvPkgs
<clever> superherointj: journalctl -f -u display-manager
<clever> DanC: which binary are you needing?
<clever> DanC: yeah, looks like the main binary is directly using gui libs
<clever> libQt5WebKitWidgets.so.5 => /nix/store/l6h2aw377jhrda4498sjzjlnkmp0q9ib-qtwebkit-5.212-alpha-01-26-2018/lib/libQt5WebKitWidgets.so.5
<clever> .rstudio-wrapped => bin/.rstudio-wrapped (interpreter => /nix/store/xdsjx0gba4id3yyqxv66bxnm2sqixkjj-glibc-2.27/lib/ld-linux-x86-64.so.2)
<clever> ,locate lddtree
<clever> oh, but GUI stuff doesnt usually play well with docker, is docker even needed? just use nix directly on the host?
<clever> DanC: you will need an extra step in a bash script somewhere, that will symlink ~/.nix-profile to ${foo} and then foo = buildEnv { paths = [ qt things ]; };
<clever> DanC: it will generate a docker image that contains the closure of a given path
<clever> DanC: the nixpkgs stuff to build a docker image is sort of like nix-copy-closure
<clever> DanC: should be able to
<clever> nixpkgs is also able to generate a docker image directly, without using any DockerFile's
<clever> or you can just use nix entirely in the docker like simpson said
<clever> and the docker image itself wont need the nix binary
<clever> DanC: you could fake things by using a pkgs.buildEnv to merge things yourself, and then just symlink ~/.nix-profile in the docker image to that
<clever> and the QT stuff is expecting libs in ~/.nix-profile/lib/
<clever> DanC: nix-env -i will add paths to ~/.nix-profile/
<clever> DanC: nix-shell will just set some env vars to make most tools find things automatically
<clever> DanC: nix-env -i the package then
<clever> DanC: thats newer then what i have, and i updated a few days ago
<clever> another way to query the same thing
<clever> "19.03pre165037.eebd1a92637"
<clever> nix-instantiate '<nixpkgs>' --eval -A lib.version
<clever> superherointj: you need to either give it focus using the mouse (ouch) or disable xterm with services.xserver.desktopManager.xterm.enable = false;
<clever> superherointj: thats the xterm desktop manager, without any WM
<clever> nefix: cant, ipxe also doesnt like to cross-compile, its using gcc, rather then $CC
<clever> gchristensen: go ahead
<clever> nefix: that makes it ignore any other arguments its given
<clever> nefix: still building things
<clever> i could
<clever> hmm, yeah, that should be fine
<clever> ./pkgs/os-specific/linux/syslinux
<clever> $CC is the name of the current compiler, so it remains more valid
<clever> nefix: and the syslinux cross-compile fails, because its using gcc instead of $CC
<clever> Unode: ah, nice
<clever> i think the iso is just a syslinux bootloader, grabbing the ipxe binary
<clever> ahh, and syslinux is what is used to make the ISO bootable
<clever> nefix: aarch64 build fails due to weird gcc params
<clever> gcc: error: unrecognized command line option '-mregparm=3'
<clever> nefix: ive also started a "native" arm64 build under a VM
<clever> ive told it to just ignore that setting, and try anyways
<clever> nefix: nixpkgs claims syslinux doesnt work on arm, and ipxe somehow depends on syslinux
<clever> nefix: attempting the above build locally, 9/30 done so far
<clever> Unode: nice
<clever> nefix: this forces nixpkgs to ignore the fact that syslinux is "unsupported"
<clever> nix-build '<nixpkgs>' -A pkgsCross.armv7l-hf-multiplatform.ipxe --arg config '{allowUnsupportedSystem = true;}'
<clever> nix-repl> perl.version or "default"
<clever> Unode: yeah, that nixpkgs is too old to have a perl.version, you could either upgrade, or just hard-code the version for now
<clever> nefix: it claims to not support aarch64
<clever> error: Package ‘syslinux-2015-11-09’ in /nix/store/qgimqkw4dcza4zddkmbfhmgg6ca8inz8-nixos-19.03pre165037.eebd1a92637/nixos/pkgs/os-specific/linux/syslinux/default.nix:66 is not supported on ‘aarch64-unknown-linux-gnu’, refusing to evaluate.
<clever> nefix: just run `nix-build '<nixpkgs>' -A ipxe` on an arm machine
<clever> Unode: what version of nixpkgs are you on?
<clever> nefix: probably
<clever> Unode: wrapProgram $out/bin/perl --set PERLPATH "$out/lib/perl5/site_perl/${perl.version}"
<clever> nefix: but you can use a normal override to set makeFlags that impact the build: https://github.com/cleverca22/not-os/blob/master/ipxe.nix#L64-L85
<clever> nefix: those files by default
<clever> ipxe.dsk ipxe.iso ipxe.lkrn ipxe.usb undionly.kpxe undionly.kpxe.0
<clever> > pkgs.ipxe
<clever> nefix: ipxe is already packaged in nixpkgs
<clever> > perl.version
<clever> [clever@amd-nixos:~/apps/unode]$ ls result/bin/perl -lh
<clever> [clever@amd-nixos:~/apps/unode]$ ls result/lib/perl5/site_perl/5.28.0/ -l
<clever> looks like we want to makeWrapper the perl
<clever> propagateBuildInputs ceases to do anything once the nix build is done
<clever> Unode: then you just want the buildEnv itself, nothing more
<clever> what are you trying to do then?
<clever> it also needs a src= if you want it to build anything
<clever> mkDerivation is missing a name=
<clever> you still need a name = "something"; on both buildenv and mkderivation
<clever> use ls to verify the paths are right
<clever> let foo = buildEnv { ... }; in stdenv.mkDerivation { PERLPATH="${foo}/lib/perl"; ... }
<clever> buildEnv to make a /nix/store/foo/lib/perl dir with everything, then add that dir to PERLPATH
<clever> Unode: you must add the buildenv to the PERLPATH
<clever> yeah, i think buildEnv would be best
<clever> i just tossed an ISO at it and installed normally
<clever> ah, i never tried importhing things
<clever> aleph-: seems to run fine for me, whats it not doing right?
<clever> then you can just f12 any machine into net-booting, and boom, same thing
<clever> it sets up everything required for network booting, on the configured ethernet card
<clever> aleph-: this one is almost more worm-like
<clever> aleph-: you may now spread the love for nixos! :P
<clever> or, run justdoit in nixos, and it will format the hdd, and install nixos!
<clever> if you reboot, the old OS will resume, as-if it had an improper shutdown
<clever> boom, the machine is now running nixos from a ramdisk, you can do as you please, ignore the existing OS
<clever> upload it to a linux server, unpack to /, and then run /kexec_nixos as root
<clever> aleph-: the nix code in here, will generate a special tarball
<clever> aleph-: oh yeah, i just remembered how you can mix some of my old stuff with metaspoilt for fun
<clever> and then control a remote server
<clever> ah, so you can use the client without the server
<clever> nix would have helped a lot back then, since it can repair such things trivially
<clever> aleph-: last time i played with metasploit was on windows, then an anti-virus ate half the files and it never worked right
<clever> and nixos-rebuild --upgrade, will call nix-channel --update for you
<clever> yeah, --add and --remove dont take effect until you --update
<clever> and also remove nixos from the non-root user
<clever> non-root should usually be empty
<clever> evanrelf: root should have a single channel called nixos
<clever> evanrelf: it sounds like you deleted all channels on root
<clever> evanrelf: also, `sudo nixos-rebuild switch --upgrade` updates the channels for you