<gchristensen>
I think I fixed the issue last night about SSH keys being replaced on every reboot, by storing the host keys on the disk and copying them back in to place at startup
<gchristensen>
andi-: looks like your PR is missing an SSH public key
<andi->
gchristensen: derp.. will fix that m(
<gchristensen>
:)
<gchristensen>
it should probably be a key dedicated to your root user fwiw
<andi->
yes
<andi->
it is
<gchristensen>
cool :)
<andi->
gchristensen: fixed
<gchristensen>
ok :)
<sphalerite>
gchristensen: why dedicated to the root user?
<gchristensen>
because you're going to have a copy of it in a root-accessible spot, and it'd just be good hygiene
<sphalerite>
gchristensen: what if I keep it on my yubikey? :p
<gchristensen>
then your nix-daemon will have a hard time accessing it I think ...
<sphalerite>
(Also, aren't all spots root-accessible?)
<gchristensen>
s/accessible/exclusive/
<gchristensen>
IMO, I think it'd be a Good Idea to not share an SSH key with your root account as with your user account, but that may just be my paranoia
<sphalerite>
I don't see why it wouldn't work if I set systemd.services.nix-daemon.environment.SSH_AUTH_SOCK or similar
<gchristensen>
and obviously I can't enforce it
<sphalerite>
I'd have to try it though of course
<sphalerite>
Haha yeah, but with security it's always best to ask rather than assume! :)
<sphalerite>
As far as malicious actors go, my user account is basically equivalent to the root account, and I'd wager it's the same for most people here
<sphalerite>
The only thing limiting root access really prevents on my machine is stupid accidents
* gchristensen
has no idea what he's doing
<gchristensen>
sure
<gchristensen>
that seems reasonable, especially w.r.t. to the yubikey
<gchristensen>
andi-: ok you're setup (despite the PR not merging yet)
<andi->
k
<andi->
will check that later after dinner.. time to recover the RPi3 and figure out why it got stuck at "Loading kernel"..
<gchristensen>
:)
<samueldr>
andi-: I *think* (haven't tested yet) that the latest 4.14 (as of this week-end) hung my rpi3 too
<samueldr>
4.13 worked, though
<Dezgeg>
humm, let's see if I manage to take a look today
<samueldr>
didn't want to report on bugtracker/IRC until I properly verified, sorry
<>
changed the topic of #nixos-aarch64 to: gchristensen has changed topic for #nixos-aarch64 to: "Get access to the NixOS Community aarch64 build box: https://github.com/grahamc/nixos-aarch64-community-box ... todo: //hydra.nixos.org/jobset/nixpkgs/trunk#tabs-jobs"
<samueldr>
had to have my rpi3 up to build what was needed for the pine64, but now that it's done, the rpi3 is mostly off-duty
<samueldr>
(this was on 3eccd0b)
vcunat has quit [(Ping timeout: 240 seconds)]
<andi->
login works for me. Time to use the CPU time we've there :-)
<gchristensen>
w00t
<gchristensen>
did you see the config snippet in the readme?
<andi->
yes
<gchristensen>
cool
* gchristensen
does his favorite thing when people are building on the box: htop
<andi->
hrhr
<andi->
I figured that I need a bigger screen (better resolution) when I couldn't list all CPUs with top
<gchristensen>
:)
<andi->
started out enabling kodi... expected much.. now it starts getting openjdk working
<gchristensen>
ahh
<gchristensen>
andi-: sorry I meant to ask more specifically, did you set it up as a remote builder?
<andi->
yes I did
<gchristensen>
nice
<gchristensen>
did my instructions suffice?
<gchristensen>
or did you need more?
<andi->
at least I think that I did it.. should try with smaller things probably
<andi->
it's enough
<gchristensen>
try building `hello`
<Dezgeg>
I built an rpi3 image from master and it worked fine for me, using 4.14.x kernel
<samueldr>
(for my yet untested case, it was upgrading from your october image to 3eccd0b)
<samueldr>
(nixos-rebuild switch --upgrade)
<Dezgeg>
maybe try boot.kernelParams = ["cma=32M"]; if that's not yet there
<samueldr>
it was, I did the upgrade two times, the first time cma was bigger since I was previously using the hdmi output with vc4 kernel mode settings and xorg
<samueldr>
the second time, when I though I did something wrong, and had nothing to lose, I simply started from scratch
<grw>
flokli: i backed the gemini few weeks ago :)
<grw>
i think nixos wont be too hard to get working thanks to fine work of those in this channel
<samueldr>
it all depends on the fine work done upstream :)
<samueldr>
not all, but some stuff
<grw>
true
<samueldr>
is it known which CPU exactly is to be used?
<grw>
yep, someone said it earlier, mediatek
<samueldr>
oof, sorry for your loss
<grw>
bad experience?
<samueldr>
cynicism aside, if the maker isn't already known for releasing sources and such promptly, it may never happen
<samueldr>
I backed only one MTK device, knowing full well sources will never be dropped, sources still haven't been dropped
<grw>
hm :/
<samueldr>
though, the note about "Android OS, Linux OS" makes it more probable they will
<samueldr>
I don't want to rain on your parade, that's the sad state of mediatek hardware
<grw>
so you think they will ship binary kernel only?
<samueldr>
do "Planet Computers" have a track record?
<grw>
i was expecting tarball on chinese ftp which barely compiles with gcc4, but no source at all would be worse
<samueldr>
even bigger OEMs shipping MTK often don't release the sources, weirdly enough
<grw>
samueldr: i dont believe theyve shipped anything similar recently, but the team contains members of psion 5 team, which was pretty successful in its heyday