<buovjaga>
I get a kernel panic with my F2FS image. Here is the panic + diffs of my modifications to the nix files used for building the image: https://paste.simplylinux.ch/view/18070502
<buovjaga>
I am at a loss on how to fully trace that :(
<buovjaga>
(the output is from qemu, it also hangs in an actual Rpi3)
<buovjaga>
Mic92: how can I pass the parameter? Somehow from stage-1.nix? I tried to figure it out, but the only solution I could think of was to brute force it in stage-1-init.sh to fail before the for loop.
s33se has quit [Ping timeout: 248 seconds]
<Mic92>
buovjaga: there is boot.kernelParams
<buovjaga>
urgh, why didn't I notice it :) thanks
* buovjaga
goes to bake another image
<clever>
Mic92, buovjaga: grub also allows you to edit the kernel params on the fly
<samueldr>
grub on rpi3?
<clever>
oh, didnt notice which room i'm in, lol
<samueldr>
:)
<samueldr>
though, does u-boot allow editing the parameters or only entering bootcmd from an empty line?
<clever>
in the case of the rpi, you can just manually edit the config.txt or cmd_line.txt on the fat32
<samueldr>
(and then editing extlinux.conf should work)
<clever>
and that
<samueldr>
config.txt may not be helpful with nixos, IIRC
<samueldr>
(since it boots u-boot)
<Dezgeg>
UEFI grub on rpi3 should be entirely possible by using U-Boot as the EFI implementation
<clever>
:D
<Dezgeg>
I think fedora or something ships that in their images, actually
<buovjaga>
hmh, now I booted my new debug1 image, but it stops at "Freeing unused kernel memory: 6784K"
<buovjaga>
should I try trace instead?
<dtz>
hey anyone know of any "gotchas" re:aarch64 and stack-protector usage ... that might explain breakage not present on x86_64? The breakage is in /my software/ so I'm likely doing something wrong and getting away with it when I shouldn't :P but thought I'd ask :)
<dtz>
whoa, what, maybe that's unrelated. Oh boy I hope it's unrelated.
<Dezgeg>
at least I have never encountered anything stack-protector related
orivej has joined #nixos-aarch64
<dtz>
plenty good for me ^_^ ty
<Dezgeg>
buovjaga, I guess tweaking the console=ttyXYZ lines might make it show more output
<Dezgeg>
remove all console= entries except the ttyAMA0 one (for QEMU that is)
<buovjaga>
urgh, I think I put the debug in the wrong .nix :(
* buovjaga
tries harder
<buovjaga>
Dezgeg: do you have an idea, why qemu will only boot with a maximum of 2048M DRAM?
<buovjaga>
maybe it would make building faster, if I could use 16GB
<buovjaga>
ok now I'm building with the minimised console= stuff
<Dezgeg>
for debugging purposes it's probably easiest to hack on the extlinux.conf file directly instead of a full image building cycle each time
<buovjaga>
ok
<buovjaga>
Dezgeg: ooh, it indeed got more talkative: switch_root: can't execute '/nix/store/qwf1lxndiabgsihp7idvj3i4c1dbjddh-nixos-system-nixos-18.03.git.e2d25035155/init': No such file or directory
<buovjaga>
dude, where's my init?
<buovjaga>
hmm, is this correct? /dev/disk/by-label/NIXOS_SD
<buovjaga>
I guess so
orivej has quit [Ping timeout: 248 seconds]
<buovjaga>
I am looking inside the image and I don't get it... there is no /nix/store/ in here
<buovjaga>
ok so something went wrong in the building as there is no /nix/store in the _SD
<buovjaga>
f*cking piping to debugfs did not work!