Cannot build the default example

[jtanguy]

Hello, and thanks for this project.

I cannot reproduce the default example tough, the pi does not seem to boot and just shows a black screen. Running a base image built from hydra works tough.

Is there something I am missing in the initial image build ? Should it be built on the pi itself, or should I use a pinned nixpkgs?

Technical details for my system

- system: `"x86_64-linux"` - host os: `Linux 5.4.35, NixOS, 20.09pre223023.fce7562cf46 (Nightingale)` - multi-user?: `yes` - sandbox: `yes` - version: `nix-env (Nix) 2.4pre7346_5e7ccdc9` - channels(jtanguy): `"home-manager"` - channels(root): `"nixos-20.09pre223023.fce7562cf46, home-manager"` - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[jtanguy]

I finally managed to make it work. Somehow config.txt was missing the flag arm_64bit=1, even tough my target is raspberryPi4

[matthewbauer]

I think 2fefdbe51c5436b5fd05ea048af744c6a690b1fd will get that working again. The issue was I forgot to include the values from loader.raspberryPi in the initial image.

[jtanguy]

Ok it builds clean now. There are still some things not working:

• the service cage-tty1 fails to start with no helpful error message, I'll keep investigating.
• when I try to update the configuration via nix, the builder has a lot to rebuild, starting with a pinned version of what seems to be your fork of nixpkgs. Should I pin my original build with the same version ?

[c0deaddict]

I have the same issue with cage-tty1 not starting.

Rebuilding doesn't work me. nix-build crashes with an out of memory exception. I'm running it on a Pi 3 with 1GB of RAM. Maybe that is too little.

[jtanguy]

I have the feeling that I must be doing something wrong, I believe that I should not have to compile so many things, from cmake to systemd.

I updated to the latest code with pinned nixpkgs, but I feel that I am building too many things

plan.txt

[matthewbauer]

• For cage-tty1 failing, it may be some graphics driver not initializing. I have only tested on rpi0, and rpi4, so that could be a source of problems. Might want to see if there are any helpful errors in journalctl.

• The rebuilding situation is still kind of difficult. It will take a lot of memory to rebuild, and that means that maybe even the rpi3 can't do it. But the rpi4 works and be able to utilize the nixos binary cache. There may have been an issue with not basing off of a nixos-unstable channel, so I'll try rebasing to see if that gets more cache hits.

[jtanguy]

The output of journalctl differs if I pin my version of nixpkgs with niv to the version of nixpkgs pinned in the sources: I added some debug env variables to the cage service.

Without pinning (I am on the unstable branch)

``` Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [EGL] command: eglGetPlatformDisplay, error: 0x300c, message: "_eglGetPlatformDisplayCommon" Jan 01 01:00:12 makair cage[811]: libEGL debug: EGL user error 0x300c (EGL_BAD_PARAMETER) in eglGetPlatformDisplay: _eglGetPlatformDisplayCommon Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [EGL] command: eglGetPlatformDisplayEXT, error: 0x300c, message: "Could not create EGLDisplay" Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [render/egl.c:176] Failed to create EGL display Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [EGL] command: eglMakeCurrent, error: 0x3008, message: "Invalid display (nil)" Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [render/wlr_renderer.c:221] Could not initialize EGL Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [backend/drm/renderer.c:40] Failed to create EGL/WLR renderer Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [backend/drm/backend.c:203] Failed to initialize renderer Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [backend/backend.c:163] Failed to open DRM device 11 Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [backend/drm/drm.c:56] DRM_CRTC_IN_VBLANK_EVENT unsupported Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [backend/backend.c:163] Failed to open DRM device 12 Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [backend/backend.c:304] Failed to open any DRM device Jan 01 01:00:12 makair cage[811]: 1970-01-01 01:00:12 - [../cage.c:209] Unable to create the wlroots backend ```

With pinning

``` Jan 01 01:00:12 makair cage[803]: libGL: Can't open configuration file /etc/drirc: No such file or directory. Jan 01 01:00:12 makair cage[803]: libGL: Can't open configuration file /home/kiosk/.drirc: No such file or directory. Jan 01 01:00:12 makair cage[803]: MESA-LOADER: failed to open vc4 (search paths /run/opengl-driver/lib/dri) Jan 01 01:00:12 makair cage[803]: failed to load driver: vc4 Jan 01 01:00:12 makair cage[803]: MESA-LOADER: failed to open kms_swrast (search paths /run/opengl-driver/lib/dri) Jan 01 01:00:12 makair cage[803]: failed to load driver: kms_swrast Jan 01 01:00:12 makair cage[803]: MESA-LOADER: failed to open swrast (search paths /run/opengl-driver/lib/dri) Jan 01 01:00:12 makair cage[803]: failed to load swrast driver Jan 01 01:00:12 makair cage[803]: 1970-01-01 01:00:12 - [backend/drm/renderer.c:19] Failed to create GBM device Jan 01 01:00:12 makair cage[803]: 1970-01-01 01:00:12 - [backend/drm/backend.c:203] Failed to initialize renderer Jan 01 01:00:12 makair cage[803]: 1970-01-01 01:00:12 - [backend/backend.c:163] Failed to open DRM device 11 Jan 01 01:00:12 makair cage[803]: 1970-01-01 01:00:12 - [backend/drm/drm.c:56] DRM_CRTC_IN_VBLANK_EVENT unsupported Jan 01 01:00:12 makair cage[803]: 1970-01-01 01:00:12 - [backend/backend.c:163] Failed to open DRM device 12 Jan 01 01:00:12 makair cage[803]: 1970-01-01 01:00:12 - [backend/backend.c:304] Failed to open any DRM device Jan 01 01:00:12 makair cage[803]: 1970-01-01 01:00:12 - [../cage.c:209] Unable to create the wlroots backend ``` Running `ls` in `/run/opengl-driver/lib/dri` gives the following output: ``` # ls /run/opengl-driver/lib/dri/ i915_dri.so iris_dri.so nouveau_dri.so nouveau_vieux_dri.so r300_dri.so r600_drv_video.so radeonsi_dri.so swrast_dri.so vmwgfx_dri.so i965_dri.so kms_swrast_dri.so nouveau_drv_video.so r200_dri.so r600_dri.so radeon_dri.so radeonsi_drv_video.so virtio_gpu_dri.so ```

I am using a rpi4 with the official 7inch touchscreen display.

I've also narrowed it down to the video drivers, and tried several variations around the hardware.opengl and mesa.eglPlatforms options, without success.

[matthewbauer]

So this looks like the driver isn't being loaded at all. You can confirm this by seeing if /dev/dri/card0 exists. The module for the touch screen is called rpi_ft5406, so there may be some logs related to that.

According to some online searching, you may be able to add dtoverlay=rpi-ft5406 to the config.txt. Try a7930165c7d07f67218a6d67c91c8dc5ef620ae0

[jtanguy]

The results are the same. That being said, the plymouth boot screen is displayed properly, so that tells me that at least the screen is working properly

[c0deaddict]

@jtanguy how are you building the image with the pinned version? I think i'm having the same problem, I get the same error messages as you got "without pinning".

[matthewbauer]

Ugh... I think this was caused by me not checking for regressions on actually rpi hardware. I think I'll have a fix soon! Apologies to both of you, I had completely forgot that we need to build mesa with drm enabled.

[matthewbauer]

That should be fixed in 476c700372ad0ce75a665db93a7c2f9b413f8ba8. I'll be uploading to the cache now.

[jtanguy]

It seems to work. I cannot say for sure because my target package is not properly cross-compiled for raspberry, but now i see my program failing in journalctl, not cage itself

[matthewbauer]

To improve the rebuild situation, I've added a redeploy.sh script which can be run on live systems. For instance:

$ ./redeploy.sh kodpi2.json kodipi2.local

will build and copy to a running system.

[c0deaddict]

Nice, it works now with retroarch :tada: the default example with epiphany gives an error. The redeploy.sh also works for me. Thanks @matthewbauer!

[c0deaddict]

There is one issue that I encounter with the redeploy: at reboot it falls back to the first build profile. It seems the systemConfig in /boot/nixos-init is not updated?

[matthewbauer]

There is one issue that I encounter with the redeploy: at reboot it falls back to the first build profile. It seems the systemConfig in /boot/nixos-init is not updated?

I saw this too, but thought it went away (might have been uboot though). Does updating the boot generations directory... appear in your output?

[c0deaddict]

Now that i pulled from master it does show that message and it also works :) I noticed that uboot is now disabled for the Pi 3, maybe that was the problem.