<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: 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>
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>
/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>
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?