zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bennofs_ has joined #nixos-aarch64
bennofs__ has quit [Ping timeout: 264 seconds]
lopsided98 has quit [Quit: Disconnected]
<artturin> samueldr: the problem with the usb dock and other things seems to be that no modules are getting loaded
<artturin> theres no /run/current-system/kernel-modules/?
<samueldr> maybe it's not a problem if the modules are built-in
<samueldr> it _shouldn't_ be a problem
<artturin> i compiled the anx7688 module as a module
<samueldr> since the modules should be built-in
<samueldr> ah
<samueldr> that's a big issue with the way stage-1 is currently architected
<artturin> CONFIG_TYPEC_ANX7688=m
<samueldr> getting the modules for stage-1's kernel, which is not controlled, is not going to work nicely
<samueldr> how does stage-2, _the way it's currently being made_, when generic, knows which modules to get?
<samueldr> though, set it as =y and it should work better
<samueldr> unless the module makes bad assumptions that it will be loaded as a module later on
lopsided98 has joined #nixos-aarch64
<artturin> here's a list of lsmod which i took from mobian https://paste.ee/p/yUzcE
<samueldr> you might want to compare with this
<lopsided98> The armv7l kernel has grown too big and started overwriting the device tree on the RPi 2 (and I assume other 32-bit RPis)
<samueldr> with u-boot?
<samueldr> well, we know how to solve that :)
<samueldr> it might already be solved if you haven't updated / built a fresh u-boot
<lopsided98> oh right, I commented on that PR lol. It doesn't look like the patch was submitted upstream though...
<samueldr> indeed, pbb_: can we do anything to help you upstream the fix?
<samueldr> I searched quickly on their patchwork instance and indeed couldn't find it
<lopsided98> This is actually the first time I've been able to get my config for this machine to build since september, due to the general state of decay of armv7l NixOS
<samueldr> yeah, I've been putting a bit of work these past few days to be in a situation where it is easier to test for me
<samueldr> soon I'll have a "canary" to check whether armv7l builds are expected to work
<samueldr> it uses qemu-user (but not binfmt!) to exec binaries
<artturin> -CONFIG_RTL8723BS=y
<artturin> +CONFIG_RTL8723BS=m
<artturin> why
<lopsided98> yeah, it would be great to have more testing. There's a bunch of issues right now; I have made or soon will be making PRs to fix most of them
<samueldr> artturin: it's forced by the kernel config
<samueldr> artturin: the module is loaded in stage-1
<samueldr> lopsided98 <3
<lopsided98> I'm not sure sure what to do about that binutils patch though. My first response would just be revert it because it breaks a whole platform just to fix the rather obscure combo of GHC+musl+ARM, but I don't know if others will like that.
<samueldr> disable it for armv7l if it's what it breaks for?
<samueldr> not ideal to not apply the same patches everywhere
<samueldr> but better than breaking the whole platform?
<samueldr> (I don't know which patch this is referring to)
<{^_^}> #107386 (by Gaelan, 9 weeks ago, open): Can't build linux-headers on armv6l
<lopsided98> This is the commit that adds the broken patch: https://github.com/NixOS/nixpkgs/commit/b3640e024f01453b3c4f720135dc6cff529da8ab
<lopsided98> A workaround might be to only apply it when hostPlatform != targetPlatform
<artturin> nice, kitty launches on nixos mobile but not on mobian :)
<samueldr> artturin: other way around, mobile nixos ;)
<samueldr> lopsided98: or maybe only when musl is involved?
<lopsided98> yeah that's probably better
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
<artturin> samueldr: i built it in and now the dock works
<artturin> logitech k400+ kb and mouse combo too
<artturin> + is part of the model name
<samueldr> cool
<artturin> also found some other options
<samueldr> I'm sure there's lots other
<samueldr> (and thank you for looking and working on it)
<artturin> i'll try copying the mobian config and changing all the =m to =y's
<samueldr> that's an option
<samueldr> ideally try to understand why things are enabled
<samueldr> (why they're disabled here is most likely: because they weren't enabled)
orivej has quit [Ping timeout: 265 seconds]
ky0ko has quit [Remote host closed the connection]
cole-h has quit [Ping timeout: 265 seconds]
adamzivcak1 has joined #nixos-aarch64
alpernebbi has joined #nixos-aarch64
adamzivcak1 has left #nixos-aarch64 [#nixos-aarch64]
<Jassuko[m]> Okay. So, I'm trying to get the nixos to boot into the correct nix init on rpi4 from using the pre-built rpi4 image as a starting point. It seems that the init or kernel related things are not properly updated when running `nixos-rebuild switch`, so the boot always just falls back to the default state of the pre-built sd-image.
<Jassuko[m]> Any clues how to actually achieve useable system from the pre-built image? If there is fancy configuration neeeded, it really should be included in the sd-image, which is not the case now.
<Jassuko[m]> I'm now in a state, where I have useable system with services by booting & running nixos-rebuild after the boot..
<Jassuko[m]> The sd image I used was the latest built marked as successful of the 20.09 set of images.
<patagonicus> Maybe a stupid question, but those the original image mount the boot partition correctly? Maybe nixos-rebuild updates some stuff on your / partition, but the bootloader is looking at a different one. (I've only tried NixOS on a RPi3, never on a RPi4, but I don't remember much trouble with that)
<Jassuko[m]> Yeah, I have separate /boot, so to have the installer behave I must mount the /boot first before running the nixos-rebuild.
<Jassuko[m]> Because it sounds like it should be relevant for building the installer... but the documentation is very vague regarding stuff like that.
<patagonicus> You can just check what it does: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/sd-card/sd-image-raspberrypi4.nix Looks useful, but it doesn't do too much. The import of the aarch64 one is more interesting, it sets up the bootloader stuff.
Darkmatter66 has quit [Read error: Connection reset by peer]
<Jassuko[m]> Yeah. And according to the generic aarch64 wiki page the /boot should not be used anymore. But I guess rpi4 bootloader needs some stuff there regardless?
Darkmatter66 has joined #nixos-aarch64
<Jassuko[m]> So there must be a vfat partition with at least some text files or something. 🤔
<Jassuko[m]> What I don't really get with nixos is that why there is no working configuration.nix included that would contain everything needed to continue using the system after the "first boot" of the sd-image.
<Jassuko[m]> Now it's like a puzzle game to get everything working even to the point of the provided sd-image. It's just weird
<patagonicus> If I read it correctly /boot is part of /, but there's a /boot/firmware filesystem which contains the RPi specific stuff. Which should then load the bootloader (extlinux, I think) and that one should read the config from /boot
ky0ko has joined #nixos-aarch64
<patagonicus> And the minimal config on https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi_4 also doesn't work?
<Jassuko[m]> Nope. At least not from the latest 20.09 image I found.
<Jassuko[m]> Maybe I should've used some newer image, but there was mostly image builds marked as failed on 21.05 set...
<patagonicus> There's probably a /boot/extlinux/extlinux.conf - does that one get updated on rebuild?
<Jassuko[m]> yes, but it doesn't seem to affect on anything
<Jassuko[m]> there is /boot/cmdline.txt that contains reference to the original nix environment the sd-image had... that might be relevant.
<Jassuko[m]> But does that minimal example configuration ever update those bootloader / firmware things either? Or does it just use the things that were put in place on the original sd-image?
<patagonicus> Ah, good point, I checked the configs at master, not at 20.09. Maybe back then it wasn't using the stub loader.
<patagonicus> The firmware doesn't need to be changed and it does update the extlinux config. AFAICT at master it's using a stub to go into extlinux, but I'm not sure if it did that in 20.09. But I'd expect so.
<Jassuko[m]> Yeah. I might as well just select a newer image... but it's also a problem with documentation that there was nothing said about which image should selected from the list of thousands of built images... :D
<Jassuko[m]> But I have to run for a while.. I'll try to make some sense of this all a bit later. :P
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
orivej has joined #nixos-aarch64
<Jassuko[m]> Yeah, so, with the 20.09 image and the config I wrote it was actually the cmdline.txt that caused the default nix environment to be the init.
<Jassuko[m]> patagonicus: Do you have idea if the failed builds are totally bad, or are there generally just some random non important packages or such that fail to build properly?
awmv has quit [Quit: Connection closed for inactivity]
<patagonicus> Jassuko[m]: it just means that something that's needed for the installation image is broken. That could be something really important like the kernel or something unimportant like some documentation. But it is something that is included in the image by default.
<patagonicus> https://hydra.nixos.org/build/134720986 There's a build from January, that's not that old.
<patagonicus> Oh, actually. The breakage is the change that modules declared in the configuration need to be built. Before that change it just ignored missing modules. I think that has been breaking many non-amd64 builds.
<Jassuko[m]> Yeah. Found out the same.
<{^_^}> #111683 (by markuskowa, 3 weeks ago, open): Raspberry Pi 4 SD card image broken on master
<Jassuko[m]> "We'd need to be able to filter out a module from the list, which AFAIK for lists is impossible with NixOS modules."
<patagonicus> You could probably built the image yourself without too much hassle if you have enough space on your MicroSD card. You'd basically just need to lib.mkForce the list of modules with what it currently is minus the modules that are not built anyway.
<patagonicus> Alternatively you can check out nixpkgs and change a boolean to allow the missing modules again, that's what I'm currently doing on my armv7 machines since I was too lazy to prune the list of modules.
<Jassuko[m]> Yeah, the SD card is 128 GB, so should be plenty of space.
<patagonicus> Oh, yeah. You'll probably want a few gigs of swap as well. But then I think you can put http://sprunge.us/wozgf5 in `sdimage.nix` and then build the image with nix-build -I nixos-config=./sdimage.nix -A config.system.build.sdImage
<patagonicus> Only question is what to put in the list of kernel modules. :D
<Jassuko[m]> well, everything but `sun4i_drm` I guess... and then iterate over until it finally builds? ;P
<Jassuko[m]> Do you think 8 GB of RAM is not enough for the build?
<patagonicus> Possibly, I don't think it should do much actual building, basically just grab everything for the system, build the initramfs locally and then put everything into the image. That needs some copying on disk + compression, but it shouldn't be RAM heavy.
<patagonicus> The question is what "everything" is. :) http://sprunge.us/MWwITT is all I could find looking through the configs, but maybe I'm missing something. I'd start with that, remove all the sun.* modules and then see if it works.
<Jassuko[m]> Uh, so it doesn't know how to fetch config imports from the repo?
monk has left #nixos-aarch64 ["Error from remote client"]
srk has quit [Remote host closed the connection]
srk has joined #nixos-aarch64
sphalerite has quit [Quit: updates!]
sphalerite has joined #nixos-aarch64
<patagonicus> I wasn't testing the config, but it should work. Maybe try nixos instead of nixpkgs? (You do have one or the other as a channel on the RPi, right?)
Darkmatter66 has quit [Ping timeout: 276 seconds]
<Jassuko[m]> Sorry, I don't understand the overall structure of the whole nix stuff well enough to really deduct how things should work at that level. BUT, it seems that the rpi bootloader will find the vfat partition and read config.txt and cmdline.txt from there and work based on them. I think I can derive a working configuration based on how debian etc handle those things.
<Jassuko[m]> cmdline.txt only has this on debian: `console=serial0,115200 console=tty1 root=PARTUUID=68c4b6cd-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait`
<Jassuko[m]> And config.txt does _not_ point to the kernel & initramfs files.
<patagonicus> config.txt should point to some bit that then loads extlinux. And nixos-rebuild will update the config for extlinux. But, yeah, as a workaround you can manually update the cmdline.txt, that will probably work.
<patagonicus> Although then I'm wondering where the kernel and initramfs come from. Because cmdline.txt will only change what happens after the initramfs
<Jassuko[m]> Can you paste what's in your cmdline.txt and config.txt?
<Jassuko[m]> Because my cmdline.txt doesn't get updated, and originally only pointed to the default nix environment the sd-card had...
<Jassuko[m]> I'd like to get it working properly... in a way or another, so that the boot stuff would update as it should.
<patagonicus> I don't have NixOS on any RPi currently
<patagonicus> I have a RPi3 somewhere in a drawer.
Thra11 has joined #nixos-aarch64
<Jassuko[m]> I just don't get how the current overall nix build config thing for rpi4 could produce a working environment. Other than one-time when building the SD card image.
<Jassuko[m]> Only reference I can find is to update kernel things to /boot partition... and by default that is not used as a separate partition anymore. While the cmdline.txt is still built assuming it would be...
<patagonicus> Maybe try the January build?
<Jassuko[m]> Yeah.. it seems very different actually.
<Jassuko[m]> Ok, I'll just grab my config and roll over to that img
<Jassuko[m]> I think it has moved to u-boot actually... apparently by chainloading the bootloader by just asking the rpi internal bootloader to kick in u-boot-rpi4.bin file.
<Jassuko[m]> Now some of the stuff in the master repo seems to make at least some sense. ;D
Thra11 has quit [Quit: WeeChat 3.0.1]
evils has quit [Ping timeout: 276 seconds]
simpson has quit [*.net *.split]
luigy has quit [*.net *.split]
luigy has joined #nixos-aarch64
simpson has joined #nixos-aarch64
orivej has quit [Ping timeout: 245 seconds]
monk has joined #nixos-aarch64
awmv has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
jumper149 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
cole-h has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
jumper149 has quit [Quit: WeeChat 3.0.1]
julm has joined #nixos-aarch64
<patagonicus> :/ rustc now depends on llvm 11.1.0, which doesn't build on armv7. And rustc is a transitive dependency of borg, which is basically the main reason I even want to run this system.
zupo has quit [Quit: Textual IRC Client: www.textualapp.com]
<s1341_> how do i install missing rustc standard libraries?
rajivr has quit [Quit: Connection closed for inactivity]
zupo has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
ib07 has joined #nixos-aarch64
dev_mohe has quit [Remote host closed the connection]
Darkmatter66 has joined #nixos-aarch64
alpernebbi has quit [Quit: alpernebbi]
orivej has quit [Ping timeout: 240 seconds]
<flokli> Yeah, systemd cross is broken: https://github.com/NixOS/nixpkgs/issues/114687
<{^_^}> #114687 (by Mindavi, 3 hours ago, open): Cross-compilation support for systemd broken
<flokli> Why don't we even test the most basic stuff?
<samueldr> flokli: I've been seeing other breakage from that treewide change
<samueldr> I'm starting to wonder how it was tested
<flokli> I'm somewhat mad, and close to giving up doing any cross if we keep breaking things.
<flokli> Supersandro ran some script, and pressed the merge button
<flokli> This is *not* how reviews should happen
<flokli> I'd rather have something lingering around a bit, until the author of a PR pings the people comfortable reviewing this
<samueldr> I've not had the time to *validate* my claims which is why I've been silent about it
<flokli> Than reviewing something poorly, merging it in, and causing soo much breakage.
<samueldr> and seeing 333 file changes in two commits will make this hard to bisect :/
<flokli> I'll just push a revert commit to master.
<samueldr> too many rebuilds :(
<samueldr> it'll have to go through the staging dance :( :(
<flokli> Well, then I just don't do any cross stuff for the next month.
<flokli> It's *super* frustrating.
<samueldr> yes
<samueldr> I'm still sticking to an early january commit for development
<samueldr> which helps no one really
<samueldr> this is exactly why this week I started writing canaries for cross
<flokli> How many of these are dead right now?
<flokli> Poor little canaries
<samueldr> unclear
<samueldr> but it looks like only my mruby infra was left standing
<samueldr> (once I fixed a real bug)
<flokli> I'm too burned out on this cross stuff for now. It needs to change, it's not sustainable.
<samueldr> yes, I know
<flokli> Either we accept it's a valid thing to care about (and a channel blocker/properly CIed), or we drop it.
<samueldr> once I know the methodology to test with qemu-user (not binfmt!) seems solid enough, I'll try doing the same right in Nixpkgs
<samueldr> flokli: if you have comments about the implementation https://github.com/NixOS/mobile-nixos/pull/317
<{^_^}> mobile-nixos#317 (by samueldr, 3 days ago, open): cross-canary: Execute cross-built binaries using qemu-user
<flokli> But again, I'll take a break on this for a month, to keep healthy.
<samueldr> yeah, I've blocked-off the first week of march to look into the misc. issues with cross
<samueldr> ideally the same concept would go in Nixpkgs, with a few chosen packages
edef has joined #nixos-aarch64
<samueldr> I think the hardest part of checking any of this is that we need to *run* the produced binaries in addition to building them
<samueldr> but running those build results on foreign arches is not exactly trivial...
<samueldr> I guess for aarch64 we could run them on actual hardware
<samueldr> make the input be the cross-compiled package, and just run it
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
monk has left #nixos-aarch64 ["Error from remote client"]
<samueldr> look at me, starting to dogfood things! https://github.com/NixOS/nixpkgs/pull/114693#issuecomment-787538170
<samueldr> I needed an aarch64 X11 desktop, and this was the easiest to get to :)
<samueldr> (I guess the pinebook pro could have been used too)
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
evils has joined #nixos-aarch64