<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
<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)
<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.
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
<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>
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.
<{^_^}>
#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.