<{^_^}>
rfcs#87 (by kisik21, 7 weeks ago, open): [RFC 0087] Promote aarch64-linux to Tier 1 support
<Mic92>
Otherwise this might be interpreted as a lack of interest in this architecture.
<gchristensen>
I suppose I shouldn't volunteer to shepherd a PR I'm coauthor of :)
qyliss has quit [Quit: bye]
<Mic92>
Maybe you know some person so that is interested?
qyliss has joined #nixos-aarch64
orivej has joined #nixos-aarch64
evils has quit [Ping timeout: 240 seconds]
<andi->
Remote building with the community builder from a stable nix version is still broken :( Whom do we have to push to deploy a newer image to the community machine?
<gchristensen>
a new image build is scheduled for every day
<gchristensen>
hmm
<andi->
mhm, then this might still be a bug in Nix :(
<gchristensen>
just looked and the build is failing
<gchristensen>
looking ...
<gchristensen>
:clown-shoes:
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
<gchristensen>
zfs becomes slow when it runs out of bytes
<gchristensen>
gotta pour some more bytes in
<n0emis[m]>
I think the rule is that 80% or so should be left free
<gchristensen>
yeah
<andi->
what a waste of space! :)
* andi-
goes buy bigger disks..
<gchristensen>
NAME USED AVAIL REFER MOUNTPOINT
<gchristensen>
rpool 135G 0B 96K legacy
<gchristensen>
now that I have 1M free, it is much faster
<gchristensen>
btw if you find a machine very low on disk, just delete some logs from /nix/var/nix/log
<gchristensen>
FS is writable, so you don't need to play remount tricks
<andi->
There is also this 6 or 8MiB in the db folder :)
<gchristensen>
LOL
<andi->
ahh the reserved file is 8MiB
<gchristensen>
yeah, sometimes that isn't sufficient
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
Raito_Bezarius has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
bennofs__ has joined #nixos-aarch64
julm has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 246 seconds]
marek has joined #nixos-aarch64
marek has quit [Changing host]
justanotheruser has joined #nixos-aarch64
orivej has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
dev_mohe has joined #nixos-aarch64
cole-h has quit [Ping timeout: 265 seconds]
dev_mohe has quit [Remote host closed the connection]
cole-h has joined #nixos-aarch64
superherointj has quit [Quit: Leaving]
LinuxHackerman has quit [Ping timeout: 245 seconds]
leonardp has quit [Ping timeout: 245 seconds]
Liam[m] has quit [Ping timeout: 245 seconds]
cepheus has quit [Ping timeout: 245 seconds]
bennofs[m] has quit [Ping timeout: 245 seconds]
edrex has quit [Ping timeout: 245 seconds]
LinuxHackerman has joined #nixos-aarch64
cepheus has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
fgaz has quit [Ping timeout: 245 seconds]
Liam[m] has joined #nixos-aarch64
Jassuko[m] has quit [Ping timeout: 245 seconds]
thefloweringash has quit [Ping timeout: 245 seconds]
leonardp has joined #nixos-aarch64
edrex has joined #nixos-aarch64
fgaz has joined #nixos-aarch64
Jassuko[m] has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
<samueldr>
qyliss: aarch64 laptop?
<qyliss>
samueldr: NetBSD developer friend lent me a Pinebook Pro
<samueldr>
neat
<samueldr>
any docs about the netbsd "boot process" for it?
<qyliss>
because I kept accidentally ^C-ing QEMU, and FFS doesn't handle that well, so I kept having to start my VMs over
<samueldr>
oh mon:stdio IIRC makes qemu's serial console resilient to ^C
<qyliss>
samueldr: oh, no, I got corrupted filesystems every time
<qyliss>
regardless of whether metadata journalling was enabled or not
<qyliss>
the NetBSD folks claim this is a QEMU bug
<samueldr>
I thought you meant you were using ^C and qemu quit :) which *is* an issue with defaults
<samueldr>
but if there's additional trouble, yee-ouch
<qyliss>
I was running graphical QEMU, so ^C to quit in the terminal was expected
<samueldr>
ah, good
<qyliss>
but it was not intentional that it destroyed the filesystem every time
<qyliss>
anyway, what I had to do was write the aarch64 generic NetBSD image to the disk, then write uboot over the top of it
<qyliss>
pkgsrc has a pinebook pro uboot build in it
<qyliss>
is that the information you were looking for?
<samueldr>
alright, sounds about as I expected
<samueldr>
do you know if they use UEFI boot?
<samueldr>
(I'm / I will be searching anyway)
<qyliss>
I can ask
<samueldr>
oh, their u-boot build relies on downstream binary blobs :(
<qyliss>
NetBSD friend is not aware of UEFI on the PBP at all
<samueldr>
U-Boot supports UEFI, I assumed all BSDs used its UEFI support now for boot, but I'm not knowledgeable in anything BSD
<samueldr>
I don't even know why I assumed that
<samueldr>
I assume the display doesn't turn on until NetBSD is in control, right?
<qyliss>
correct
<samueldr>
2021.04 finally has the patches in for that
<qyliss>
uboot, you mean?
<samueldr>
yes
<qyliss>
neat
<samueldr>
though it's kind of a bummer that your aarch64 target is a run-of-the-mill pinebook pro :)
<samueldr>
to me it's in the "totally boring" (which is good) category of aarch64 hardware :)
<qyliss>
my obscurity budget is spent on the "NetBSD+Nix" part of it :P
racoon has joined #nixos-aarch64
<samueldr>
qyliss: how did you acquire the u-boot binaries? built with pkgsrc?
<qyliss>
yeah
<qyliss>
just make pkg
<qyliss>
*make package
<samueldr>
was that cross-compiled or you had to do it native?
<qyliss>
cross-compiled from x86_64 netbsd
<samueldr>
nice
<samueldr>
I've not seen many instructions for other distros/OS about how they "distribute" U-Boot to end-users for similar use cases
<qyliss>
http://armbsd.org distributes pre-ubooted NetBSD images for a big selection of ARM boards, but it's been down for a few days
<racoon>
samueldr: strictly speaking we don't include them in pkgsrc for distribution to end users, that's just a convenient side effect
<qyliss>
oh hi :)
<samueldr>
oh, hi!
<racoon>
h-hi
<samueldr>
I've been interested in the *actual* end-user "installation flow" of other distros/OS to see where NixOS has flaws, and see how it can be made better, either NixOS, or as a whole
<samueldr>
hopefully with the idea that distros don't produce n images, one unique snowflake per board
<samueldr>
because that's... totally unmanageable in the long run!
<samueldr>
so, racoon, if it wasn't for that side-effect, how would users do their first steps into getting NetBSD on their Pinebook Pro? (linking to upstream docs is fine too!)
orivej has quit [Ping timeout: 252 seconds]
<racoon>
samueldr: here's a few ways. when mine arrived I dd'ed the generic image and it booted. another approach is to download the binary package of u-boot from pkgsrc, dd it into the hole in the generic image, then write that
<racoon>
I'm rebuilding my laptop right now and don't have a web browser but there's an INSTALL.html for evbarm that might be enlightening
<racoon>
I'm hoping that more boards get EDK 2 support, it makes installing on the raspberry pi so much nicer
<samueldr>
racoon: may I PM?
<racoon>
ye
<racoon>
oh wait I have lynx, that works
orivej has joined #nixos-aarch64
<samueldr>
those search terms gave me the right place to look at
<samueldr>
though IIRC noneucat tested the path bindings successfully
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<samueldr>
alternatively maybe it changed with recent kernel upgrades
luxemboye has quit [Remote host closed the connection]
luxemboye has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<zhaofeng>
Hmm, it might be the case.
* zhaofeng
should really fix his notifications
<samueldr>
hehe
<samueldr>
I wasn't sure whether your notifications were broken or if you were not available
<samueldr>
ah
<samueldr>
I see what eg25-manager is
<samueldr>
probably better than what I did only to control it through systemd
<samueldr>
though at the same time... having it be exist within systemd things was useful
<zhaofeng>
Yeah, I guess eg25-manager is a cleaner way to handle things. It's nice to be able to control the modem as a systemd unit but it's not really essential
<samueldr>
the main advantage is allowing to block other services on the modem status
<samueldr>
I guess the reporting of the modem status can still be done through a service that way
<samueldr>
even if controlled through eg25-manager instead