<samueldr> I totally respect (as in allow to exist) the decision to not provide the source of the operating system, and not to make it easy
<samueldr> but at least _possible_
<samueldr> the chromeos hardware is (still) a good example of a good implementation
<samueldr> they have a component one rung down from the firmware which orchestrate all this
<heywoodlh> Yeah, I completely agree. Especially because Apple hardware typically outlives its support lifespan.
<samueldr> which allows you to not only replace the boot firmware
<samueldr> but if you brick the boot firmware you can recover!
<samueldr> which is why you see standard UEFI Tianocore on intel chromebooks
<samueldr> additionally the chromeos team always contributes back to mainline projects
<heywoodlh> I worked at a school district before and they had thousands of perfectly good generation one iPads that were absolutely useless despite the hardware being great.
<heywoodlh> Yeah, I really like Chromebooks!
<samueldr> :<
<heywoodlh> My first Arch laptop was a crappy Acer Chromebook. I loved it so much.
<samueldr> I've read the horror story of iPads used as POS, where an iOS upgrade left the POS app unable to start (dropping 32 bit support IIRC)
<samueldr> and they had no way to revert to the previous iOS release at that time IIRC
<samueldr> imagine how business-crushing that must be
<heywoodlh> Yeah, absolutely.
<heywoodlh> And they're a bit merciless with their attitudes.
<heywoodlh> At the same time, when you contrast to Microsoft being backwards-compatible forever I can understand the logic.
<heywoodlh> Microsoft making Windows work with everything really makes it easy to hammer on Active Directory because it's so hard to lock down.
<heywoodlh> Which, that can be business-crushing too.
jumper149 has quit [Quit: WeeChat 2.9]
CyberManifest has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
h0m1 has quit [Ping timeout: 240 seconds]
h0m1 has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
CyberManifest has quit [Quit: Leaving...]
justanotheruser has quit [Ping timeout: 244 seconds]
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
superherointj has quit [Quit: Leaving]
<veleiro> well guess i have to fix my pinebook pro case so i can build mobile-nixos
juliosue1ras has joined #nixos-aarch64
juliosueiras has quit [Read error: Connection reset by peer]
juliosue1ras has quit [Read error: Connection reset by peer]
juliosueiras has joined #nixos-aarch64
<veleiro> anbox sucks
<veleiro> very snap based
<veleiro> the incompetence that nix has to deal with.. i tell you
orivej has joined #nixos-aarch64
<Ke> android is a huge project, it's not trivial to do anythign reasonable with it
<veleiro> exactly
<veleiro> its almost a joke to compile it from source to get around the google SDK
<veleiro> the license agreement i mean
<{^_^}> #75603 (by primeos, 39 weeks ago, open): Build Android tools from source (adb, SDK, Android Studio, etc.)
juliosueiras has quit [Remote host closed the connection]
kahiru has quit [Ping timeout: 240 seconds]
kahiru has joined #nixos-aarch64
alp has joined #nixos-aarch64
<leonardp> does anyone have a unifi controller running on a raspberrypi or similar? i am getting a lot of `Process 4225 (mongod) of user 183 dumped core.`
<Jake[m]> I actually do! You need to use a different version of mongodb
<Jake[m]> Gimme a sec
<{^_^}> #75133 (by alexvorobiev, 40 weeks ago, open): nixos/unifi controller: mongod crashes immediately (Raspberry Pi; aarch64)
<leonardp> wow thanks
<leonardp> i'll try that!
<Jake[m]> I was running 20.03 so I used an overlay to use mongodb from unstable, but now I'm using 20.09 and it got fixed by then.
<Jake[m]> One other tip: `networking.firewall.allowedTCPPorts = [ 8443 ];` so that you can access the GUI.
<leonardp> thanks for the pointers
<leonardp> good to know it's fixed
<leonardp> i am still mad i have to use their controller to manage a single device... when i bought it it was working in standalone mode...
<Jake[m]> Yeah tbh I bought it without fully understanding it, so I thought it was my fault when I realized I needed another device to configure it.
<Jake[m]> What's this standalone mode though?
<leonardp> well, i have a NanoHD wifi acces point. it basically just gets an address via dhcp and that's it
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<leonardp> there's not much to configure
<leonardp> and when i bought it i could just set the address to dhcp and leave it alone
<leonardp> which is how it's running right now
<Jake[m]> What about setting the wifi ssid and password?
<leonardp> yeah, also that :)
<leonardp> and firmware upgrades
<leonardp> 3 functions... and after the fw update i could no longer acces it with their app
<leonardp> on the other hand i guess their hardware is probably meant to be used in masses so i kinda get where they are conming from
<Jake[m]> Gotcha, so you do need the controller to configure it, but it'll hum along by itself without it.
<leonardp> exactly
<Jake[m]> Yeah, that's what I figured. And I had the Pi around anyway, and the controller was packaged up so nice already by NixOS I really couldn't even be mad.
<leonardp> i stil have another raspberrypi running raspbian with "pi-hole"
<leonardp> now i want to nixify it and the controller is a super nice bonus
<Jake[m]> I'm also working on pi hole nixos! I have something that works right now, but it's only okay. Let me know if you get it working nice.
<leonardp> actually i only need/want dnsmasq+hosts file. although the pi-hole gui is super nice i found myself rarely using it
<Jake[m]> I will say one gotcha I encountered: if you reboot by unplugging and the time gets messed up AND you are using the Pi as it's own DNS resolver, it won't be able to resolve the URL of the NTP server b/c the time is wrong, and it won't be able to correct the time, so it pays to have a NTP server configured that is a static IP.
<Jake[m]> Yeah that's what I'm going for too, even though the GUI is nice.
<Jake[m]> I'm using unbound, I forget why and I'm not even thrilled with it.
<leonardp> isn't there something like a fake-hwclock package around?
<Jake[m]> Not saying it's bad just saying I need to look into it.
<Jake[m]> What's fake-hwclock?
<leonardp> i think it just writes the time down into a textfile and after booting reads that file
<leonardp> so your time won't be off by too much if you reboot
<Jake[m]> and that works even if you unplug it?
<Jake[m]> this could change everything
<leonardp> might be worth a try
<Jake[m]> right I was thinking about that too
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 265 seconds]
cole-h has quit [Quit: Goodbye]
LnL- is now known as LnL
orivej has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
<colemickens> oh hey, my nvme and serial adapters showed up, almost two weeks after usps claimed they were delivered
<colemickens> lol
<colemickens> they say state is hard
<colemickens> I can't tell if I'm tired or what. mount says the nvme is mounted for / even though it was used in an x86 machine last
<colemickens> and the boot process says it actually mounted the emmc to / as I would've expected (and given the contents I'm seeing) yet mount insists the nvme is active on / and /nix/store ?
<colemickens> I suspect maybe has to do with mounting by partlabel and having overlapping partlabels across the two drives
t184256 has joined #nixos-aarch64
<colemickens> "umount /dev/nvme0n1p2" -> target is busy. Um, target is a zfs pool and I don't even have zfs loaded?
smrtak[m] has joined #nixos-aarch64
alp_ has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
<colemickens> that pinephone blog update makes me thirsty for curst
<colemickens> crust even
orivej has joined #nixos-aarch64
<colemickens> UART output is enabled by flipping the UART switch to the ON position (item 9).
<colemickens> great that I know what item 9 is
orivej has quit [Ping timeout: 240 seconds]
alp_ has quit [Ping timeout: 272 seconds]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 256 seconds]
alp_ has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<colemickens> Weird. I can't get stage-2 to see the NVME, even though it works if I boot from emmc?
<colemickens> I put nvme in boot.initrd.kernelModules
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
<colemickens> somehow having the serial output makes me feel 100x more competent though :P
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<leonardp> what is the proper way of appending/editing stuff in config.txt on the raspberrypi3?
<leonardp> i might be blind.... found it boot.loader.raspberryPi.firmwareConfig
<kyren> leonardp: this took me a long time to figure out, but it depends on whether you're using uboot or not, probably if you followed recent instructions you're using uboot and boot.loader.raspberryPi.firmwareConfig isn't going to do anything :(
<kyren> I think the module that controls config.txt is being rewritten for the uboot changes, OR if you want to you can stop using uboot but it requires a large boot partition to hold the kernel images, which might be annoying if you don't have that
<leonardp> yep... doesn't seem to do anything...
<leonardp> i can make it work when building sd-images
<{^_^}> #67902 (by lopsided98, 1 year ago, open): raspberrypi-bootloader: support new firmware partition concept
<kyren> it's a bit of a mess, I also found that linuxPackages_rpi3 doesn't really boot properly with uboot, so if you need that then you should stick with... I guess it's direct booting, I dunno what to call it
<kyren> if you can make your own sd image then maybe you can modify the configuration for the pi4, which currently doesn't use uboot?
<kyren> that's what I tried until I ran into cross compiling issues, then gave up and just upgraded from a 19.03 image that had a better partition size, really the only thing in the way of switching is that the /boot partition needs to be 128M or larger
<leonardp> hmmm... great to see that someone is working on these issues
<leonardp> i might try switching back to the raspberrypi's native bootloader
<leonardp> although i quite like uboot
<kyren> yeah uboot is just better, directly booting the kernel from the firmware is the worst
<leonardp> wow... accidentally disabled ssh with nixops deploy
<leonardp> gues i just found a new way to lock myself out of a raspberrypi
<kyren> oh nooooo :(
<kyren> yeah it's the worst when that happens
justanotheruser has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<Jake[m]> So relatable 😅
veleiro has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 260 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has joined #nixos-aarch64
veleiro has joined #nixos-aarch64
<veleiro> does the pinephone-braveheart for mobile-nixos work for the newer pinephones?
zupo has joined #nixos-aarch64
<samueldr> it might need adjustments to u-boot for the 3GB variant, veleiro
<samueldr> well, probably most certainly does
<samueldr> cole//mickens shared a link in the last few weeks about that
<veleiro> ah, that's probably what it is
<veleiro> Code: "Synchronous Abort" handler, esr 0x96000000
<samueldr> ugh, u-boot's patchwork seems to take an eternity to respond
<samueldr> IIRC it's a simple one-patcher change with relatively few changes
<Thra11> patchwork's not responding at all for me
<samueldr> same
<samueldr> "eternity to respond" was because I was too impatient to wait for the actual time out before replying :)
<samueldr> pretty sure it is
<samueldr> like, I used that exact repo to find the subject :)
<samueldr> so we either rebase on the newer version of the crust branch
<samueldr> neat, we can drop one of my patches
<samueldr> the LEDs one
<samueldr> if we rebase on top of that we could also implement the "real" recovery during boot
<samueldr> well, I was going to at some point with the exact patch they included
<veleiro> colemickens: have a link? :)
<samueldr> veleiro: it's what we linked basically
justanotheruser has quit [Ping timeout: 244 seconds]
<samueldr> if you update the u-boot commit to the latest of that branch, it should work
jumper149 has joined #nixos-aarch64
<samueldr> you may need to remove a patch about LEDs
<veleiro> ahhh
<veleiro> sorry missed that
<samueldr> n/p, especially if you were reading in chronological order :)
alp_ has quit [Ping timeout: 272 seconds]
cole-h_ has joined #nixos-aarch64
<heywoodlh> samueldr: running into this error when I try to build from my repo or yours for razer-cheryl error 'struct mdss_dsi_ctrl_pdata' has no member named 'refresh_rate_cfg'
<heywoodlh> (If you are sick of me please feel free to ignore, sorry this isn't working yet :)
cole-h has quit [Ping timeout: 258 seconds]
<veleiro> i suppose you mean here
<samueldr> in a meeting for a while
kahiru has quit [Ping timeout: 265 seconds]
kahiru has joined #nixos-aarch64
LnL has quit [Quit: exit 1]
alp_ has joined #nixos-aarch64
<Thra11> (Though I may be wrong)
orivej has quit [Ping timeout: 272 seconds]
stiell has quit [Ping timeout: 260 seconds]
alp_ has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
stiell has joined #nixos-aarch64
<veleiro> thanks
cole-h_ is now known as cole-h
zupo has joined #nixos-aarch64
<samueldr> hm, I had forgotten I had a custom patch with only partial commits
<Thra11> It looked like that was mostly cherry-picking commits from the pine64 crust branch, so having switched to said branch, I dropped the patch.
<Thra11> It built ok. Still waiting for it to transfer the disk image from the build server, so haven't tested yet
<Thra11> I wish there was a way to tell nix that transferring large files to a build server only to dd them into an image and transfer it back is not efficient.
<Thra11> Maybe there is. I don't know.
<samueldr> yeah, it was the branch without the orangepi and other A64 boards stuff
<samueldr> Thra11: preferLocalBuild
<samueldr> though not sure what the _actual_ semantics are
<Thra11> Yeah. I thought I'd seen something like that around somewhere.
<samueldr> so whatever way, if it's confirmed to work for you, veleiro, we can go forward from there
<Thra11> samueldr: "Uncaught Exception" <unhappy phone icon> "Command not found... `systemd-udevd --daemon` (127)(System::CommandNotFound)"
<Thra11> Then reboots after 10 seconds
<samueldr> Thra11: good news, the kernel boots
<samueldr> Thra11: and init works!
<samueldr> and the display works!
<Thra11> :)
<samueldr> and even the "everything's wrong" display works!
<Thra11> I have serial output if it's helpful
<samueldr> might be
<samueldr> but that's... concerning
<samueldr> that should be part of the initramfs
<samueldr> unless
<samueldr> oh no
<samueldr> there were recent changes weren't there with systemd to split udev off?
<samueldr> or am I imagining things?
<{^_^}> #97051 (by vcunat, 1 week ago, open): systemd: build libudev.so "separately"
LnL has joined #nixos-aarch64
<samueldr> the "--daemon:" prefix is weird
<samueldr> Thra11: nixpkgs commit used
<samueldr> I'm gonna try it on qemu to see
<samueldr> I'm assuming master for Mobile NixOS, with a pinephone patch
<Thra11> samueldr: master for mobile nixos, nixpkgs at 4b7401bb5b32d20f7f94e3a61daec9b12d700f32 (not strictly true, I'm actually on my plasma-mobile packaging branch, but it's just plasma changes and new packages on top of that commit)
<samueldr> it should be alright too
<samueldr> I mean, without your plasma phone changes
<samueldr> that's way before anything NixOS happens
<Thra11> "--daemon: line 1: systemd-udevd: not found" is a very weird message
<heywoodlh> samueldr: any suggestions on the error I got on building: "mdss_dsi_ctrl_pdata' has no member named 'refresh_rate_cfg'"
<samueldr> heywoodlh: diff your branch's config against mine, since mine built
Darkmatter66 has quit [Ping timeout: 264 seconds]
<samueldr> I would hazard a guess about framebuffer config idiffs
<samueldr> diffs*
<samueldr> Thra11: good news
<samueldr> D, [2020-09-16T20:21:27.020095 #1] DEBUG -- : $ systemd-udevd --daemon
<samueldr> --daemon: line 1: systemd-udevd: not found
<samueldr> that's with qemu
<samueldr> so it's not you
<samueldr> I'll try on top of the latest unstable that built for mobile nixos
<samueldr> I should get a qemu test going I guess
<samueldr> on top of e0759a49733dfc3aa225b8a7423c00da6e1ecb67 too
<heywoodlh> samueldr: I tried building against yours too and it failed. But I did have a discrepency in my config vs yours so I'm gonna try it again because maybe something I did was off.
<samueldr> it's not a config thing I think
<samueldr> a config-free checkout with qemu fails
<samueldr> *something* in nixpkgs changed
<samueldr> and since there is no vm tests (yet) it hasn't been caught
<heywoodlh> Oh you were talking about my issue with your above comments?
<samueldr> oh shoot
<samueldr> sorry
<samueldr> mixed up people
<heywoodlh> Lol okay, no worries.
<samueldr> or more to the point, forgot there were two issues
<samueldr> heywoodlh: yes, check if the difference does it
<samueldr> mdss_dsi is the driver used to drive (heh) the display
<samueldr> if you enable the "old style" framebuffer on a device that isn't using it might do that
<samueldr> I *think* I had something similar on cheryl2
<samueldr> and I would give it a 50/50 chance cheryl1 also could because of *reasons*
<samueldr> long story short, it might be using DRM (the good kernel kind) for android, and if it does you might be enabling untested code path
<samueldr> because that rings a bell
<samueldr> Thra11: c59ea8b8a0e7f927e7291c14ea6cd1bd3a16ff38..a31736120c5de6e632f5a0ba1ed34e53fc1c1b00
<samueldr> between all that
<samueldr> you know the drought we just had :)
<Thra11> samueldr: Is that known working commit to known broken commit?
<samueldr> yes
<samueldr> tested using time nix-build examples/hello --argstr device qemu-x86_64 -A build.default && ./result
<samueldr> (and NIX_PATH pointing to the right nixpkgs)
<Thra11> samueldr: Does 7361f6f25266e8bc104f9bafaec860e67ea45c65 look suspicious to you?
<samueldr> we do our own copy_bin_and_libs
<samueldr> so yes
* samueldr wonders why it doesn't fail to build
<samueldr> oh, what if it copies a dangling symlink?
<samueldr> Thra11: do you think you can try applying the same change in Mobile NixOS or would you be lost?
Darkmatter66 has joined #nixos-aarch64
<Thra11> samueldr: Changing modules/initrd.nix, yes?
<samueldr> yeah
<samueldr> if it ends up working that's a good PR that's sure to get merge
<samueldr> merged*
<Thra11> I can certainly try :)
<samueldr> great
<samueldr> I've been busy not working on Mobile NixOS these last few days/weeks
<Thra11> That tiny change to initrd.nix appears to be causing it to rebuild the kernel.
<Thra11> Is the initrd built into the kernel in some way?
<samueldr> no
<samueldr> that's weird
<heywoodlh> samueldr: just tried the build using your Git repo and it failed
<heywoodlh> (the build for razer-cheryl)
<heywoodlh> error: 'struct mdss_dsi_ctrl_pdata' has no member named 'refresh_rate_cfg'
* samueldr checks
bennofs has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 240 seconds]
<heywoodlh> samueldr: any luck?
<samueldr> had to cancel the build, since I'm not on the same commit of nixpkgs I was it was rebuilding the world and I had to use the machine, sorry
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<heywoodlh> Ah, no worries
<Thra11> samueldr: Now boots to splash/login prompt
<samueldr> Thra11: great
<Thra11> Can't seem to login though. Is nixos/nixos, root/nixos the right usernames/passwords?
<samueldr> depends on what you built and what the config is
<samueldr> like nixos, there is no default really
<samueldr> there is examples/demo which has a password set
<samueldr> but otherwise there is nothing
<samueldr> since it would be kind of awkward if it overwrote your personal config with a nixos user and some dumb root password!
<Thra11> I ran `nix-build --argstr device pine64-pinephone-braveheart -A build.disk-image` in the root of mobile-nixos
<samueldr> yeah, no user settings
<samueldr> I'm not sure how users will set themselves up in the end
<samueldr> so I have made no decision on that problem
<samueldr> you can add a local.nix at the root to configure things
<samueldr> the usual configs apply
<samueldr> yes, I figure that's annoying, but that's an open question: "onboarding"
<samueldr> (1) how should users install?
<samueldr> build an image themselves with the settings they want? start from an sd-image like pre-installed setup? iso-like where you are in an ephemeral system?
<samueldr> so since I don't know, I didn't try to answer :)
<samueldr> (2) for an on-device install flow... how do you deal with the configuration? writing up your config in vim on an onscreen keyboard seems.. masochist!
justanotheruser has joined #nixos-aarch64
<Thra11> Yes, definitely interesting questions. I'll write myself a local.nix for now.
<samueldr> you'll find some places there are losse thread ends like that
<samueldr> where I don't have an answer, so it's left hanging for a revelation
<samueldr> or at least until it's really needed
<Thra11> Yeah. Makes sense.
<colemickens> I am trying to pull the modules from mobile-nixos into what looks like a regular nixos build ATM, I'm not sure its the right tact
<samueldr> yeah, that's not flakeful
<samueldr> left as an exercise to the reader
* colemickens has been exercising...
<veleiro> i tested it and it works
<veleiro> i'm trying to figure out the next steps
<veleiro> should mobile.hardware.ram = 1024 * 3; as well?
<samueldr> it's the lowest amount available on the model
<samueldr> it's currently totally unused
<samueldr> this is something I intend to use at some point in the future to provide sane defaults or warnings
<veleiro> ah
<veleiro> i just read the chat about user settings above
<veleiro> I'm eager to find a good solution
<samueldr> once you're set up somehow it's not an issue, it's really getting a foothold that's problematic
<samueldr> and well, nuts to default passwords, they're a scourge and NixOS (the distro) has none, so why should Mobile NixOS have some?
<samueldr> (disregard the virtualbox VM which makes a liar out of me)
<colemickens> (it's a bit aggressive about it actually https://github.com/NixOS/nixpkgs/issues/95778)
<{^_^}> #95778 (by colemickens, 4 weeks ago, open): mutableUsers=false and root.hashedPassword is set, yet nixos-install prompts for password:
heywoodlh has quit [Quit: WeeChat 2.9]
<Thra11> I'm now logged in as me! local.nix is actually quite a nice way to do it (preparing the device config beforehand on your computer is actually really neat, especially when you have an existing configuration.nix to steal snippets from)
<samueldr> though building on your computer is not always trivial for everyone :)
<samueldr> and not possible for some software! (cross-compilation)
<samueldr> though configuring with local.nix is likely to stick around
<samueldr> even if there is an "installer"
<Thra11> yeah. it would be nice to have some way to take a prebuilt image and supply your own initial configuration.nix
<samueldr> I had someone message me literally yesterday about installer stuff, I have yet to re-read the message and reply
<samueldr> basically ollieparanoid from postmarketOS wants to take a look see if his work (under NLnet too!) on an installer can apply for Mobile NixOS
heywoodlh has joined #nixos-aarch64
heywoodlh has quit [Client Quit]
<Thra11> Well. I'm going to call this a great success and go to bed! Good Night!
tilpner has quit [Ping timeout: 258 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 244 seconds]
tilpner has joined #nixos-aarch64
<colemickens> apologies for the reddit link
<gchristensen> neat!
<samueldr> all built from the "decompilation" project
<samueldr> it's amazing what a little bit of source code can do
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 258 seconds]
hexa- has quit [Quit: WeeChat 2.7.1]