Ashy has left #nixos-aarch64 ["WeeChat 1.9.1"]
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
h0m1 has quit [Ping timeout: 260 seconds]
alp has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
knerten has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
zupo has quit [Remote host closed the connection]
cole-h has quit [Quit: Goodbye]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bennofs_ has joined #nixos-aarch64
bennofs has quit [Ping timeout: 240 seconds]
<patagonicus> Hmm. How can I cross compile a single package with nix-build for armv7? nix build nixpkgs.pgksCross.armv7l complains that armv7l doesn't exist (armv7 as well).
<clever> > pgksCross
<{^_^}> undefined variable 'pgksCross' at (string):318:1
<clever> > pkgsCross
<{^_^}> { aarch64-android-prebuilt = <CODE>; aarch64-embedded = <CODE>; aarch64-multiplatform = <CODE>; aarch64-multiplatform-musl = <CODE>; aarch64be-embedded = <CODE>; amd64-netbsd = <CODE>; arm-embedded = ...
<patagonicus> Ah, I think it's armv7l-hf-multiplatform
<clever> yep
<patagonicus> But now it's complaining that amdgpu-pro is Linux only, which is weird, since I'm trying to build the hardkernel kernel and I don't think that depends on any amdgpu things.
<clever> whats the full attr path?
<patagonicus> I'm trying nix-build -A pkgsCross.armv7l-hf-multiplatform.linuxPackages_hardkernel_4_14
<clever> thats not building the kernel
<clever> you gave it an attrset of every kernel module
<patagonicus> Argh, forgot about that one again.
<clever> so its building everykernel module!
<clever> add .kernel to the end
<patagonicus> Yep, .kernel works. :)
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Remote host closed the connection]
zupo has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pbb has quit [Read error: Connection reset by peer]
pbb has joined #nixos-aarch64
mvnetbiz_ has quit [Quit: Bye!]
mvnetbiz_ has joined #nixos-aarch64
Takan has joined #nixos-aarch64
<Takan> hi
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Takan has quit [Remote host closed the connection]
g-607 has joined #nixos-aarch64
g-607 has quit [Client Quit]
mobian has joined #nixos-aarch64
mobian has quit [Client Quit]
g-607 has joined #nixos-aarch64
g-607 has quit [Read error: Connection reset by peer]
g-607 has joined #nixos-aarch64
g-607 has quit [Quit: g-607]
cole-h has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<fps> when resizing the boot partition on an sdcard, is that more involved than just using gparted to resize it (including shrinking of the root partition)?
<fps> [rpi4]
rajivr has quit [Quit: Connection closed for inactivity]
<patagonicus> fps: I don't know about the RPi4 specifically, but RPi1 and 3 don't really care much, so I'd guess you're good.
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-aarch64
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
<samueldr> patagonicus: rpi4 is using the raspberry pi boot flow, not u-boot one, so the boot partition is still important
<samueldr> fps: you're right, the raspberry pi doesn't care much about specifics of the partition
<samueldr> fps: so using gparted to edit all of that is fine
<samueldr> there is no magic offset, no specific flags
<patagonicus> Yeah, you need the boot partition, but as long as it's the first and FAT32 it's probably going to work (with the right files in it).
<samueldr> I'm not even sure it needs to be the first
<patagonicus> Well, the multiplatform image doesn't mark it as bootable, so that's not how it finds it. But it might just check all partitions marked as FAT32 (I think that's "b" in MBR speak).
<samueldr> of directly peeking at the FS
<samueldr> I don't know how exactly
<samueldr> note that looking at the multiplatform image could be misleading, since it has things like the EXT4 partition being marked bootable, this is for u-boot
<samueldr> (and u-boot is what's being booted on the rpi3 with that image)
<samueldr> I don't know if I should take a look at the pi4 rpi-foundation kernel + u-boot again and see if now it works
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> at least remove one part of the possible confusion
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has quit [Quit: Leaving]
N47HZ has joined #nixos-aarch64
<fps> patagonicus: samueldr: thanks. will give it a go then :)
N47HZ_ has joined #nixos-aarch64
N47HZ has quit [Ping timeout: 256 seconds]
N47HZ_ has quit [Remote host closed the connection]
<patagonicus> Hmm. I moved /nix/store and /tmp to my SSD, but / seems a bit weird now. df -h claims 12G/30G used, but du -schx only finds 1.1G.
<patagonicus> Ah, --apparent-size at least gives me 11G. Let's figure out where that's coming from. :)
<patagonicus> Aha! Forgot to delete /nix/store/.links and that's 9.5G. :)
<samueldr> .links is used for optimizing the store wtih --optimise-store
<samueldr> by creating hard links
<samueldr> though I guess since you copied things... hard links are probably not relevant anymore
<patagonicus> Yep, just found that by googling. Didn't expect /nix/store to have hidden files and I didn't want to delete the dir on the running system since that's used as a mount point. :)
<patagonicus> So, now I just need to figure out how to get the ethernet adapter to work in stage1 one so I can do remote unlocking of root on (LVM on) luks.
<patagonicus> But, tomorrow I'll order more HC2. And a network switch, I guess, because I need more ports.
<samueldr> patagonicus: lsmod, find which module looks networky in there
<samueldr> and add it to boot.kernelModules
<samueldr> you should need only the "leafy" module, the one that is actually for your hardware, and not the dependencies along the way
<samueldr> but sometimes the dependencies are not defined well inside the kernel and you might need to add a couple "accessory" modules too
<patagonicus> Hmm. Is there a difference between that and availableKernelModules? I put it in there and AFAICT it gets loaded, but by the time eth0 appears, udhcp is already running, but only for sit0 and ip6tnl0, which don't help.
<patagonicus> (Seems to be module r8152 by the way)
<samueldr> available doesn't load them for you
<samueldr> udev eventually will load it in stage-1 though
<samueldr> so in reality not much except if udev somehow doesn't load it
<samueldr> ah
<patagonicus> Ah, so for kernelModules they are force loaded before other stuff in stage1 runs?
<samueldr> yes, but "other stuff" is udev
<patagonicus> … I should really go to bed, but now I want to try that.
<samueldr> so if it's loaded by udev, I don't think it will change anything
<patagonicus> Hmm
<samueldr> unless the networking is done in preDeviceCommands
<patagonicus> Let me boot the image I currently have, with it in available to get the log.
<samueldr> preLVM
<samueldr> if you're sure it's timing, you could lib.mkBefore a waitDevice with some path that gets added for network devices
<samueldr> e.g. maybe /sys/class/net/enp2s0
<patagonicus> https://gist.github.com/Patagonicus/b1297f983e618ed42f5410d841c4cde4 There's the line at 6.47 with eth0 in it which makes me think that it gets loaded at some point.
<patagonicus> The SATA disk also takes a long time to show up, as in multiple seconds, so maybe it just takes longer than udev settle waits for.
<patagonicus> I'll try the waitDevice tomorrow, sounds like a good idea. Thanks!
<samueldr> not necessarily good, but at least workable
<samueldr> it will add delay
<patagonicus> I can live with "it works". I also used to use a udev rule to run vgchange -ay because otherwise stage2 wouldn't activate the volumes on the SATA disk. Having at least on volume on there needed for boot makes stage1 wait for it and activate it.
<samueldr> yeah
<samueldr> waitDevice is kinda made for that
<samueldr> hmm, whatever the issue is, streaming the function calls using trace-cmd trace doesn't help
<samueldr> (quite obvious in hindsight since it happens in userspace)
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ has quit [Remote host closed the connection]
tilpner_ has joined #nixos-aarch64
tilpner_ is now known as tilpner
orivej_ has quit [Ping timeout: 256 seconds]