<emilsp>
I was completely unaware that hydra built these :)
<tilpner>
It appears you followed the link for ARMv6 and ARMv7 devices
<tilpner>
Right above that are the Hydra links
<emilsp>
god, these images don't seem to downloadable at all.
<tilpner>
They just take a while
<tilpner>
But you can probably use nix-store -r if you're impatient
<emilsp>
Usually wget will output something after it starts receiving the response, in this case I get nothing.
<tilpner>
It takes a while
<emilsp>
you are absolutely correct it seems :?
<tilpner>
Hydra needs to create a 2GB archive
<tilpner>
Or... something. I don't know what it did, but it did eventually do that
<emilsp>
still, starts booting into the kernel and then drops hangs the hdmi signal :/
<samueldr>
it might be "fine", depending... it depends on a couple things :/
<samueldr>
I'm not sure how much the mainline kernel progressed, but it can appear to hang with the default configuration since this is a generic aarch64 kernel
<samueldr>
if you have a serial adapter, it would help figuring out whether it fails for real or not
<samueldr>
and the hdmi output might get "broken" by the way the raspberry pi 3 tells the user it is lacking power
<emilsp>
unfortunately, I do not have a serial adapter on hand
<samueldr>
switch VT with alt+f2, then back with alt+f1
<emilsp>
as far as power goes, it's being fed by a psu rather than a regular usb port, so it should be ok
<samueldr>
the raspberry pi 3 is quite voracious
<emilsp>
trying to switch tty's doesn't help :(
<samueldr>
u-boot did show up fine beforehand, right?
<samueldr>
(up to Sarting the kernel?)
<emilsp>
yep
<emilsp>
at some point, I could even ping it
<emilsp>
now whenever it comes up, I can't.
<samueldr>
hmm, the fact it was network reachable is good, but the fact it (might have) stopped responding is annoying :/
<samueldr>
the first boot will be longer since it re-hydrates the system's states after expanding the partition size
<samueldr>
not sure what are the failure modes if this is stopped abruptly
<emilsp>
how long should the first boot be ?
<samueldr>
I don't remember / have no idea
<samueldr>
my raspberry pi setup is tied up can't boot it up with a fresh image to check the state of things :/
<emilsp>
no worries, I'll leave it to do it's thing unbothered for 30 minutes now and see what happens.
<emilsp>
is networking enabled by default in the install image?
<samueldr>
yes, just like the installer iso
<samueldr>
which means that openssh is present on the image, but disabled by default
<emilsp>
that's fair.
<samueldr>
(it's built on the same profile)
<emilsp>
how laborious would it be to build my own image so that I can have ssh access set up? could I have ssh during initrd?
<samueldr>
with access to an aarch64 machine to do the native build, just as laborious as with the "normal" installer image
<emilsp>
and with no such access?
<samueldr>
without one, I don't know about the state of cross-compiling a complete system just now
<emilsp>
that's fair. I'll likely not do any of that and just hope that it boots itself with a freshly dd'd sd card in 30 minutes
<emilsp>
woop, it's pingable after a fresh reflash and enough waiting.
<samueldr>
a good test to see if it "works" is to blindly type reboot (and enter)
<samueldr>
you should be in a terminal with superuser access
<samueldr>
if it reboots, then something is up with the graphic stack (unsure where to go from there)
<emilsp>
blindly typign reboot did nothing :/
<samueldr>
not sure whether it would be pingable during the house-keeping it does on first boot
<emilsp>
welp, when it first boots, it populates the root fs right?
<emilsp>
thus, it creates an /etc/nixos/configuration.nix, right?
<samueldr>
expands it and touches some files, I don't recall which ones should or shouldn't be there
<emilsp>
if I wait long enough for these files to be created, can I mount the sd card and edit the config to have openssh ?
<samueldr>
hmmm, I'm doubting whether the service is default disabled or not; if it isn't you should be fine addint to /root/.ssh/authorized_keys imperatively
<samueldr>
if it is disabled I'm not sure how to handle that
<emilsp>
well, port 22 gets refused, so I take it that it's disabled.
<sphalerite>
emilsp: re "how laborious": you can probably do it by installing nix on a non-nixos distro and building it from there.
<sphalerite>
(assuming you have a non-nixos aarch64 distro working on the pi)
<samueldr>
(most distros shipping for the pi ship armv7 since that's what the raspberry pi foundation supports)
<samueldr>
so it'd have to be checked carefully :)
<emilsp>
arch allegedly is better supported with armv8/aarch64
<emilsp>
so I might try that another day.
<samueldr>
just now booting an (albeit earlier) sd image to the initial generation
<samueldr>
and annoyingly it boots fine with working graphics :/
<samueldr>
though I can confirm that `systemctl status sshd` is `Active: inactive`
<emilsp>
how much earlier?
<emilsp>
maybe my image is borked, so I'd be happy to test yours out.
<emilsp>
if it was built by hydra ofc
<samueldr>
it's from the 18.09 release, probably like 2-3 months ago
<samueldr>
I'm waiting on the image download
<samueldr>
I'll flash it to check
<samueldr>
waiting on `dd` to finish
<samueldr>
the only difference will be it's written on an usb drive, but it should be the same
<samueldr>
and uh, just to double-check, it's the 3B, not the 3B+, right?
<emilsp>
oh, that might be a monkey wrench I wasn't aware of :/ let me double check
<samueldr>
support should be mostly on par, but maybe there are some subtle differences
<emilsp>
model b v1.2
<samueldr>
u-boot
<samueldr>
starting kernel
<samueldr>
(sharing here the current step it's at)
<samueldr>
switched to VT
<samueldr>
console login
<samueldr>
it's way faster on that usb drive than on an SD card
<emilsp>
hmm, so my raspi might be borked then :> Got it 2 days ago for the sole purpose of running nixos.
<emilsp>
I'll try out the official raspi image.
<samueldr>
can't check on the board what model it is exactly
<samueldr>
but pretty sure it doesn't mean the raspi is broken
* samueldr
searches for the meaning of model b v1.2
<emilsp>
that's what's written on the PCB right under all the pins
<samueldr>
hmmm, model b v1.2, might it be a raspberry pi 2 with the 64 bit cores?
<samueldr>
okay, so we should be working with the same hardware
<samueldr>
one thing I know: sometimes the screen it's attached to can cause different results for the graphics stack, and sometimes will just not work
<samueldr>
but it shouldn't just fail the whole boot
<samueldr>
it should still respond to `reboot` :/
<emilsp>
well, this is a 2560x1440 display, maybe this isn't something the pi is equipped to deal with.
<samueldr>
it should go up to and stop 1080p, but maybe it tries to do something funny?
* samueldr
could try with one of his benq 1440p displays
<emilsp>
the only other _screen_ I can test with is a 32" 720p screen :D I'll try that out shortly. Yea, I'm worried thati's doing something funny
<samueldr>
just tried with a crummy 1600x900 display on which u-boot is just broken, raspi boots to VT fine :/
<emilsp>
seems like the ubuntu image boots just fine
<emilsp>
or, I at least get to see my tty
<emilsp>
this is aggravating
<emilsp>
let me try out my ancient plasma
<samueldr>
aarch64 with mainline kernel?
<emilsp>
doubt it's aarch64 or mainline, this is straight from the official raspberry website
<samueldr>
the graphics stack on the foundation's kernel is (apparently) wildly different to the mainline kernel one
<samueldr>
nothing weird to report on the 1440p display, the display's OSD confirms it's 1080p
<emilsp>
just unscrewed the monitor arm in which my hdmi cable, plugged it into the plasma TV, and now I see it booting up just fine :)
<emilsp>
this is not aggravating at all
<emilsp>
but hey, it seems to work now
<emilsp>
dell U25118D is clearly incompatible with nixos on the raspi 3 as of 19.03
<samueldr>
:/ it'd be neat to know why, and report it, but I wouldn't even know where to start on that
<samueldr>
good to know if others have trouble seeing things past u-boot that it might really be the display
<emilsp>
uart might be handy
<samueldr>
it definitely is
<samueldr>
once you start collecting those puppies^W SBCs
<emilsp>
so, now that I've got a terminal, what's the easiet way to get a nixos thing on it that will boot, dhcp itself an address and run sshd?
<samueldr>
it should do all first three already (boot, dhcp, address), the latter one I'm not sure what the easiest is
<emilsp>
I see. Can't I just run nixos-build from the plasma TV ? It should end up rebuilding, right?
<samueldr>
yes you could
<samueldr>
the configuration.nix file will be read-only, but that's simply an artifact from being copied from the nix store
<emilsp>
yep, I've already forced stuff into it
<emilsp>
do I have to manually add the binary cache?
<emilsp>
and do I need network access on it for the rebuild (I think I do) ?
<samueldr>
with aarch64, the binary cache will be already configured and fine
<samueldr>
and you might need network access, though unsure for just that setting
<emilsp>
heh, I've already ran out of space
<emilsp>
seems that the resizing failed
<emilsp>
eh, will reflash again
jtojnar has quit [Remote host closed the connection]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
finally wrote a simplified kernel builder for mobile-nixos, will be easier to integrate the common required bits across the different similar and dissimilar OEM trees
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]