<colemickens>
Okay. I've basically got it working, except that I'm leveraging the netboot module and it "--load-db" with "nix-path-registration" and I'm not sure I fully understand this mechanism.
<colemickens>
I guess I'm not even sure if I want to have the store overlayed on the netboot device if I'm going to have it on NFS read-only anyway.
<colemickens>
weird. It gives up, continues booting and then partway through boot the console output corrupts
cole-h has quit [Quit: Goodbye]
h0m1 has quit [Quit: WeeChat 3.0.1]
<colemickens>
hm, but if I mount /nix read-only from the nfs server, I'm going to basically need to mount over /nix/var though so that the netboot system has its own profiles...
h0m1 has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 264 seconds]
tilpner_ is now known as tilpner
ryantrinkle has quit [Ping timeout: 260 seconds]
h0m2 has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 260 seconds]
ryantrinkle has joined #nixos-aarch64
<colemickens>
my biggest problem is now just that genet seems buggy :P
<colemickens>
and/or there's some sort of race and I need to give the link even longer to come up reliably
<thefloweringash>
sphalerite: I got around to switching my lx2k to your uefi setup (thanks!), but I'm having trouble with the storage. Is this error familiar to you?
<thefloweringash>
[ 177.538630] nvme 0002:01:00.0: can't change power state from D3hot to D0 (config space inaccessible)
orivej has quit [Ping timeout: 240 seconds]
<colemickens>
... why does netboot force grub2 and syslinux on non-aarch64-linux??
<colemickens>
clever: no, I'm just trying this same netboot scenario without arm_64bit and with armv7l-linux instead.
<colemickens>
It looks like there's a condition I need to relax that will probably just work, just not sure of the backstory in the first place. I'll blame it later and see if I can find out
<clever>
# unsure what this does?
<clever>
#"earlycon=uart8250,mmio32,0xfe215040"
<clever>
colemickens: earlycon enables the uart much sooner in the boot process, before device-tree is parsed
<clever>
potentially even before linux has uncompressed itself
<colemickens>
sounds like magic to me
<clever>
colemickens: and thats the MMIO address of ttyS0
<colemickens>
oof ghc isn't even supported on armv7l, maybe this isn't worth the novelty of being able to do it :)
<clever>
colemickens: from what ive heard, the native-codegen doesnt support arm32 at all, and is just starting to get decent arm64 support
<clever>
colemickens: so arm32 works via llvm
<clever>
and i have done ghc on arm32
<colemickens>
I mostly meant from a nixpkgs standpoint :)
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
<colemickens>
samueldr: does *native* armv7l being broken sound right/possible to you?
<samueldr>
possible
<colemickens>
possible, I guess is inherently the case, but you know what I mean maybe :)
<samueldr>
been over a year since I last did native armv7 builds
<samueldr>
I do want to try it again soon
<samueldr>
(I have an rk3399 builder I think will be able to chew through a lot of what I actually want)
<colemickens>
oh my god nixpk.gs is my new favorite thing. thank you x100 qyliss !
<samueldr>
oh right, qyliss++
<{^_^}>
qyliss's karma got increased to 127
<samueldr>
colemickens: maybe some details about armv7
<samueldr>
like, broken how?
<colemickens>
samueldr: sure, it was just above when you replied, the links to the hydra instance.
<colemickens>
My understanding is that floweringash runs this hydra instance and tries to keep an armv7l-linux cache up to date.
<colemickens>
I specifically see a nixos-unstable job that has, at least, coreutils failing since sometime in October.
<colemickens>
And I consider you the person with their finger on the pulse of nixos/arm stuff so I thought you'd have an idea if it was just outright broken or not.
<colemickens>
It's not worth spending time on, though, probably. At this point the main driver of my interest is just that yo/rick mentioned wanting to netboot armv7 on rpi4 which I'm -->this<-- close to having.
<samueldr>
aarch64 more than 32 bit arm, since 32 bit arm is painful :/
<samueldr>
>> Exit code 134 means your program was aborted (received SIGABRT), perhaps as a result of a failed assertion
<samueldr>
right, so it's probably fine to have 134 in tests
<aleph->
Huh this is annoying... angerman whenever you get a sec. In the Helios64 boot order, microSD card is supposed to take priority over the eMMC right? Seems to be ignoring that and still booting to the internal setup.
<samueldr>
nope, emmc has priority on rk3399 aleph-
<samueldr>
for the firmware
<aleph->
Crud.
<samueldr>
now, the firmware (e.g. u-boot) *may* not follow that boot order!
<samueldr>
OH, _that_ is what I should have done today
<samueldr>
get my helios64 up
<aleph->
Hmm guess I need to find u-boot commands to change the boot device.
<samueldr>
you cannot exactly "change" the boot device with u-boot
<samueldr>
the reason why... it's... complicated
<samueldr>
you can, though, boot easily boot once on another device