<gchristensen>
we can't build anything on hydra for those archs because we don't have adequate (or any) hardware for it
<gchristensen>
and it isn't really sensible to spend time setting up a big rpi cluster for example for it, aarch64 was possible because we could get a single box with 100 cores
<flokli>
gchristensen: i already thought about using qemu-system-arm for builds…
<gchristensen>
that isn't really a tenable solution for hydra.nixos.org, unfortunately
<gchristensen>
especially for full NixOS support which would then require qemu-in-qemu
<gchristensen>
(and already the tests are a bit slow, and sometimes runs in to slow / racey failures)
<flokli>
so what would be the goal? finding a board with much more cpu cores, if a rpi cluster doesn't make sense?
<gchristensen>
IMO, the first thing is to make aarch64 really good and fully supported by The NixOS Community
jj_ has joined joined #nixos-aarch64
<gchristensen>
after that it'll be easier for us/me to convince my ARM contacts to give us a big armv7 system
<flokli>
currently, most of my boards are armv7-based. but I think I'll do much more with aarch64 as soon as the gemini pda arrives in my inbox ;-)
<gchristensen>
yeah :) unfortunately I think we're just not able to sensibly scale out to more platforms yet
<flokli>
so what's the limiting thing? currently missing hardware? or do you think getting aarch64 more and more supported will also fix some build failures on armv7, so it doesn't yet make sense to build it yet?
<gchristensen>
focus and demonstrating success
<flokli>
ok
<Dezgeg>
having aarch64 does help quite a bit in getting rid of many x86-isms in nixpkgs
<gchristensen>
true
<Dezgeg>
(nixos/release.nix is still a thing to refactor)
<gchristensen>
oh my yes
<gchristensen>
and I think if we try to do more than one at a time, we'll end up having bad support for all of them for a long time
<gchristensen>
we've had the aarch64 box for like 1yr and only recently did nixos.org/nix/install support it
<gchristensen>
and while our ARM friends are friendly and generous, they're not doing it for charity, but because it fits with their business plan for growth
<gchristensen>
that is my perspective anyway :$ what do you think, Dezgeg?
<jj_>
hi all, i don't know if this is the right place to ask, but how can i specify in the sd-image-aarch64-linux.img that ssh should start at boot? I want to use it on a rpbi3, and connect to it using ssh over ethernet, as I don't have a hdmi nor usb-ttl connector available. But if I try it now, ssh gives the "connection refused" error ...
orivej has joined joined #nixos-aarch64
orivej has quit [(Ping timeout: 255 seconds)]
<samueldr>
jj_: partial answer: you would do as you would with the x86_64 installer, but import `nixos/modules/installer/cd-dvd/sd-image-aarch64.nix` instead of `installation-cd-minimal.nix`
<samueldr>
ah, the argument to nix-build will change too, to `-A config.system.build.sdImage`, if I'm not mistaken
<jj_>
hmm, so i cannot edit some file somewhere on the image to have it start ssh by default? I ask, because if I look write the image to an SD card, and then look at the contents of the unbooted SD card there's just one folder with files, but after a boot of the rbpi it seems to contain a full system
<Dezgeg>
no official way - I presume you could edit root's .bashrc to run 'systemctl start sshd' and add an authorized_keys to /root/.ssh
<Dezgeg>
as a mega-hacky way
<Dezgeg>
or .bash_profile, whatever the file actually is, I can never remember...
<gchristensen>
jj_: it is because the full system is sort of put in place at "activation" time -- around stage 1 of the boot
<jj_>
sounds like an interesting idea, but unfortunately .bashrc/.bash_profile are - i think? - only executed when a login occurs, however, i cannot login :)
<samueldr>
as with the x86_64 iso, root is automatically logged-in
<jj_>
ah great! then my next question: i guess i cannot just create /root/.bashrc and have it work, but i have to add some configuration in configuration.nix, right? How can i nix-build it then?
<samueldr>
you wouldn't need
<samueldr>
if I understand the situation correctly, the SSH server is already installed, it's simply disallowed to start
<gchristensen>
it is not marked to start by default