<__red__>
Is the Raspberry Pi the most common target for this arch?
<__red__>
anyone else running anything more exotic?
<__red__>
(I don't suppose anyone's got any of those 128 core servers yet eh? ;-)
<andi->
Do not go done that path :D
<andi->
and yes we've a community machine with 64ish cores or so
<__red__>
tee heee
<__red__>
I want one :-)
<gchristensen>
ampere's machines are affordable (for servers) and have great cpus
<__red__>
Ím waiting for the first generation of ARM servers to fall out of the cloud and onto ebay
<__red__>
shhouldn't be long now
<gchristensen>
probably already did as the cavium thunderx2 has been out for quite some time
<andi->
clever: have you tried the recent RPi kernel images? I just built 5.4.72 with the matching firmware and the machine is a lot more responsive.. Reboots do not take forever.. It doesn't load audio drivers anymore thought and after loading the manually there is no interface..
<__red__>
the closest I've seen to affordable ARM server gear for a human is on ebay, about $1330 ish
<gchristensen>
the cavium thunderx's 96 cores were kinda junky though
<__red__>
I'm wishing I still had access to Niagara CPUs
<__red__>
but they're long in my past :-(
<gchristensen>
you might find even more exotic hw out there: experimental runs where a few racks were made and discarded
<__red__>
that would be nice
cole-h has quit [Ping timeout: 260 seconds]
<__red__>
I'd like to target my phone at some point too
<__red__>
but that's another story
<gchristensen>
the very experimental runs are *annoying*
<gchristensen>
I've got access to a dozen or so of them and I can't really be bothered to make them run properly
<__red__>
How do you get access to such things?
<gchristensen>
being friendly with Equinix Metal / Packet at the time
<gchristensen>
and being able to put the hw to good use
<__red__>
makes sense
<__red__>
so just wishing into thin air doesn't work
<__red__>
got it :-)
<gchristensen>
they have hw they can't really sell, but already have and providing power, cooling, and bandwidth is cheap compared to buying good will and training platform experts :)
<__red__>
every so often the AWS / Google / Facebook recruiters poke me via email
<__red__>
and each and every time I go "nope" to facebook, and I never gather up the courage to ask how much AWS / GCP resouurces AWS/Google employees get
<__red__>
I never ask because I'm worried the answer might make me want to change companies ;-)
<gchristensen>
hehe
<gchristensen>
I have reason to believe Googlers get ... uh ... generous ... amounts of GCP
<__red__>
hah
<__red__>
I have a friend of mine that told me the same thing about AWS
<__red__>
At some point it is inevitable taht I will end up in one of those places
<__red__>
or in one of the security consultancies
<__red__>
it's inevitable with the way the industry is going, but I really don't want to move right now.
<__red__>
ho hum
<__red__>
anyways - a conversation for another time and place
justanotheruser has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
alp has quit [Ping timeout: 256 seconds]
jakimfett has joined #nixos-aarch64
jakimfett has left #nixos-aarch64 [#nixos-aarch64]
jakimfett has joined #nixos-aarch64
<jakimfett>
I've got a nixos system running on a pi 4, and it all works...except 'nixos-rebuild switch' doesn't seem to be making the new configuration persistent (reboots put me back to the default user, without the software installed from before the reboot).
<jakimfett>
...kinda uncertain which layer I've borked things at, anyone want to give their thoughts on the matter?
<jakimfett>
That said, I also tinkered with the boot device, and it's possible I've forked myself over with that, somehow. Specifically, I ran into the '/boot device full' issue (as described here https://github.com/NixOS/nixpkgs/issues/23926), which led me to the page which recommends removing the /boot device entirely:
<{^_^}>
#23926 (by joepie91, 3 years ago, open): When /boot is full, system rebuilds fail
<samueldr>
with the current pi 4 image, you'll have to make sure the FAT32 partition is mounted at /boot
<samueldr>
otherwise you're making copies of the files on the ext4 partition that won't be used by the raspberry pi proprietary bootloader
<jakimfett>
Thanks, samueldr. That explains my issue.
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<jakimfett>
Hmm. So, now I'm back to the same issue as before...getting the error saying "no space left on boot device", is there a way to just bump the boot partition size up to a gig (or at least something larger than 128mb)?
<samueldr>
manually
<samueldr>
sorry :/
<samueldr>
(or edit the derivation in Nixpkgs and build a custom .img)
<jakimfett>
Yeah, working towards custom images, not quite there yet on my homelab.
justanotheruser has quit [Ping timeout: 244 seconds]
<jakimfett>
Any deviation from the normal process on juggling partitions, or is it pretty much the same as Adafruit makes it out to be?
<jakimfett>
(in essence, delete the existing boot partition, resize the main one, create a new one with the desired size, then restore the files from pre-delete?)
<samueldr>
I have skimmed the PDF, not sure where it tells you to delete
<samueldr>
but you can just resize "from the left" the ext4 partition, and resize the FAT32 one accordingly
<samueldr>
I would use gparted for that
<jakimfett>
Page 14
<jakimfett>
And I'm about to attempt that, but I've got to reboot first. brb.
jakimfett has left #nixos-aarch64 [#nixos-aarch64]
<samueldr>
it seems unnecessary to delete the partition
<samueldr>
oh, maybe FAT16
<samueldr>
probably limited in total size
<samueldr>
in that case yeah
<samueldr>
there is nothing special to do with the FAT32 partition
jakimfett has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
jakimfett has quit [Quit: Leaving.]
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<colemickens>
aha, that's a fork of samueldr's work. I merely contributed a tiny change.
<colemickens>
(which was someone else's work from a different project that I just ported into wip-pinebook-pro)
alp has quit [Ping timeout: 240 seconds]
<veleiro>
its more than I was able to find
<colemickens>
It would be nice if GH made it easier to distinguish what type of fork a repo is. Some GH forks are merely for contributions to their parent, whereas others are meant as standalone forks.
<veleiro>
true, i shouldnt say fork in that case
<veleiro>
branch or feature
<colemickens>
veleiro: I just like to give credit, and also I don't know that my fork stays up to date with the changes made in the upstream wip-pinebook-pro.
monk has joined #nixos-aarch64
<veleiro>
well the flake stuff wont be merged in the repo yet i'm sure
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
ardumont has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
PetitOrion has left #nixos-aarch64 ["Quitte"]
justanotheruser has quit [Quit: WeeChat 2.9]
justanotheruser has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
<gchristensen>
clever, putting pics of cats in their auctions to stand out
julm has quit [Remote host closed the connection]
<sphalerite>
yep, they know exactly what they're doing.
<sphalerite>
well, it's not just a picture of a cat, it's a cat sitting on the actual item.
<gchristensen>
I'm pretty sure the cat took the rest of the photos
julm has joined #nixos-aarch64
<sphalerite>
We've all heard that the internet is for porn, but I think that's a lie. Its _real_ purpose is distributing pictures of cats.
<gchristensen>
lol
<sphalerite>
gchristensen: the cat using a camera, or using the cat as a camera?
<gchristensen>
cats have good vision!
<sphalerite>
aw man, now I feel like I need a powerful ARM board again.
<clever>
sphalerite: the pi4(00) is fairly powerful
<gchristensen>
want to play with a 96 core box?
<sphalerite>
I have 2 RK3399 devices and a 3rd on the way though, so…
<samueldr>
clever: hahaha
<sphalerite>
gchristensen: dual thunderx?
<gchristensen>
yea
<clever>
but not 96 core powerful
<clever>
samueldr: relative to previous pi models
<gchristensen>
if you can get it seeing its disks, I'll let you play with it for a few days :)
<samueldr>
sphalerite: my helios64 is in the hands of Canada Posts :)
<sphalerite>
clever: eh, rk3399s are similar, no?
<clever>
sphalerite: which arm core in that?
<samueldr>
it's a BIG.little
<sphalerite>
samueldr: oh wow, so you're getting yours quicker maybe!
<samueldr>
2 A72 and 4 A53
<sphalerite>
samueldr: my last status update was "In transit-Shipment in transit at Dostyq Kazakhstan"
<clever>
sphalerite: ah, like they mashed a pi3 and pi4 into the same core, for power-saving
<samueldr>
now expected for the 16th of this month
<samueldr>
clever: kind of, but older design :)
<clever>
samueldr: so it can basically swap between pi3 and pi4 cores at runtime
<samueldr>
what I think sphalerite meant with "powerful board" was something that's actually workstation worthy
<samueldr>
I would assume, too, one where you could put a Radeon GPU
<samueldr>
clever: not only swap, can use the 6 cores at once
<sphalerite>
clever: not swap, really, rk3399 allows operating them all at the same itme.
<sphalerite>
aaah samueldr ninja
<clever>
ahh
<samueldr>
if you're thinking about NVIDIA's, it's a bit complicated
<clever>
but can 4 A53 beat 2 A72?
<gchristensen>
sphalerite: I'll take that as a no =)
<clever>
pi4(00) has 4 * A72
<samueldr>
clever: wasn't it A76?
<clever>
samueldr: not sure exactly, i know it had a 7
<samueldr>
ah no, A72
<samueldr>
weird, I thought it was A76
<sphalerite>
gchristensen: it's a "sure, if I have the time one day" :p
<__red__>
gchristensen: would you consider a 48 core thunderx box vs the more modern honeycomb?
<__red__>
sorry for the delay - ended up in a work meeting
<sphalerite>
gchristensen: wait, is this on packet.net or hardware access?
<gchristensen>
packet
<__red__>
supposedly, giving me money gives them the impression that they can tell me what to d :-P
<samueldr>
__red__: if you want something that's _meant_ for workstation use, the honeycomb is probably better suited as it's currently having devs working on the rough edges
<sphalerite>
gchristensen: ok, I think I still have my intro credit on packet.net so I could also try it myself :D
<sphalerite>
but yeah, time…
<gchristensen>
__red__: I'm just a monkey who can press buttons, for real opinions I'd ask the other people here
<samueldr>
what I personally want is any kind of box where I can put a GPU to have proper acceleratoin
<samueldr>
anything else and ugh, not worth it
<samueldr>
I would also accept built-in acceleration that is actually usable
<samueldr>
the pi 4's isn't on 64 bit NixOS
<samueldr>
at least, not in a way that matters
<samueldr>
videos are all hitchy, and some other regular desktop use isn't smooth
<sphalerite>
hm, I wonder how panfrost is doing.
<__red__>
when I'm out of this meeting, I may ask what the steps are to get nixos-aarch64 to run on a different target
<__red__>
bbiab
<samueldr>
sphalerite: last I checked ~3 months ago, with stock Nixpkgs + community kernel for the PBP, it was somewhat better
<samueldr>
but not by much
<samueldr>
so I guess right now it must be better
<__red__>
(I'm currently running a yum-based distro on my arm cluster - I would like to change that)
<samueldr>
__red__: unless you do netboots, like gchristensen, you're likely to go through two scenarios: (A) u-boot (B) UEFI
<sphalerite>
__red__: what's your arm cluster composed of?
<__red__>
odroid HC-2
<samueldr>
armv7l
<gchristensen>
<3 netboot
<samueldr>
and even then, with netboot you're still going through (A) u-boot or (B) UEFI
<samueldr>
but with extra steps
<gchristensen>
yup
<__red__>
I'll snag a blank CD card and a machine with a kernel to my desk in the next hour or so and see if I can get the thing to at least boot
<__red__>
I'm guessing I can't get my amd64 hydra to cross-compile arm images right?
<__red__>
images will need to come from the community aarch64 hydra?
<samueldr>
but a couple of the workarounds are in there
<sphalerite>
32-bit arm is a pain in general though.
<samueldr>
it's a big YMMV imo
<samueldr>
if you can cross-compile your everythings for armv7l, it should be fine enough
<__red__>
getting to the image will be the interesting part
<__red__>
bbiab
<samueldr>
your exynos CPU has a bit of "draw the rest of the owl" to it
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<blackriversoftwa>
Hi all, I've been reading the nixos-mobile site a bit wondering if I should take the time to run it on a secondary phone to play with it a bit. Can it actually boot into a GUI e.g. phosh or plasma-mobile yet? I saw xfce in the examples but none of the made-for-mobile Linux GUIs
<samueldr>
we don't have a made-for-mobile GUI going yet, but that's because I've been building from the gound up
<samueldr>
been making the boot flow first-in-class, then worked on abstractions
<samueldr>
I don't know exactly when I'll start working on that, but I will at some point work on porting one of those mobile environments
<blackriversoftwa>
samueldr: ok cool. Are there several contributors or are you mostly working on your own?
<samueldr>
some people contributed device ports
<samueldr>
I've had a few contributions here and there come in
<samueldr>
but as far as regular contributions, if we don't count all of Nixpkgs/NixOS (which this builds on), then it's me
<samueldr>
I'm curious as to the secondary phone you have to port to
<samueldr>
if you tell me what it is, I can try to guesstimate whether it's trivial, easy or hard to port to
<blackriversoftwa>
samueldr: right now I have a Pixel 2 as my primary phone but I'm going to be retiring it from that and then trying out mobile-nixos on it
<blackriversoftwa>
it looks like it already has a port?
<samueldr>
the non-xl variant does
<blackriversoftwa>
`google-walleye`
<blackriversoftwa>
I don't think mine is an XL
<blackriversoftwa>
is the XL substantially different?
<samueldr>
the xl variant is likely trivial, would need a kernel config tweak or two
<blackriversoftwa>
makes sense
<samueldr>
which are all known factors
<blackriversoftwa>
ok well once I have my new phone up and running I'll try flashing an image
<blackriversoftwa>
would you take a patch to thread a `pkgs` param through instead of relying on `NIX_PATH` all over?
<blackriversoftwa>
that would make it easier to pin nixpkgs
<blackriversoftwa>
it also wouldn't disrupt using NIX_PATH since it would just default to `pkgs = import <nixpkgs> {}`
<samueldr>
yes, but only if it also is a good first step into making it work with flakes; I don't want the work to be undone :)
<blackriversoftwa>
ah. I don't actually like flakes all that much but I could make sure it is compatible with that.
<blackriversoftwa>
I like using `niv`for external deps
<samueldr>
yeah, I think you get what I mean; so it won't be problematic with flakes use
<blackriversoftwa>
right
<blackriversoftwa>
I think stripping out all the `<nixpkgs>` references except for a default would be necessary to use flakes as well
<blackriversoftwa>
so I think the work has to be done either way
<samueldr>
you can ignore all of `lib/image-builder/*tests*` for <nixpkgs> uses, btw
<samueldr>
those are not referenced inside of Mobile NixOS proper; the image builder is relatively stand-alone
<samueldr>
so you're left with not that many at least :)
<samueldr>
I think half of them are in comments!
<blackriversoftwa>
Well I tried just overriding `pkgs` using the nixos `nixpkgs.pkgs` option and there were still things from my `NIX_PATH` coming in from somewhere, so there is something remaining to be done
<samueldr>
yeah, there are some
<samueldr>
but not that many to go through
<blackriversoftwa>
actually that is probably what I would do, use that option to thread it through and just set it if there is a non-null `pkgs`argument to `default.nix`
<blackriversoftwa>
ok that will be a good first PR then
alp has quit [Ping timeout: 272 seconds]
<samueldr>
overlay/mruby-builder/default.nix # is a helper to call `nix-build` in that CWD, so it can be ignored too I think
<samueldr>
(I broke the expression and things still built)
<samueldr>
if something _had_ to be done, it would be dropping that file
<blackriversoftwa>
samueldr: ok I'll try to make a PR shortly
zupo has joined #nixos-aarch64
* samueldr
was reading his own code
<samueldr>
so yeah, there's "a" Nixpkgs that's used in default.nix and release.nix for lib stuff, but are not used for any outputs
<samueldr>
the release.nix one is probably harder to get rid of
<samueldr>
the default.nix one might be easier
<samueldr>
but those are not used for their outputs, so that's why I was diving into the implementation
<samueldr>
lib/release-tools.nix # evalWith <- this is what ends up using the NixOS modules system, and I think this is what ends up using the default <nixpkgs> for nixpkgs.path
<colemickens>
(I had a very difficult time trying to find my way through all this)
<samueldr>
I had a very difficult time trying to implement my way through all this the first time around
<colemickens>
I do have something that is usable from flakes though
<samueldr>
I'm 99% sure the reason you get <nixpkgs> in the build output is the reason you would get <nixpkgs> in a NixOS rebuild
<samueldr>
so the solution is likely the same
<samueldr>
release.nix can be ignored, it's used for Hydra