<clever>
xj9[m]: did you try running that patchelf command under "nix-shell -p gcc" ?
<clever>
if that can confirm the working and broken system, then you can do "git help bisect", and bisect all of nixpkgs without rebooting or restarting things on the live machine
<clever>
johnramsden: the next step i can think of, does nixos-rebuild -I nixpkgs=... build-vm reproduce the problem?
<clever>
yeah
<clever>
--interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" will always pick the one for the arch nixpkgs is compiling against
<clever>
it wont work right for 32bit ones
<clever>
"--set-interpreter ${stdenv.glibc}/lib/ld-linux-x86-64.so.2" will only fix 64bit programs
<clever>
looks like archive.org is having trouble, links that previously worked are now dead
<clever>
to find out which revision breaks it, and which revision fixes it
<clever>
johnramsden: and then nixos-rebuild -I nixpkgs=/home/clever/nixpkgs/ test/switch
<clever>
johnramsden: if you look at the last ~6 digits of a nixos build, you can see nix channel versions, try checking those out in a clone of nixpkgs
<clever>
so it could be an upstream problem, and nothing to do with your config
<clever>
ah
<clever>
johnramsden: did you nix-channel --update between them?
<clever>
ah, that will probably be faster if your dealing with a bigger set of files
<clever>
johnramsden: you can just ls and diff against any snapshot in here
<clever>
ekleog: oh, and are you interested in netboot and ipxe?
<clever>
the tar is only there to get the full closure of kexec into a machine that lacks nix
<clever>
ekleog: and if you want to skip unpacking the tar, you can nix-build -A config.system.build.image instead, that will give you the files as a directory, rather then a tar
<clever>
ekleog: the testing i recently added does just that with qemu
<clever>
ekleog: you can just unpack the tar and run the kernel+initrd however you like, as long as the kernel cmdline is intact
<clever>
ekleog: yeah, that tarball will contain a kernel, initrd, and the full closure of bash + kexec
<clever>
ekleog: i think it will vary, depending on if your trying to push more data then the network can allow
<clever>
ekleog: which .xz?
<clever>
so the inner tcp just goes ham, and fills up buffers everywhere
<clever>
and the outer most tcp refuses to drop any packets
<clever>
the inner most tcp uses packet loss to adjust its throttling
<clever>
viric: ive also been told that tcp over tcp will result in massive latency
<clever>
ekleog: manualy copy the kernel+initrd to /boot and make them the default in grub.cfg
<clever>
ekleog: that would also be required for cases where the existing os doesnt have kexec enabled
<clever>
ekleog: then you can just pick the installer from grub, and do recovery of any scale
<clever>
ekleog: i have also been considering putting this kernel+initrd into /boot, and giving it its own grub entry, via a nixos option
<clever>
ekleog: you can either do the install manualy over ssh (thats how the kexec was previously used), or edit the justdoit script to do btrfs instead
<clever>
with 1 command, it will nuke /dev/vda and do the entire nixos install
<clever>
ekleog: so if a zfs system with ext4 /boot and zfs / /nix /home is suitable, you could tell nixos to justdoit, and it does it, lol
<clever>
you can configure the kernel to reboot upon panic
<clever>
and if you loose control, it will reboot itself, and come back with the old config
<clever>
if you can still access, cancel with shutdown -c
<clever>
nixos-rebuild test, in combination with "shutdown -r +15" will activate it, and then reboot in 15 minutes
<clever>
and without a control panel from the datacenter, you cant remotely reboot
<clever>
but if the network setup is weird, its easy to get wrong, and then you loose all control
<clever>
if your server has dhcp, it should come back up after the kexec and let you in
<clever>
so you have ~4 minutes left, but you can always "shutdown -c" to cancel the ticking clock, and "systemctl stop autoreboot.timer" to prevent it entirely
<clever>
ekleog: also beware, the kexec is configured to reboot every hour on the hour, as a safety
<clever>
ekleog: but the existing partition layout will persist
<clever>
LnL: added it to my release file for my hydra
<clever>
LnL: i havent tried, but let me see
<clever>
then /kexec_nixos, ssh back in, run "justdoit", give nixos-install a root pw, and reboot
<clever>
dash: as for how its used now, edit both target-config.nix and configuration.nix to include your ssh auth keys, build the tarball, unpack the tar to / on the server (any linux distro works)
<clever>
lol
<clever>
potentialy in any datacentr
<clever>
so i can now create a zfs based nixos install on a remote machine after running ~5 commands, assuming the remote server has dhcp available
<clever>
gchristensen: took one of my older examples from 2016 and merged it with my kexec trick
<clever>
not sure, i havent tried changing the layout on nixos
<clever>
GiGa|Laptop: hasnt happened in a long while
<clever>
personaly, i run nixos-unstable (so i never have to change the channel) and i just delete stateVersion from the config (so such breaking changes happen sooner)
<clever>
GiGa|Laptop: sounds like a network error, try the command again
<clever>
GiGa|Laptop: above that should be another error
<clever>
GiGa|Laptop: only way is to comment them out in systemPackages
<clever>
and if you do care about ipfs, you can manualy move the data to the new path
<clever>
so bumping the state version would effectively result in the loss of all data in the ipfs node
<clever>
ah, for ipfs, it controls where the daemon stores all of the ipfs data
<clever>
fixing that ssh config would change the ssh host pubkey, and set off warnings for all ssh clients
<clever>
ekleog: and i believe only 2 things even use stateVersion, postgres, and sshd (it enables some older less secure ssh host key stuff)
<clever>
for postgres, you would need to dump the entire db as sql, delete the db files, update the stateVersion, and re-import it again
<clever>
the nix database auto-updates itself and has no undo
<clever>
nope
<clever>
it needs to know what the on-disk format of the db is, to pick the right postgres version
<clever>
like postgresql
<clever>
so it can deal with things that break horribly in an upgrade
<clever>
stateVersion tells nixos what version the state was originaly created in
<clever>
no
<clever>
stateVersion shouldnt be changed
<clever>
cement: Virt<tab><tab> in a shell
<clever>
bennofs: oh, never noticed that variant of override
<clever>
srhb: you would probably need to use a foldl' to merge a list of haskell overrides (each in their own file) and then make a single overrides to pass to haskellPackages
<clever>
bennofs: fun
<clever>
bennofs: i'm always fuzzy on which one to get callPackage from
<clever>
srhb: whichever overlay applied last will have set the final value of overrides
<clever>
srhb: yeah
<clever>
there is only a single overrides attribute
<clever>
so only one set of haskell overrides will ever apply
<clever>
each call to haskellPackages.override, will overwrite the previous
<clever>
another problem though
<clever>
and self.haskell might even be better, if you wanted to allow other overlays to change it
<clever>
correct
<clever>
yeah
<clever>
the haskellPackages part
<clever>
and i believe haskell did it first, and nixpkgs copied it
<clever>
yeah
<clever>
so you dont need a .pkgs on them
<clever>
both super and self are variants of the pkgs set
<clever>
srhb: you want to use the superHS directly
<clever>
ben: doCheck = true; will make nixpkgs automaticaly run "make check"
<clever>
ben: if you can get them to work, sure, that will also help detect future breakage
<clever>
your directly editing bytes in the framebuffer, and then re-interpreting them
<clever>
and the arrow keys + enter let you re-run any text currently on the screen
<clever>
the list command just barfs text onto the screen
<clever>
i wouldnt even call that thing an editor
<clever>
and any "garbage" between the elements will be preserved when saving/loading
<clever>
it stores the source as a linked-list of lines of text
<clever>
and if you just "happen" to put some assembly between line 10 and line 20, it would blindly copy it from floppy->ram when loading the "text"
<clever>
another weird thing, is that the c64 just treated the entire program as a linked-list, and would just leave it as a linked-list on the floppy
<clever>
so you had to leave large gaps in the numbers, for future planning
<clever>
Infinisil: the c64 used those numbers just to tell the editor where to insert a line within the program, and it was completely incapable of shifting lines up/down at a later point
<clever>
Infinisil: i first learned that method of priority numbering when i was programming basic on the c64
<clever>
danbst: http-proxy depends on http-proxy', and http-proxy' depends on http-proxy, you need to use the super more somewhere, but this expression looks a bit off, so i'm not sure where
<clever>
then you can insert things at 15, to squeeze between 2 things that would have been too close previously
<clever>
and using 0 10 20 ... 90 as a standard
<clever>
i do think a larger range, like 1 to 99 would be a bit more flexible
<clever>
heh
<clever>
so you can just set it to whatever you want, and it does a sort based on that
<clever>
ah
<clever>
?
<clever>
but also so simple, just sort the names logicaly, rather then inspecting the deps of each and computing a toposort
<clever>
it was basicaly just a for loop over * in bash
<clever>
the old rc.d system did the same thing for services
<clever>
so a rule file with a higher priority can still override it
<clever>
and it only uses the other names if the name attribute is "" at that point
<clever>
and the priority of all the names
<clever>
Infinisil: i can even see the code in there that checks for net.ifnames=0
<clever>
Infinisil: which will land at /etc/udev/rules.d/80-net-setup-link.rules
<clever>
Infinisil: it controls the inclusion/omission of a udev rule file that manages the names
<clever>
bennofs: i thought i saw something in pam, to auto-create any missing directories when you start a session
<clever>
drwxr-xr-x 2 clever users 16 May 2 23:07 /nix/var/nix/profiles/per-user/clever/
<clever>
ah yeah, that one
<clever>
drwxrwxrwt 8 root root 8 Jun 18 2016 /nix/var/nix/profiles/per-user/
<clever>
not on this nixos system, and that would allow anybody to mess with default (roots nix-env) and system (the nixos build)
<clever>
drwxr-xr-x 3 root root 52 May 23 09:01 /nix/var/nix/profiles/
<clever>
i think nixos has things in pam that manage that
<clever>
and the user original installing it needs +w to the default profile
<clever>
each user should own the directory named after them, in /nix/var/nix/profiles/per-user/
<clever>
make a nixbld group, add nixbld{1..5} to the group, chown most of /nix to root, run nix-daemon as root, set NIX_REMOTE=daemon for all users
<clever>
whenever that comes up, i just convert it into a multi-user setup
<clever>
sudo git can do similiar things
<clever>
and using sudo in a single-user setup can break things, leading to root owning parts of the store, and now your single-user cant manage it right
<clever>
on a single-user install, you have direct write access to the store, so sudo isnt needed
<clever>
any user on the system is free to delete any path thats not in use
<clever>
bennofs: without sudo
<clever>
the path is in the arguments of sudo, so its "in use"
<clever>
which also means, "sudo nix-store --delete /nix/store/foo" will never work
<clever>
nix will scan maps, fd, exe, and environ
<clever>
it is
<clever>
yeah
<clever>
yeah
<clever>
so you can ctrl+c your programs, but your doing so blindly, and you cant disconnect
<clever>
with screen, it will partialy connect, but in a write-only fasion
<clever>
sphalerite: ah yeah, ive had to use that for screen on nixos
<clever>
sphalerite: and /proc/<pid>/fdinfo/ shows the seek position within every file, so you could monitor how far along something is in reading a file, without the overhead of strace or pv
<clever>
need a pid namespace to prevent that from being abused
<clever>
sphalerite: and /proc/<pid>/root can even cross chroot borders, in both directions
<clever>
sphalerite: those symlinks also bend the rules, the symlink can point to a deleted file, but still be opened for reading
<clever>
sphalerite: that will show all files its opening
<clever>
sphalerite: simplest thing i can think of is to peek in the /proc/<nix-build/store pid>/fd/ while its dumping it
<clever>
UrsidaeJohn: a similiar line targeting PATH would probably fix your issue
<clever>
UrsidaeJohn: i see this in nixos's sudoers file
<clever>
Defaults env_keep+=SSH_AUTH_SOCK
<clever>
but on nixos, it doesnt
<clever>
for example, on gentoo, sudo resets $PATH to "sane defaults"
<clever>
sudo on some distros will reset $PATH for security reasons
<clever>
so the editor itself never gains root
<clever>
UrsidaeJohn: then when the editor quits, sudo will copy it back to the original place
<clever>
UrsidaeJohn: there is also "sudoedit" which will copy the file to /tmp owned as the current user, and run $EDITOR on it
<clever>
same
<clever>
thats what the man page says
<clever>
LnL: i think thats an optional feature
<clever>
-D create all leading components of DEST except the last, then copy SOURCE to DEST
<clever>
xificurC: did you mkdir -pv $out/bin/ first?
<clever>
then it shouldnt need root to do it
<clever>
where does it store that data after gaining root?