<zhaofeng>
Ha, for firefox, I just modified firefox-bin to pull down the binaries from Manjaro ARM 😄
<dxb[m]>
lol
<dxb[m]>
that's a good idea
<dxb[m]>
i think i got it now though... but now i'm having to build the kernel apparently
ajs124 has quit [Quit: Bridge terminating on SIGTERM]
ajs124 has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
<dxb[m]>
ugh... i don't want to build this kernel. i'd rather use one that's already built. anyone know how to do that?
<dxb[m]>
hm i might have an idea actually
<dxb[m]>
ok, there we go... just had to checkout the commits from the latest successful pinephone build in hydra
<veleiro>
i just wanted to say, incredible work with arm64 and nixos. i was struggling with it last year especially because of rebuilds but now i just easily got a pi 4 up and running on nixosUnstable with flakes, no problem
<sphalerite>
I have the tools but am a bit scared to try desoldering the chips just in case I do something wrong
<sphalerite>
(I do have the UBports edition)
orivej has joined #nixos-aarch64
Tofe has joined #nixos-aarch64
v0|d has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
srk has quit [Remote host closed the connection]
srk has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 250 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Ox4A6F has quit [Quit: authenticating]
Ox4A6F1 has joined #nixos-aarch64
marek has quit [Ping timeout: 252 seconds]
zupo has joined #nixos-aarch64
marek has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev_mohe has quit [Quit: dev_mohe]
Tofe has left #nixos-aarch64 [#nixos-aarch64]
zupo has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
adisbladis has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
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…]
artturin has joined #nixos-aarch64
zupo has joined #nixos-aarch64
ServerStatsDisco has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
sebbadk[m] has quit [Quit: Idle for 30+ days]
justanotheruser has joined #nixos-aarch64
<dxb[m]>
i'm building mobile nixos images for my pinephone. once i build an image with `-A build.disk-image` and it builds the full system image, am i able to then make changes to my build and run a new build that doesn't rebuild the stage1 stuff? based on the documentation it seems like i can build some kind of partial image and flash it on top of my existing image without destroying parts of the existing image but i'm not sure
<dxb[m]>
i'm understanding properly. can someone explain? it'd be super nice if i didn't have to make full builds every time i change some stuff
cole-h has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<hexa->
things you've already built should be cached in your nix store
<hexa->
if you change stuff that these results depend on expect to build them new
<samueldr>
sphalerite: sadly, the information about what feature should and should not be working with and without the mods are not great
<samueldr>
there is no clear table
<samueldr>
and last I asked, JumpDrive should be working even without the mod? but I'm not even sure
<dxb[m]>
hexa- yeah, i know it's not rebuilding the packages, but it still takes a long time to build the actual image
orivej has quit [Ping timeout: 260 seconds]
<dxb[m]>
and isn't stage 2 independent of stage 1?
<samueldr>
in mobile nixos, they are more independent yes
<samueldr>
but for the pinephone it is a bit more subtle
<samueldr>
there is stage-0, stage-1 and stage2
<samueldr>
stage-0 is stage-1, but it will kexec into the kernel+stage-1 of the selected (or default) generation
<samueldr>
reading what you said, changing something in the configuration will rebuild the disk image, because things changed, but it shouldn't rebuild "everything"
<samueldr>
I guess it depends on the exact change
<samueldr>
but if e.g. you change a configuration that affects stage-1, "stage-1" will be rebuilt, as in the filesystem image for stage-1, too, and then the disk image will need to be rebuilt too
<samueldr>
but dependencies shouldn't need to be rebuilt
<samueldr>
unless things were garbage collected from your store
<dxb[m]>
so here's the scenario: i'm tweaking my image a bit because it boots to the login screen, i try logging in, something with my wm is borked so i make a small tweak to that and rebuild. literally all packages are still cached but build takes like 30 minutes on my pi and it's 3.4gb that i then have to scp and write to an sd card. that's what i'd like to reduce. i understand how nix's package caching works
<samueldr>
ah, on a Pi, is it running off of an SD card?
<samueldr>
if so, I assume it's that long because of I/O
orivej has joined #nixos-aarch64
<dxb[m]>
oh, looking at the docs i guess it's just the boot stuff that you can build on its own :/
<dxb[m]>
yeah it's on an sd
<dxb[m]>
would it be quicker if it was pxe'd?
<samueldr>
yeah :[ SD cards on raspberry pi gives aarch64 a bad name :)
<samueldr>
no idea
<samueldr>
maybe
<dxb[m]>
lol
Mindavi1 has joined #nixos-aarch64
<samueldr>
I know on a non-raspberry pi, going from SD to NVMe was multiple order of magnitudes quicker
<samueldr>
(like 2 order of magnitudes)
<dxb[m]>
hrm
<samueldr>
and more importantly... the machine stays usable even with heavy I/O :/
<samueldr>
really can't wait until they have a "main" raspberry pi board with something else than SD
<samueldr>
but that won't help your issue
<samueldr>
dxb[m]: get ssh going
<samueldr>
then you can nix-copy-closure to/from
<samueldr>
that's what I do on my pinephone
<dxb[m]>
what do you mean?
<samueldr>
hmm
<dxb[m]>
that sounds magical :o
<samueldr>
not necessarily only nix-copy-closure
<samueldr>
but you can use a remote builder with NixOS
<samueldr>
in many ways
<samueldr>
with Nix* though nixos-rebuild also has another method to do so
<samueldr>
so you could rebuild your system and not build on the phone
<dxb[m]>
i have like 3 or 4 pis, would that help?
<samueldr>
ah, you'd need to have your configuration copied to the sd image too, but all doable with SD
<samueldr>
probably not as much since you have a "linear" graph of dependencies to build that each depend on each-other that are I/O heavy :)
<dxb[m]>
ah ok
<samueldr>
I'm trying to think of the easiest to explain method of doing remote builds for your situation and I can't really
<dxb[m]>
i'm not sure i'm following what you're suggesting then. i've never used nix-copy-closure (or even know what it is)
<samueldr>
but the "draw the rest of the owl" is: get ssh access to your pinephone, then use
<samueldr>
nixos-rebuild, wither dry-build and copy the .drv to the builder
<Mindavi1>
What would be a good aarch64 build machine?
<Mindavi1>
Or is using the pinephone feasible too?
<samueldr>
or using --build-host --target-host
<samueldr>
using the pinephone is feasible, but if it's running on an SD card it's going to be slower
<samueldr>
hmmm
<samueldr>
you might want to `man nixos-rebuild`, dxb[m], and read about --target-host, --build-host and --use-remote-sudo
<Mindavi1>
Because I kinda got stuck with my cross-compilation stuff, the gnome stuff is not really easy to get building
<samueldr>
I guess I need to make using `nixos-rebuild --target-host` easier, on my end
<Mindavi1>
But at least I got quite far
<samueldr>
Mindavi1: yeah :( cross-compilation really is a bummer
<samueldr>
using the pinephone is a fine way to do it, maybe you want to run it from usb only, with the display disabled, so there's no harm to the battery
<samueldr>
display disabled since IIRC without the battery the display can cause it to not have enough power to share around
<samueldr>
it's, after all, just a fancy allwinner a64 device
<Mindavi1>
Yeah, jumpdrive boots without battery, but nixos doesn't boot without battery
<dxb[m]>
<samueldr "you might want to `man nixos-reb"> i'll look into this, thanks
<samueldr>
what would be a "good" aarch64 build machine?
<samueldr>
trick question
<samueldr>
the answer is: nothing!
<Mindavi1>
Is there an easy way to disable the display?
<samueldr>
Mindavi1: no idea :)
<Mindavi1>
I did find some servers but €2500 is too much for my hobby projects :p
<samueldr>
yeah
<samueldr>
that's why it's "nothing", there's really no in-between "good"
<samueldr>
except maybe the honeycomb
<samueldr>
but I am yet to see "reviews" about using it either as a builder or as a workstation
<samueldr>
but if an SBC is good enough, the only "least bad" options I can recommend are those with either SATA or PCIe/NVMe on board
<samueldr>
since the first main bottleneck in perfs with SBCs is I/O
<samueldr>
because SD cards are garbage at good I/O :)
<samueldr>
funnily(?) enough, eMMC storage, which is often touted as "the same as SD" is generally better
<samueldr>
but still not amazingly great
<Mindavi1>
Both are not that great
<Mindavi1>
And worse, not very reliable
<Mindavi1>
Especially not if you're gonna write a lot I guess
<samueldr>
eMMC in my experience isn't bad, probably because it's the better binned chips
<dxb[m]>
i'm pretty sure most of my sd cards can read/write faster than the pi's sd slot can manage
<samueldr>
plausible too
<Mindavi1>
Guess I'll start hacking with the pinephone first, since I happen to have that one lying around
<Mindavi1>
Maybe one day I'll look into those SBCs, it would be nice to have a remote builder available sometimes
<samueldr>
Mindavi1: in that case, probably the best bang-for-buck is any well-supported by linux mainline rk3399
<samueldr>
now you have the choice about the exact board configuration... some come with SATA, some with NVMe slots, some with a PCIe slot
<samueldr>
so for a builder-mainly use case, NVMe is probably desirable because it's less of a bother to get in a "nice" package
<Mindavi1>
I saw there's a Pine64 RockPro64 that has that chip
orivej has quit [Ping timeout: 246 seconds]
<Mindavi1>
But the 4GB version is sold out
<samueldr>
yeah
<samueldr>
it's PCIe though, which means that for storage you need to use a "real" PCIe card
<samueldr>
so that becomes a mess to wrangle :)
<Mindavi1>
Mm yeah NVMe would be very handy indeed
<dxb[m]>
what about nvme over usb3?
<samueldr>
dxb[m]: treat it as "just" usb3
<dxb[m]>
pi 4 with 8gb ram and usb3 nvme dongle
<samueldr>
with the Pi the main issue is reliability with usb
<samueldr>
probably power related
<dxb[m]>
ah
<samueldr>
I tried USB and it wasn't good in my case
<elvishjerricco>
CM4 + PCIe->NVMe adapter?
<samueldr>
I don't treat CM4 as a good solution
<elvishjerricco>
(if you can find a CM4 anywhere)
<samueldr>
because at that point you've paid more than self-contained solutions :(
<samueldr>
but those probably proves that the hardware can manage
<samueldr>
I am a bit biased since I ended up getting mine comp'd
<elvishjerricco>
Well the CM4 itself is like $10 less than the equivalent rpi4, and the IO board is $35
<samueldr>
oh!
<samueldr>
they don't sell the heatsink/case kit :(
<elvishjerricco>
(USD)
<elvishjerricco>
Ah
<elvishjerricco>
Yea cooling is actually pretty important for rpi4/cm4
<samueldr>
but then, the Pi4 with CM4 accessories is going to be a bit issue
<samueldr>
because it won't be the "default" configuration for mainline
<dxb[m]>
so samueldr to go back to what you were saying for a sec... should i do a basic config with no gui at all, maybe have it configured to connect to my wifi and have ssh enabled with my ssh key or whatever, and then boot it up from there and look at that section in the manpage you pointed me to?
<samueldr>
dxb[m]: will take some initial setup time to get right, but will allow you to "just" rebuild
<Mindavi1>
The mezzanine is for the nvme?
<samueldr>
Mindavi1: yes
<samueldr>
but I'm not sure it's worth it without the case
<samueldr>
I never ended up finishing describing
<samueldr>
they have some issues with finishing up the software at the moment
<dxb[m]>
yeah, but is that what you mean? starting with a basic setup like that that i can ssh into and then use my pi as a remote builder for the os that's already running on the phone?
<samueldr>
dxb[m]: yes
<dxb[m]>
cool, thanks. i think that gives me a good starting point
<samueldr>
dxb[m]: oh, you could also download the "demo" rootfs from hydra
<samueldr>
which will give you a networkmanager+graphical UI
<samueldr>
so you will be able to connect it from there, and then you can remote
<samueldr>
that'd allow you to skip the initial setup steps
<dxb[m]>
i might do that, but i also don't mind building my own image, it's just that i'm building so many images while i tweak stuff that it's painful to have like a 45+ minute turnaround time just to find out that i didn't fix whatever i was trying to fix
<samueldr>
it's a **really** well put hardware piece, but the software issues are enough to turn off a lot of users
<samueldr>
I'm not sure the total cost is worth it compared to other RK3399 solutions
<samueldr>
**but**, I can attest that it works, with NVMe boot with mainline u-boot, and probably mainline linux when blacklisting f302usb
<samueldr>
dxb[m]: I understand :) and yes it's painful
<Mindavi1>
Mm yeah it is quite a bit more expensive than the rockpro, but if I want to do anything serious it might be worth looking into
<Mindavi1>
At least it's good if it's endorsed
<samueldr>
I wouldn't *endorse* it per se, but it's so close to being real good
<Mindavi1>
What is the 'software issues' part? Drivers?
<samueldr>
"support" from the board maker
<samueldr>
which, thinking just a few seconds, with NixOS you never get support from the board maker :)
AmandaC has joined #nixos-aarch64
<samueldr>
but I'm biased because libre.computer is a bit different from many vendors
<Mindavi1>
Hehe, sure thing
<samueldr>
they strive to ship mainline-based "EBBR" u-boot
<samueldr>
and mainline-based images
<samueldr>
e.g. their amlogic board, out of the box, boots a UEFI USB iso of NixOS
<samueldr>
(to be verified, I don't recall if I had to add a driver for it to work well)
<samueldr>
but their ROC-RK3399-PC had issues for a good while
<Mindavi1>
That is very important to get the software world in a better place
<Mindavi1>
Oh yeah, big beefy supply is always good
<samueldr>
Mindavi1: yes, I keep in touch with that vendor, they are AFAICT really small, but doing the right thing, which ends up costing them some support because they don't just slap a BSP-based ubuntu image out of the door
<samueldr>
Mindavi1: and it's "just" a PD power supply too
<Mindavi1>
The RPi can also be unstable with a lacking supply
<Mindavi1>
Yeah, always handy
<samueldr>
imo this board design is in the top tier SBC designs
<samueldr>
oh, right, the Mezzanine can be configured for PoE
<samueldr>
if it matters for you
<samueldr>
oh, sold out though
<Mindavi1>
I don't have any good routers anyway
<Mindavi1>
Let alone PoE
<samueldr>
but really, compare other RK3399 solutions "all kitted-out" before
<samueldr>
including shipping costs and everything you'll need to get NVMe (or SATA) going
<samueldr>
I can't **recommend** or **vouch** for it, but I want to
<samueldr>
another nice thing is that the important "main" ports are all on one side
<samueldr>
power input (only one of the two type-c works for power), ethernet and HDMI are on the same side
<samueldr>
compare that to the rat's nest of many SBCs where things are routed in the most inconvenient sides
<Mindavi1>
Mm yeah that's good to consider
<Mindavi1>
I'm based in Europe so shipping from US is pretty expensive
<samueldr>
right, there's that to consider too
<samueldr>
I get double-dipped on with shipping :)
<samueldr>
being in Canada, too often from-the-US shipping ends up just as if I was way far elsewhere in the world
<samueldr>
while it may be that my location is closer to the shipping origin than some other mainland US state :)
<Mindavi1>
Mm yeah that's not great
<Mindavi1>
I can get my stuff easily from Europe normally, so that's good
sciamp has joined #nixos-aarch64
Mindavi1 has quit [Read error: Connection reset by peer]
Andoriyu has quit [*.net *.split]
ajs124 has quit [*.net *.split]
AmandaC has quit [*.net *.split]
julm has quit [*.net *.split]
patagonicus has quit [*.net *.split]
dotlambda has quit [*.net *.split]
mla has quit [*.net *.split]
matthewcroughan has quit [*.net *.split]
ajs124 has joined #nixos-aarch64
julm has joined #nixos-aarch64
mla has joined #nixos-aarch64
patagonicus has joined #nixos-aarch64
matthewcroughan has joined #nixos-aarch64
AmandaC has joined #nixos-aarch64
Andoriyu has joined #nixos-aarch64
dotlambda has joined #nixos-aarch64
matthewcroughan has quit [Max SendQ exceeded]
matthewcroughan has joined #nixos-aarch64
Guest36338 is now known as dsal
rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-aarch64
<dxb[m]>
samueldr: so i messed up my config so it didn't connect to my wifi (i'm pretty sure i know the reason) but even if i plug in a keyboard it doesn't accept my username and password when i get to that login prompt with the green welcom text. i kinda feel like i've never successfully logged in at that screen before. is that normal?
<dxb[m]>
or does it maybe have some stock credentials at that point and not the ones from my config yet?
<samueldr>
dxb[m]: the keyboard works, right?
<dxb[m]>
yep
<samueldr>
good
<samueldr>
stupid question, but that's like the basic requirement for this to work
<samueldr>
how are you building up your custom image?
<samueldr>
off the top of my head, this looks fine
<samueldr>
assuming the hashedPassword is right, that should be fine
<dxb[m]>
hrm
<samueldr>
look at examples/demo there's a "nixos" user with a non-hashed password
<dxb[m]>
ok
<samueldr>
in case there's something in there that's missing
<samueldr>
but I don't think so without comparing
<dxb[m]>
i can just put the password in plaintext too, maybe that'll make it easier lol
<dxb[m]>
i'm just using a dummy password anyway
<samueldr>
and the build picks-up your local.nix changes...
<samueldr>
.... I assume so since you rebuild the image and it takes a while
<dxb[m]>
yeah, if i make changes to only my local.nix i get a different output hash
<samueldr>
yeah, just fishing for obvious issues
<dxb[m]>
also when i was building with a gui it would launch the gui
<samueldr>
dxb[m]: try building the uefi-x86_64 vm on your x86_64 system using the same config
<dxb[m]>
is that part of mobile-nixos?
<samueldr>
yes
<samueldr>
I use this: `nix-build ./examples/demo/ --argstr device uefi-x86_64 -A build.vm && ./result` to run the demo
<samueldr>
so in your case
<samueldr>
I use this: `nix-build --argstr device uefi-x86_64 -A build.vm && ./result
<samueldr>
>> nix-build --argstr device uefi-x86_64 -A build.vm && ./result
<dxb[m]>
ok lemme try that
<samueldr>
that will make the development cycle a bit quicker, depending on your x86_64 desktop perfs
<samueldr>
won't be able to do the wireless networking, but at least you can validate some parts of your initial config
<samueldr>
mainly here, username/password, maybe GUI stuff too
<dxb[m]>
yeah
<dxb[m]>
thanks
<samueldr>
I find that, outside hardware-specific issues (which for what you're doing there should be none), using the VM works really well to get 95% of the way there
<samueldr>
e.g. the plasma mobile work I did all the integration work in the VM, then built for the pinephone and it just worked
<dxb[m]>
yeah, that should make it a lot easier
<dxb[m]>
that's actually kind of how i did my very first nixos install lol
<samueldr>
it's so hard to recommend workflows to people since... I don't really know where the pain points are, I just... do things :)
<samueldr>
but it is helpful to hear about those issues
<samueldr>
and for the record, I think the install method will **not** involve writing a custom image
<samueldr>
like, the end-user installation method
<dxb[m]>
i was on arch, wanted to try nixos but had a hard time wrapping my head around it, installed it into a vm on my arch system and spent like a week playing with it and getting my nix config to match my arch config, then i installed nixos directly on my system and copied my configuration.nix that was on my vm onto my new nix system on hardware and i've been on nixos ever since lol
<samueldr>
because, as you've observerd, it's not trivial!
<samueldr>
heh, almost like that for me too, but instead of a VM, it was my previous (still useful and used) laptop
<dxb[m]>
yeah, i've been using the arch pinephone image lately and it's kinda nice that they have a few images for different graphical systems plus they have a barebones one with no graphics that you can use to build your own system. it'd be nice to have something like that for nix on the pinephone
<samueldr>
I have to think for more than just the pinephone, really, so it kinda limits me in some places
<dxb[m]>
yeah, i totally understand that
<samueldr>
but I've been thinking, and it's most likely going to be a kind of "installer" that you use on your computer, tethered via usb
<dxb[m]>
with all the work you've put into this though, at some point this could also be used as a sort of base for other people to build their own custom local.nix or whatever and build a complete os with whatever options they want to provide
<dxb[m]>
and then they can provide their own images for whatever they're building if other people want the same setup
<dxb[m]>
eyyy i got in
<samueldr>
note that the VM is not a good target to "nixos-rebuild" into, for many reasons
<samueldr>
so it's not going to be useful to really test that setup
<dxb[m]>
i fixed my wifi issue (i had accidentally set it up to connect to my 5ghz AP, but when creating the psk hash i used the 2.4ghz AP and i don't think the pinephone supports 5ghz....) and rebuilt the image and i was able to ssh into it
<dxb[m]>
i haven't tried the vm one yet
<samueldr>
right
<samueldr>
and yeah
<samueldr>
2.4Ghz
<samueldr>
hopefully your area is not overcrowded
<samueldr>
its wifi chipset does not deal too well if there's too much interference
<dxb[m]>
is there a way to turn the screen off when it's in this mode? it's just at the text login but i'm connected on ssh so i don't need the screen right now
<dxb[m]>
heh, i live in atlanta so..... yeah, it's crowded
<samueldr>
echo 0 | sudo tee /sys/class/backlight/ ... /brightness
<samueldr>
something like that
<dxb[m]>
i mean, i live in a suburb of atlanta that's not super close to the city, but even then, it's crowded around here
<samueldr>
yeah, 2.4Ghz is more about proximity
<samueldr>
I live in a flat with lots of flats around, so it's *really* crowded in 2.4Ghz interference
<samueldr>
since you also need to add other things like bluetooth, and microwave ovens into the mix :)
<dxb[m]>
lol
<dxb[m]>
i wonder what happens if you start spewing deauth packets all over the place
<dxb[m]>
probably really fucks things up cause everything will try to reconnect i assume
<samueldr>
good/bad Q :)
<dxb[m]>
nice, `echo 0 | sudo tee /sys/class/backlight/backlight/brightness` worked, thanks
mindavi has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<dxb[m]>
samueldr: should i be able to run nixos-generate-config and use the files it gives me?
<dxb[m]>
i mean i guess i should copy my local.nix over to replace the configuration.nix, but what about the hardware?
<samueldr>
good question
<dxb[m]>
lol, if you're not sure i can just try it and see
<samueldr>
don't use the generated hardware configuration, as it's being configured by default by the mobile nixos abstraction
<samueldr>
but in practice you *could* set it and it should work fine
<dxb[m]>
now that i have a solid base image to start with i think it'll take away some of the pain of building, copying, burning, booting, repeat
<samueldr>
hopefully it will
<samueldr>
though I really recommend trying the VM for maybe an even faster feedback loop
<dxb[m]>
so are you suggesting i use no hardware configuration? or should i somehow modify this?
<samueldr>
unless you're working on device-specific issues
<samueldr>
no hardware configuration
<dxb[m]>
yeah, i'll definitely try the vm thing. i have it in my notes to try it
<samueldr>
replace <mobile-nixos...> with your favourite way to make use of it
<samueldr>
that's the main "magic" that's required
<samueldr>
that will ensure all defaults required for the abstraction are set
<samueldr>
note that after a rebuild the nixos-rebuild script tells you it doesn't know how to make the configuration bootable
<samueldr>
it's totally right, it doesn't know!
<samueldr>
that's because our stage-1 cheats and peeks at generations :)
<samueldr>
you might also want to add `hardware.firmware = [ config.mobile.device.firmware ];`
<samueldr>
I don't recall if it's needed
<samueldr>
but it's in my config
<qyliss>
sad to discover upstream GNU ld doesn't support aarch64-netbsd
<samueldr>
aww (?)
<samueldr>
I don't exactly know what this means for the NetBSD effort :)
<dxb[m]>
cool, thanks. when you say to replace <mobile-nixos...> if i use it just the way you did it, do i need to add the mobile-nixos repo as a channel?
<samueldr>
dxb[m]: available through the <> resolution mechanism
<samueldr>
I never used channels, I hand-manage a NIX_PATH
<dxb[m]>
oh i guess i thought that was a channel
<samueldr>
you might want to use ./mobile-nixos/ instead
<qyliss>
samueldr: means it's difficult for me to test stuff since the only hardware I have running NetBSD is aarch64
<samueldr>
and git clone it next to configuration.nix
<dxb[m]>
ok i can do that
<samueldr>
qyliss: ah!, it supports netbsd on x86_64 I gather?
<qyliss>
yeah, the current status is that we can cross-compile to x86_64-netbsd, and static binaries will run
<qyliss>
dynamically linked ones won't, and I haven't managed to get a NetBSD linker with debugging enabled due to the aforementioned QEMU problems
<samueldr>
you really hate success if you want to cross-compile to [static, netbsd, aarch64] all at once ;)
<qyliss>
so I was hoping having actual hardware would help with that
<qyliss>
but now I can't produce binaries for it
<qyliss>
I'll try packaging NetBSD's binutils fork, I think. It uses their standard build system so might be easy.
<samueldr>
are NetBSD using another linker? patches?
<samueldr>
that answers it
<qyliss>
on BSD, everything that is part of the base system gets imported into the tree
zupo has joined #nixos-aarch64
<qyliss>
and then tends to be modified from there
<qyliss>
at the very least, the build system gets replaced with bmake
<qyliss>
they do try to upstream, but so far aarch64 netbsd in binutils is only partially upstreamed (not the ld parts)
<samueldr>
I added a pinned issue where I'll be tracking issues and PRs from upstream; if anything is missing tell me, elsewhere since I locked the issue to ensure no discussion happens there mobile-nixos#349
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mindavi>
How do I make sure that the / partition is sized to the whole emmc? The 'boot.growPartition' doesn't seem to do much...
<mindavi>
And I assume I can't resize mounted partitions
<samueldr>
Mindavi: for now, resize it manually once, haven't pulled the trigger on "fixing" the problem
<samueldr>
because ressizing *partitions* is dangerout on a lot of targets :(
<samueldr>
I kind of assume I won't ever fix it
<samueldr>
and instead deal with installing to a user-partitioned storage
<mindavi>
Using jumpdrive or how would you suggest to do it (this is the pinephone btw)
<samueldr>
jumpdrive or Mobile NixOS Target Disk Mode
<mindavi>
Yeah, letting the user partition is probably best
<samueldr>
**anyway** letting the user partition is kind of required for things like LUKS
<samueldr>
not strictly required, but much less of a headache
<samueldr>
everyone going through the same setup step would help
<mindavi>
Easy enough to manually resize indeed, that's good
<samueldr>
I don't see disk images as a viable "product" for many targets... since generally you need to encode a bit too much
<samueldr>
things like usernames
qyliss has quit [Quit: bye]
<samueldr>
or passwords even
qyliss has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
<mindavi>
Hmm, it seems like the phone doesn't boot after resizing...
<samueldr>
Mindavi: check that the third partition still has the "legacy bootable" flag
<samueldr>
it's a GPT flag
<samueldr>
use `cgpt show -v` on the block device when using either TDM or JumpDrive
<samueldr>
you can gist/pastebin the output that should give us all the good info weneed
<samueldr>
we need
<samueldr>
oh, cgpt is in vboot_reference
<dxb[m]>
i just resized on mine and it worked. but i noticed (and i've noticed this in the past too...) when you re-add the last partition, the starting block that fdisk suggests is not the same starting block that the partition was at before
<dxb[m]>
i always set it to be the same starting block as the partition i deleted
<samueldr>
I don't know why so many people use the footgun that fdisk is :)
<dxb[m]>
and i assume if you don't that you're gonna have a bad time
<dxb[m]>
lol idk... what should i use?
<samueldr>
to be fair, I don't really have a good answer
<dxb[m]>
i'm just used to fdisk because any time i google something about partitions it's what's used
<samueldr>
since probably sfdisk would have done the same thing without being careful
<dxb[m]>
error: Module `/etc/nixos/configuration.nix:anon-1' has an unsupported attribute `__please-fail'. This is caused by introducing a top-level `config' or `options' attribute. Add configuration attributes immediately on the top level instead, or move all of them (namely: __please-fail build eval pkgs) into the explicit `config' attribute.
<dxb[m]>
:/
<samueldr>
>> 20482 32 Pri GPT table
<samueldr>
and that "primary GPT table location" is what is important with a holey partition layout
<samueldr>
though I might scrap the holey partition layout and make a discrete partition for U-Boot
<samueldr>
meaning that there will be *again* a new partition scheme for the default expectation :)
<samueldr>
but since we're using partlabels it's probably not a big deal now
<samueldr>
dxb[m]: I would hazard a guess that you imported `mobile-nixos` outright (or default.nix)
<samueldr>
right?
<samueldr>
can you show the imports?
<dxb[m]>
ah yeah, you're right :)
<dxb[m]>
it had been too much time between reading your message about it and actually doing it lol
<samueldr>
ugh, the wifi chip perfs are so bad it's a battle to do anything on the device here :)
<samueldr>
but I know it's because I live in a worst case scenario for Wi-Fi
<samueldr>
so yeah, switching to a discrete partition would require importing "back" into mobile-nixos some work I did on another project, which is not really an issue
<samueldr>
and in my experience partitioning tooling is less likely to trample on the changes
<dxb[m]>
ok cool, got my first successful rebuild on the device
<mindavi>
cgpt also complains -- also, I don't know how to use it :p WARNING: One of the GPT headers/entries is invalid
<samueldr>
that warning is because the "backup" GPT is not at the end of the device I think
<samueldr>
try sfdisk, probably easier
<dxb[m]>
it looks like those --target-host and --build-host options are pretty straight forward to use but i haven't tried it yet
<dxb[m]>
Mindavi: what about fdisk?
<samueldr>
uh
<samueldr>
**cfdisk** not sfdisk
<samueldr>
duh
<samueldr>
sfdisk is the scripted fdisk
<samueldr>
fdisk is the unusable and should never be used fdisk ;)
<dxb[m]>
fdisk gave me some warning like that and said it would fix it on a write, but i didn't have any trouble with it
<dxb[m]>
lol
<samueldr>
(all three are from util-linux, and basically the same tool)
<samueldr>
fdisk has the bad text interface, cfdisk a good TUI, sfdisk is for scripting, or for imperative manipulations
<samueldr>
I basically always use --build-host on my x86_64 machines to build on my beefier machine, which also results in them picking prebuilt artifacts
<mindavi>
It boots!
<mindavi>
Thanks :) and cfdisk indeed has a good TUI
<samueldr>
fdisk has the distinction of not having a stable "API"
<samueldr>
they, in the past, changed what letters do
<samueldr>
and using letters as commands to do stuff is... pretty bad imo
<mindavi>
Oh, that's great for corrupting your disk
<samueldr>
hm?
<mindavi>
Having the letters change their meaning
<samueldr>
right
<samueldr>
in the nixos "installation guide" in the manual, which is more of an example known working setup, fdisk was used previously
<mindavi>
Yeah, at work someone used an fsdisk script
<samueldr>
and instructions topped working!
<samueldr>
stopped*
<mindavi>
I was like, what does this even mean
<samueldr>
sfdisk is the stable API for scripting
<samueldr>
and is somewhat understandable
<mindavi>
Uh oh, that's bad
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
<dxb[m]>
i didn't know sfdisk was a thing
<dxb[m]>
or cfdisk
<dxb[m]>
i'm definitely guilty of writing scripts that use fdisk
<samueldr>
:)
justanotheruser has quit [Ping timeout: 260 seconds]
<dxb[m]>
shortly before i started using nixos, i wrote this whole system that takes an archlinuxarm image for the raspberry pi and configures it to do a bunch of stuff like auto-connect to wifi, enable ssh, set a static ip, and some other stuff... like it lets you run some custom stuff on first boot and stuff and has a script to expand the partition on first boot. anywho, i used fdisk for all that stuff
<dxb[m]>
and then i installed nixos like a month or 2 later and i haven't used the arch thing since
<samueldr>
the usual story of a NixOS user :)
<dxb[m]>
lol
justanotheruser has joined #nixos-aarch64
<dxb[m]>
hrm
<dxb[m]>
samueldr: after i did my first rebuild, it won't do another because it can't find nixpkgs
<samueldr>
uuuuh... the good news is that's a "NixOS" issue
<dxb[m]>
lol
<samueldr>
I don't really know how to help you get this fixed "right"
kcalvinalvin has quit [Ping timeout: 245 seconds]
<samueldr>
but whatever method you use to get nixpkgs going on your NixOS systems should work
<dxb[m]>
hm... i might just need to do a channel update
<samueldr>
probably there's no channels configured at all
<dxb[m]>
ah that was it
<dxb[m]>
sorry :p
<samueldr>
no worries
<samueldr>
and since I don't use nix-channel at all, I'm not used to it
<samueldr>
it *is* probably breaking some expectations
<dxb[m]>
yeah
<samueldr>
I actually *never* used it really, early early on I used other hand-managed schemes
<samueldr>
I don't like how `nix-channel`'s way of managing channels doesn't allow you to update to a specific channel revision
<dxb[m]>
i think i might have actually put something in my local.nix that added the channel to stage2, and since it was just left over from before i guess i forgot about it and didn't run the update like i should have
<samueldr>
plausible
<dxb[m]>
yeah the revision thing makes sense... but i think for most people just running it as their os, they just want the latest packages available
<dxb[m]>
you can still override the channel and import something else
<samueldr>
until they need to go back after an update :)
<samueldr>
or sync machines to the same revision to reuse cache
<dxb[m]>
lol
kcalvinalvin has joined #nixos-aarch64
<dxb[m]>
so now i'm trying the remote build stuff but it's getting hung up on needing a sudo password... not sure how to enter it
<mindavi>
Well, you're getting further than I am with that :p
<samueldr>
dxb[m]: check the manual for --use-remote-sudo
<samueldr>
not sure if that'll help
<samueldr>
btw y'all pinephone using peeps, just merged a couple PRs since yesterday
<dxb[m]>
i thought i searched the manpage for sudo lol...
<dxb[m]>
guess not
<dxb[m]>
hrm, that didn't work though. it calls sudo but doesn't have a way to ask me for the password i guess
<dxb[m]>
apparently
<mindavi>
Oh
<dxb[m]>
this is for sudo
<dxb[m]>
i am
<mindavi>
Use an ssh key?
<samueldr>
I know things changed with remote builds last release, but haven't taken the time to understand the changes
<dxb[m]>
yuck
<mindavi>
That's what the manual says about it
<mindavi>
But I'm not getting it to work either, so ymmv
<mindavi>
Warning: If you are building via the Nix daemon, it is the Nix daemon user account (that is, root) that should have SSH access to the remote machine. If you can’t or don’t want to configure root to be able to access to remote machine, you can use a private Nix store instead by passing e.g. --store ~/my-nix.
<dxb[m]>
i guess i can initiate it from the pi instead of from the phone
<dxb[m]>
and then i think i have to run it again on the phone after that maybe? like then the packages will be cached and copied over
<samueldr>
I personally use `nix-copy-closure` and `nix-instantiate` trickery
<samueldr>
but that's because I haven't taken the time to understand how to make the --build-target thing work :)
<samueldr>
(or --target-host ?)
<dxb[m]>
it's both...
<dxb[m]>
one specifies where the packages should be built, the other specifies where the packages should end up
<samueldr>
I know
<samueldr>
zhaofeng zhaofeng_alt: if you want to, or else I'll end up doing it, you can use mobile-nixos#351 as a starting point for a demo phosh system
<colemickens>
also "flake tooling" is a confusing phrase that points to some potential confusion -- a flake expression simple dereferences to a nix derivation that gets built the same way a regular derivation is built when using nix-build.
<matthewcroughan>
colemickens: well if I try and run `nix build` with my inputs.nixpkgs being 68aad7348a0eb90571daa9dd60f1aca6be962455, it complains about no flake.nix being at the root
<matthewcroughan>
so I can't use it with the 'flake tooling", i.e the latest nix
<matthewcroughan>
that's nixpkgs from like 3 years ago
<colemickens>
not to be rude, but I'd recommend using the flake input I'm using rather than trusting that comment