justanotheruser has quit [Ping timeout: 260 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vikanezrimaya has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
vikanezrimaya has quit [Quit: Connection closed]
vikanezrimaya has joined #nixos-aarch64
cole-h has quit [Ping timeout: 244 seconds]
vikanezrimaya has quit [Quit: Connection closed]
rajivr has joined #nixos-aarch64
<rng4>
on a scale of "why haven't you just done it already" to "you should start with transforming mars", how hard would it be to kexec on a raspberry pi 3B+ to format the sdcard to use zfs for root?
<clever>
rng4: the kexec stuff ive done, needs a decent amount of ram, a pi3 may not have enough
<clever>
i also dont know if arm kexec is reliably
<clever>
reliable*
<clever>
booting from usb would be far simpler
<rng4>
I'm currently using nixos-generate sd-aarch64-installer to build the initial image. Would it be as simple as booting that image from usb, partitioning the sdcard into a vfat boot partition and a zfs root partition, and doing a nixos-install? Something made me think that it wouldn't be that easy with nix on the pi. Maybe the way firmware or uboot
<rng4>
worked.
<evils>
hmm, how do i get most of my pi's RAM available on headless nixos? (i'm getting 895MB vs raspios' 936MB) (i have `boot.loader.raspberryPi.firmware.config = "gpu_mem=16";`)
justanotheruser has quit [Quit: WeeChat 2.9]
dev_mohe1 has joined #nixos-aarch64
dev_mohe has quit [Ping timeout: 244 seconds]
dev_mohe1 is now known as dev_mohe
<samueldr>
rng4: you can also install to another sd card connected through a usb adapter
h0m1 has quit [Ping timeout: 264 seconds]
h0m1 has joined #nixos-aarch64
rng4 has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 244 seconds]
justanotheruser has joined #nixos-aarch64
mla has quit [Ping timeout: 265 seconds]
CodeKiwi has joined #nixos-aarch64
DigitalKiwi has quit [Ping timeout: 260 seconds]
cole-h has joined #nixos-aarch64
zhaofeng has quit [Ping timeout: 260 seconds]
zhaofeng has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
cole-h has quit [Ping timeout: 245 seconds]
jumper149 has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
monk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
jumper149 has quit [Ping timeout: 256 seconds]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Quit: WeeChat 3.1]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 260 seconds]
jumper149 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
ib07 has quit [Ping timeout: 265 seconds]
justanotheruser has quit [Ping timeout: 244 seconds]
<Ke>
so there's some support for cross-compiling natively(?) with-qemu user, does it actually most of the time work and does it work with binary caches
<Ke>
I guess that's a question?
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<aforemny>
Ke: Yes and yes. I am right now facing an issue where building an sdImage using aarch64 emulation seg faults (but building the system succeeds). But this is really the first issue I've encountered. So far i thas been a rather great experience.
<aforemny>
(I have not investigated if it segfaults strictly because of aarch64 emulation.)
justanotheruser has joined #nixos-aarch64
jumper149 has quit [Ping timeout: 276 seconds]
<Ke>
wow, this is slow
orivej has quit [Ping timeout: 264 seconds]
monk has left #nixos-aarch64 ["Error from remote client"]
zupo has joined #nixos-aarch64
justan0theruser has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 244 seconds]
<samueldr>
qemu-user is not cross-compiling, but native compiling with extra steps
<samueldr>
and it means that it works "like native compiling"
<samueldr>
including the use of binary caches
<samueldr>
but doing compilation through qemu-user is not guaranteed to give the right results
<samueldr>
the closer you are to a full rebuild, the less likely it is to end up successful
<samueldr>
but if it's mostly assembling the final parts, AFAIK it's been quite good
cole-h has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<aforemny>
I have been doing whole system builds with qemu-user a couple of times now (using binary substitutes though). No complaints here so far! :fingerscrossed:
<aforemny>
The aforementioned seg fault seems to be Nix rather than qemu-user. At least I can reproduce it without passing `--argstr system aarch64`.
<samueldr>
it *may* be that this is worse on armv7
<samueldr>
(or armv6 even)
<Ke>
samueldr: sure
<Ke>
anyway using binary caches is a huge deal
marijan[m] has quit [Quit: Idle for 30+ days]
mla has joined #nixos-aarch64
ib07 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ib07 has quit [Ping timeout: 245 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
<ar>
samueldr: I haven't yet had a failure with qemu-user for aarch64
<samueldr>
I know for sure with 32 bit arm I had, I don't recall if I had for aarch64
<samueldr>
and issues may have been fixed since then
<samueldr>
(I mean, in upstream qemu)
<samueldr>
but still, ambient impurities are going to be wildly different
<zhaofeng>
ar: I couldn't build gtk in qemu-user. Meson couldn't resolve some dependency for some reason
Ox4A6F has quit [Quit: authenticating]
Ox4A6F has joined #nixos-aarch64
<Ke>
so I found this, I guess that means that aarch64 rfc did not progress?
<Ke>
apparently the meetings are quite frequent, if the next one is on april fools day
<Ke>
or was not handled
<Ke>
best day for outside the box rfcs
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-aarch64
<samueldr>
danielrf[m]: do you know of any project packaging the dynamic partition tools in a standalone way?
<samueldr>
fun! their graphics for dynamic partitions also includes a distinct recovery partition
<samueldr>
oh
<samueldr>
>> Devices launching with Android 10 must not use system-as-root.
<samueldr>
boot as recovery is synonymous with system-as-root
<samueldr>
well, not exactly
<samueldr>
the initramfs could still be selecting between normal boot, recovery, or fastbootd
<danielrf[m]>
Does lpdump actually dump the partitions, or does it just "display pretty-printed partition metadata" ?
<samueldr>
>> When BOARD_USES_RECOVERY_AS_BOOT is set to true, the recovery image is built as boot.img, containing the recovery's ramdisk. Previously, bootloader used the skip_initramfs kernel command line parameter to decide which mode to boot into. For Android 10 devices, the bootloader MUST NOT pass skip_initramfs to the kernel command-line. Instead, bootloader should pass androidboot.force_normal_boot=1 to skip recovery and boot normal Android
<samueldr>
danielrf[m]: no idea yet, haven't ran any of it still
<samueldr>
might be I would need lpunpack
<danielrf[m]>
lpunpack does seem to build with soongnix
<danielrf[m]>
I don't envy you having to deal with all this complexity
<samueldr>
haha, at the very least it's only needed to get the vendor partition
<samueldr>
I'm 99.999% sure we're just writing whatever we want on the super partition
<samueldr>
doesn't really make sense otherwise
<danielrf[m]>
I'd agree
<danielrf[m]>
would just need to check that fastbootd can figure out it needs to virtually repartition if the user later wants to put android on it
<samueldr>
exactly
<samueldr>
though, in case of doubt, userdata is still a distinct partition, and in that case `super` is just an unused psan