<samueldr>
got it with the sd card... now will it work on the iso? :)
<samueldr>
totally looks like somethin in the UEFI boot flow breaks something with rockchipdrm here
h0m1 has quit [Ping timeout: 276 seconds]
h0m1 has joined #nixos-aarch64
<samueldr>
anyone with a "free" RK3399 + HDMI that would know how, and have the time to test an sd image vs. iso image build of the same Nixpkgs (with the same kernel) to see if it's a pinebook pro issue, or RK3399 issue?
<zhaofeng>
But it seems to be the most likely candidate with built-in 5G baseband
<samueldr>
given the lack of transparence they've exhibited previously, I don't have any hopes to see the kernel
<samueldr>
and it won't be mainline-based I bet on it
<zhaofeng>
Guess I'll hold off until I see an actual prototype :/ There doesn't seem to be much information out there even in Chinese
* zhaofeng
prays it won't be some 3.x BSP kernel
<samueldr>
probably not because of android requirements
<samueldr>
but probably some really bad "whatever minimum is required by android" based tree
<samueldr>
what I'm actually more curious is
<samueldr>
how long until the sam ODM design is linked from alibaba or aliexpress
<samueldr>
same*
<samueldr>
in itself it's not necessarily an issue
<zhaofeng>
There are probably just using Anbox as the apps run in JingOS, not via dual-boot
<samueldr>
oh, probably
<samueldr>
or maybe using one of those proprietary products
<samueldr>
there are "anbox-like" products for android
orivej has quit [Ping timeout: 240 seconds]
<samueldr>
great! finally I can tie a bow around my changes
<samueldr>
since I have now basically shown that the issue lies with something in the UEFI boot chain
<samueldr>
hmph... a bit frustrating, but nothin I can't deal with... I guess for now I'll re-setup it in preparation for future UEFI setup, prep an ESP partition and not use it
<samueldr>
I kind of confirmed that with extlinux.conf booting poweroff works fine
figgyc has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-aarch64
orivej has joined #nixos-aarch64
srk has joined #nixos-aarch64
cole-h has quit [Ping timeout: 240 seconds]
bennofs_ has quit [Read error: Connection reset by peer]
bennofs_ has joined #nixos-aarch64
<sphalerite>
samueldr: as in it will just configure a new output automatically?
orivej has quit [Ping timeout: 240 seconds]
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
dev_mohe has quit [Client Quit]
<dupon1>
Hi, I'm following the wiki guide to build my own ARM image but can't figure out how to cross compile the image
bennofs has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
<samueldr>
sphalerite: (pinephone DP output) IIRC I needed to go to the displays panel
<samueldr>
and uh, needed the "prefer modesetting" PR to be applied
<sphalerite>
hm, difficulty with that was (for me at least) that it doesn't fit on the screen…
<samueldr>
yeah, I tested before the xfce bump that broke the interfaces somewhat :(
<samueldr>
"broke"...
<samueldr>
get in a shell, export DISPLAY=:0 and use xrandr?
Mindavi has quit [Quit: leaving]
<dxb[m]>
is fetchgit broken in nixos-unstable? it looks like it's trying to fetch the nixos branch instead of the branch i'm telling it to fetch
justanotheruser has quit [Ping timeout: 250 seconds]
raspi4 has joined #nixos-aarch64
<raspi4>
hi guys, does the gui stuff (x11, mesa, gpu) work on latest raspberry 4 build?
<samueldr>
that's a trick question
<raspi4>
hehe
<samueldr>
IIRC some combination of vendor kernel + vendor boot chain may work
<dupon1>
I tried to generate an SD-image with Qemu but it takes ages and can't find how to cross-compile but saw people saying on samueldr's logs it's working
<samueldr>
not sure if mainline linux has it working with acceleration
<raspi4>
i had it working a year ago but lately i crashed it (my fault) so i rebuilt fresh version
<samueldr>
it's possible that if U-Boot is involved, even with the vendor kernel, there will be uh... things... to do
<samueldr>
things that I'm not really sure what though
<raspi4>
well you got the hardware? then i suggest you just copy the image onto an sd
<raspi4>
i got the problem with the device-tree-overlays
<raspi4>
when i try to get the graphic with acceleration to work
<samueldr>
[08:28:01] <dupon1> Hi, I'm following the wiki guide to build my own ARM image but can't figure out how to cross compile the image
<samueldr>
(that was their earlier message, since raspi4 might not have seen it)
<samueldr>
ARM is vague :) armv6, armv7 or aarch64?
<raspi4>
no idea how to help with cross compiling, didnt manage to get it working last time i tried
<dupon1>
samueldr: oops, forgot to say which ^^' it's aarch64
<samueldr>
it's not exactly working out of the box still
<samueldr>
for the time being there are issues that needs Nixpkgs patches still
<raspi4>
hmm
<samueldr>
and then some workarounds can be done strictly in NixOS options
<samueldr>
raspi4: which board?
<samueldr>
oops
<samueldr>
dupon1: which board?
<dupon1>
I yet have the board but target is Pine64 (normal, not the pro)
<samueldr>
if it's well supported by the mainline kernel, you shouldn't need to build anything
<samueldr>
dupon1: a big vague, unqualified "Pine64" is their allwinner offer
<samueldr>
but since you said pro
<samueldr>
might be rock64 from pine64 ?
* dupon1
is tired
<samueldr>
a bit*
<dupon1>
the Rock64
<samueldr>
no worries :)
<samueldr>
right
<samueldr>
I don't remember if that's well supported by mainline
<dupon1>
it's "community supported"
<dupon1>
according to wiki
<samueldr>
yeah, I mean by the "mainline" linux kernel
<samueldr>
which means the kernel from kernel.org, without additional patches
<samueldr>
which is what we build in the aarch64 images
<samueldr>
but even with the tip of master, won't cross-compile an sd image or iso image
<samueldr>
though AFAIK everything is available either in PRs or on its way through staging
justanotheruser has joined #nixos-aarch64
<dupon1>
hum okay
<zhaofeng>
Or spend $800 on an M1 Mac :) This thing's performance is unreal, I must say
<dupon1>
so you advise me to native build it? (because cross-compile is likely impossible?)
<dupon1>
zhaofeng: haha
<samueldr>
no, don't buy M1 for linux, unless you research and understand what you get yourself into
<samueldr>
dupon1: cross-compiling with NixOS is going to make things harder on you
<samueldr>
so I advise it only if you're really confident with everything else in your project
<samueldr>
e.g. I was fixing up some issues with the sd image and iso images for arm, I am really confident in everything Nixpkgs/NixOS with those builds, so adding the cross-compilation issues means I'm 99.9% sure that the issues I face are caused by cross-compilation
<dupon1>
if it don't requires me to be confident in my lif- I see, NinjaTrappeur told me he had terrible failure with cross-compiling
<samueldr>
if I wasn't already confident in the results, then I couldn't really "get" what the root causes of the issues are :)
<dupon1>
I get it
figgyc has joined #nixos-aarch64
<samueldr>
it's not "don't cross-compile"... but... "cross-compilation is another layer of issues you might want to avoid until you know everything else is supposed to work"
<samueldr>
"so that when you hit issues, you're not left scratching your head wondering why"
<dupon1>
I understand, I'll get two boards, one to compile and the other to test builds
<samueldr>
though you probably can start with one board, as long as you have a way to switch the storage out :)
<samueldr>
(assuming you already have one board)
<raspi4>
you could use an usb card reader
<samueldr>
uuh... to write the sd image from linux, yeah... to boot... YMMV
<dupon1>
I yet have a board and I'll wait next month to order one or more, it will give me time to think about :)
zupo has joined #nixos-aarch64
<raspi4>
Error at 'compatible': FDT_ERR_NOTFOUND
<raspi4>
builder for '/nix/store/30ljrfbjawpfw1cmd83cn90f3m4h347l-device-tree-overlays.drv' failed with exit code 1
<raspi4>
cannot build derivation '/nix/store/a2k0r076g0ja4pzpg078jizwpcsl8q9v-nixos-system-raspi-21.05pre286880.7cb76200088.drv': 1 dependencies couldn't be built
<raspi4>
error: build of '/nix/store/a2k0r076g0ja4pzpg078jizwpcsl8q9v-nixos-system-raspi-21.05pre286880.7cb76200088.drv' failed
<raspi4>
any idea?
<samueldr>
FDT_ERR_NOTFOUND is most likely what happens when applying an overlay to a dtb file that either doesn't have labels enabled, or doesn't have the node the overlay is looking for
<samueldr>
with the pi4, probably trying to apply an overlay for the vendor kernel on top of mainline
<samueldr>
that is the configuration that will allow you to use the vendor kernel
<raspi4>
got that line
<samueldr>
then it's odd
<samueldr>
I'm really not familiar with the overlays stuff in NixOS
<raspi4>
me neither :/
raspi4 has quit [Quit: Connection closed]
<dxb[m]>
is there something i can put in my config to hide the mouse?
<dxb[m]>
like to just have it always hidden
<samueldr>
dxb[m]: unclutter maybe
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<CRTified[m]>
So, I've been redirected here (again): Does anyone has a config for the rpi3b+ at hand where wifi works? According to ip a and the wpa_supplicant log, there is a connection, but the RPi is not reachable over wifi and wpa_supplicant also complains about "RRM: Ignoring radio measurement request: Not RRM network". I'm on nixos-21.05pre286925.3e62e383f4b, the RPi is set up with nixops and using linuxPackages_latest
* colemickens
is tempted to get a rpi3b+ just to help out sometimes, I didnt know it was so popular
<CRTified[m]>
I might have one spare 3b+ right now, as I want to move away from them :D
<CRTified[m]>
Originally used one for my 3D printer with octoprint (I'm migrating that right now to using nixops, as seen above), and already replaced one for running home assistant with a RockPi 4C (I'm having wifi problems on that one, too... Somehow I'm always fighting with wifi on these things)
<colemickens>
oh plus there's a cute little flirc case for it even
apache8080 has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 240 seconds]
apache8080 has joined #nixos-aarch64
<apache8080>
Has anyone setup full disk encryption on a raspberry pi with nixos?
<samueldr>
yes
<apache8080>
do you have a link to an example?
<samueldr>
no
<samueldr>
anyway it wouldn't help much for the config
<samueldr>
since the config is basically the same as on any other NixOS system
<samueldr>
what differs is how it was installed
<apache8080>
oh, did you have to modify the sd-image.nix script in any way?
<samueldr>
encryption through a nix-build is probably a big no no :)
<apache8080>
oh ok
<samueldr>
sd-image should be seen as a shortcut to an end-result
<samueldr>
it's a ready-to-run system
<samueldr>
but you can `nixos-install` to another media!
<samueldr>
either from the sd-image build, or from alternative ways to boot
<samueldr>
the main issue there is how to get the "initial boot firmware" parts set up properly
<apache8080>
hmm ok, so during that install step then I would setup the other media for encryption
<samueldr>
yeah
<samueldr>
you have to be aware of the boot scheme you want to use
<samueldr>
whether it's through the raspberry pi "config.txt" scheme which directly loads a kernel, through some other U-Boot based boot schemes, or UEFI through tianocore
<samueldr>
sadly I don't really have (yet) documentation for that part
<apache8080>
so right now we have just been building sd-images for the various arm boards we are using and booting and running off of that, thats why I was looking at encryption at nix-build time
<samueldr>
know that this means the secret (the passphrase) will be part of the build
<apache8080>
ah ok
<samueldr>
(or you need to work a lot more to not have it part of the build)
<samueldr>
and the image builder is currently strongly railroaded into its use case
<apache8080>
that makes sense
<samueldr>
so even if you had a method to do so, it would be hard to integrate with the current setup
<samueldr>
(not impossible!)
<apache8080>
ok, thanks for the help
<samueldr>
sorry there was no all-in-one answer, but that's the gist of it
<samueldr>
oh, and really, being aware of your boot chain here is probably the most helpful "first step" for further customizations of the installation