<clever>
loook: yeah, and line 132 ran activate, which i think was involved in settupg up /run
<clever>
but systemd will get upset if its not pid 1
<clever>
if you just run it normally without exec, it will drop back to the shell
<clever>
if you exec, it can result in another panic
<clever>
yeah
<clever>
loook: yeah, if you exec stage2 from that shell, it will get pid1 and should try to boot fully
<clever>
no need for a thumbdrive
<clever>
disasm: if you have physical access, you can just pick an older generation, or add init=/bin/sh to the kernel commandline and get instant root
<clever>
disasm: do you have physical access or access to grub?
<clever>
there should be a -c flag and an absolute path
<clever>
loook: but if you want the sshd-config to work, just read /nix/var/nix/profiles/system/etc/systemd/system/sshd.service
<clever>
loook: you can usualy just run sshd without any args and it will work
<clever>
so you can only ping ip's
<clever>
also keep in mind, dns may not work yet
<clever>
it might also need the word default added, ip route add default via 192.241.218.1 dev eth0
<clever>
default via 192.168.2.1 dev eth0 metric 2
<clever>
ip route del 192.241.218.1 dev eth0
<clever>
you may need to delete the 192.241.218.1 route
<clever>
yeah, that should be working
<clever>
loook: what does "ip addr" and "ip route" say?
<clever>
the gateway part is optional if you can ssh in from another droplet in the same subnet
<clever>
it will be required before either route will fit
<clever>
forgot that step
<clever>
oh right, "ip link set eth0 up"
<clever>
loook: that will get you internet access, then you can manualy run sshd with an absolute path and &, which should get you a better terminal and copy/paste
<clever>
loook: "ip addr add 192.241.218.198/24 dev eth0; ip route add 192.241.218.0/24 dev eth0; ip route add via 192.241.218.1 dev eth0"
<clever>
id get the network up first
<clever>
yeah, that confirms its a channel, but that shouldnt have broken it
<clever>
loook: also, do you know how to configure an ip with only "ip" or "ifconfig" ?
<clever>
tab completion should work
<clever>
loook: looks like the contents of a channel got modifyed what does it say if you run nix-store -q --roots on that path?
<clever>
loook: can you screenshot it?, the hashes can help in debugging the cause
<clever>
loook: in theory, once you can get it to boot fully, you can just "nixos-rebuild boot" and it will update the boot config
<clever>
its hashing everything in /nix/store to see if anything is currupt
<clever>
yeah
<clever>
just unset NIX_REMOTE?
<clever>
loook: you may need to export NIX_REMOTE=local i think
<clever>
loook: can you get back into that bash shell and then run "nix-store --verify --check-contents" ?
<clever>
try going back to grub and picking an older generation
<clever>
ah
<clever>
have you tried booting those yet?
<clever>
loook: did you have the option to boot older generations in grub?
<clever>
its jan 1st, 1970, minus your timezone offset
<clever>
yeah, that date is normal
<clever>
loook: try looking in ls -l /nix/var/nix/profiles/system/systemd/lib/systemd/systemd
<clever>
slabity: all i can think of is to modify nixpkgs directly, and maybe send a PR upstream so it always does it that way
<clever>
Mic92: and a one-time inspection of the current IP cant deal with that
<clever>
Mic92: in the case of digital ocean, they will just open your rootfs and tinker with /etc/network/interfaces any time the IP changes
<clever>
slabity: mkBefore and mkAfter cant easily be overridden, you would need to checkout a clone of nixpkgs on the same revision, and just edit the file directly
<clever>
Mic92: hardest part, is ensuring the network will come up in every case, some datacenters expect static ip config, others dhcp
<clever>
Mic92: yeah, it is almost that easy, extract a tar to /, /kexec_nixos, run "justdoit", reboot
<clever>
Mic92: with this, nixops can take over the machine after the justdoit.nix in the same directory has finished installing
<clever>
Mic92: yeah, the kexec requires a working linux kernel, of any distro
<clever>
andrewrk: you will need to boot from the install cd, mount the rootfs to /mnt, and put the new boot at /mnt/boot/, then run "nixos-install --chroot" and "nixos-rebuild boot"
<clever>
Mic92: with the kexec stuff i linked previously, i can do an install without needing any custom iso to be mounted
<clever>
if you use another working nixos droplet, you can mount the old one to /mnt and then do "nixos-install --chroot" to chroot into it, and then do repairs, and restore the previous connections
<clever>
would it be possible to connect that disk image to another working droplet?
<clever>
Mic92: which forces it to drop into a shell
<clever>
dhess: yeah, all nixos instances include nixos-install
<clever>
gchristensen: do you happen to know how well kexec works on aarch64?
<clever>
if you set the system param for <nixpkgs/nixos> with --argstr, you should be able to create an aarch64 version of the tar
<clever>
dhess: basicaly, you upload a tarball to an existing linux machine (any distro), run a bash script, and within ~2 minutes, it will be running nixos from a ramdisk
<clever>
dhess: i havent tried it yet, but you could give my kexec trick a try on arm8
<clever>
similiar for pkg-config, its setup hook adds all inputs to the pkgconfig search path
<clever>
so if gcc isnt in the build inputs, it wont find any other buildinput
<clever>
yeah, gcc has a setup-hook that adds buildInputs to the search path for libs and headers
<clever>
so your just going to give yourself more problems down the road
<clever>
benley: there is no real reason to do it, and the tools usualy dont work right when installed that way
<clever>
deba5e12: correct, you should never put build-time tools like pkgconfig/gcc in the systemPackages
<clever>
yeah
<clever>
ah
<clever>
deba5e12, spinus: installing pkgconfig breaks a lot of what nix does to automate things working, you need to add pkgconfig to the nix-shell args
<clever>
and they list them all in the imports section
<clever>
you can break configuration.nix up into multiple files
<clever>
?
<clever>
this creates an nginx reverse proxy, with automatic ssl from lets encrypt
<clever>
inflames: enablePepperFlash has to be set for the chromium package
<clever>
inflames: which program do you want to enable flash in?
<clever>
and you cant just install flash, you have to enable it within the build options for the thing you want it on
2017-06-09
<clever>
and libuuid still shows, because its an alias of utillinuxMinimal
<clever>
and nix-env is trying to remove duplicates, and it removed the original instead
<clever>
pbogdan: ah, eject is an alias for utillinux
<clever>
11670 eject = utillinux;
<clever>
i find nix-repl to just be better at viewing these things
<clever>
pbogdan: part of the confusion, comes from the attribute path being utillinux, but the name is util-linux
<clever>
wait no, thats not how the attr search works
<clever>
pbogdan: you dont have -A, so its show names, not attribute paths
<clever>
pbogdan: what are you using to query the packages?
<clever>
:O
<clever>
can yoy gist the entire error?
<clever>
what user was it ran as?
<clever>
what about it failed?
<clever>
what about the result from the previous nix-build?
<clever>
what is the value of $NIX_REMOTE?
<clever>
what about when you use something like nixos-rebuild --fast?
<clever>
yeah
<clever>
so the current-shell would work, but only for root
<clever>
but when nix is ran as root, it will bypass the daemon
<clever>
yeah, you would need to be able to do a nixos-rebuild to apply things properly
<clever>
you have to set it in the env for the daemon
<clever>
bachp: ah, when nix-daemon is in play, the current-shell ceases to be enough
<clever>
bachp: nix-build '<nixpkgs/nixos>' -A config.system.build.toplevel
<clever>
bachp: does "type nix-build" show the nixUnstable version?
<clever>
gchristensen: sudo -i is usualy better
<clever>
by default, it uses the nix in the path to build the nix in configuration.nix, then continue onward
<clever>
bachp: "_NIXOS_REBUILD_REEXEC=1 nixos-rebuild" will use the nix commands in $PATH, rather then the "correct" nix
<clever>
bachp: do you have ssh to another nix machine that is working?
2017-06-08
<clever>
mbrgm: however, nixos also gives the disk group +w to the block devices, so that user almost has root anyways
<clever>
mbrgm: i modified your collectd example to wrap smartctl instead, and yeah, once i join the disk group, i can query any hdd i want
<clever>
ison111: nice
<clever>
ah
<clever>
mbrgm: another option is to just edit collectd to do this on its own
<clever>
mbrgm: about the only difference, is the one between trusting that a program will drop root correctly, vs just not giving it root to begin with