Posts by chewitt
-
-
I put a note in the wiki article about Samba server and Kodi SMB client being separate things. Other than that I wouldn't document the client from a security perspective as this is making outbound connections (not receiving inbound) so it's not contributing to the attack-surface of an installation.
LE is loosly based on https://www.linuxfromscratch.org/ principles if you want to read up. Brace yourself for an exciting read

-
Code
Jan 07 20:45:54.278148 LibreELEC kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034] ... Jan 07 20:45:54.290312 LibreELEC kernel: [drm] Initialized meson 1.0.0 for d0100000.vpu on minor 0 Jan 07 20:45:54.290363 LibreELEC kernel: Console: switching to colour frame buffer device 240x67 Jan 07 20:45:54.290917 LibreELEC kernel: meson-drm d0100000.vpu: [drm] fb0: mesondrmfb frame buffer deviceNope, that's the moment 0.12 seconds after kernel boot when the simplefb device used during early stage boot is unloaded and the kernel switches to the meson (Amlogic) fb device provided by the VPU on the SoC which is now ready for use.
There is nothing helpful in the logs at this point and garbear understands what the overall issue is about. You can stop guessing.
-
Open a separate thread about the remote issue. Keep it focussed on technical details (no need for the install life-story).
-
I created https://wiki.libreelec.tv/installation/security in the install section so it's more visible. This is public documentation that can be added-to by anyone who cares enough to make the effort.
-
Same black screen
system log https://paste.libreelec.tv/arriving-jaybird.logOdd. This time there's no crashes or complaints about stride size and buffers. The logs look clean.
-
I think the cause is a GPU driver issue (missing mali regulator, crash log):
That's a wrong guess (and if you don't know the answer, don't guess). Amlogic hardware has no Mali regulators so the frequency scaling code in the Mali probe/initialisation code correctly cannot find them and throws an error, which is harmless. Tweaking the kernel code to stop bogus user reports of GPU bugs is something I'd like to solve, but it's harder than it looks.
I've asked Q's to garbear who maintains Kodi retroplayer.
-
In syslinux.cfg you can set "boot=/dev/sda1 disk=/dev/sda2" where /dev/sda1 is the /flash (boot) partition, and /dev/sda2 will be used for the /storage. You can also mount using disk labels, e.g. "boot=LABEL=LIBREELEC" or UUIDs. The full list of boot flags is a mix of LE specific things (read the 'init' script which is in the initramfs, see in the busybox package) and kernel things, which will be covered by kernel documentation on boot params. I would recommend configuring the PC to boot from USB and leave it that way until something works.
Back on-topic:
The fact we see some variant of failing to create an EGL surface under both display environments perhaps hints to something in-common between them. LE uses OpenGL-ES for Generic (GBM) and OpenGL for Generic-Legacy (X11) images. Both environments leverage mesa, but in different ways. I know mglae is already thinking about a mesa bug, and I'm starting to wonder the same.
I pushed changes to the patch so "Nouveau" is now GBM, and I added "Nouveau-Legacy" which uses X11 (as you've been testing). I'm currently building both, which is normally around 40 mins/image for me.
EDIT: I pushed both images here: https://chewitt.libreelec.tv/testing
-
C2 is the most popular AMLGX board. Not huge numbers, but enough that a negative change between releases would show up in forum reports (despite the effort to downplay expectations with AMLGX). If you have media that reliably reproduces a problem with the current LE13 nightlies, I'd appreciate an extract or copy for testing.
-
At devs: Is that normal for Odroid-C2?
Yup, 100% of AMLGX installs show it and it's completely harmless.
To me it looks like a general buffer issue on Odroid-C2:
Nope, there is no such thing as a "general buffer issue" and we're grabbing at straws with that comment.
qazy Please update to the latest LE13 nightly. I haven't touched the LE12 codebase in a while and any investigating and fixing needs to focus on the current codebase I'm poking. I have a hunch the error messages are generated by mesa, but it's probably reporting an issue with the underlying Linux DRM layer (where things like stride and buffers are handled). It may be something related to 'canvas' setup.
-
LE 9.2.8 shipped in July 2021 so it has zero support for the RPi5 hardware released 2+ years later in September 2023, and the change from legacy RPi decoders (OMX, MMAL, etc.) in 9.x to GBM/V4L2 in 10.x onwards means you can't even frankenstein something with the old codebase and newer kernel/firmware (without foregoing all hardware decoding).
-
Since you appear to be too lazy to read the linked wiki section that contains the answer I will post it here for you:
"In short: It was technically possible (but heavily discouraged) to use install2internal with older LibreELEC images. It is NOT POSSIBLE to use install2internal with AMLGX and running the script will either fail, or fail and break boot. To run LibreELEC from eMMC storage please purchase a supported "board" device."
Clear enough?
-
-
Code
Jan 18 15:38:34.552496 LibreELEC kodi.sh[840]: libEGL warning: egl: failed to create dri2 screen Jan 18 15:38:34.562281 LibreELEC kodi.sh[840]: glx: failed to create drisw screen Jan 18 15:38:34.581328 LibreELEC kodi.sh[840]: ERROR: Can not initialize OpenGL context. Exiting Jan 18 15:38:34.581482 LibreELEC kodi.sh[840]: ERROR: Unable to create GUI. ExitingCode
Display More... 2025-01-18 15:38:34.116 T:840 info <general>: ID:0xaa Name:640x480 Refresh:59.940479 Width:640 Height:480 2025-01-18 15:38:34.116 T:840 info <general>: Pixel Ratio: 1.334171 2025-01-18 15:38:34.116 T:840 info <general>: CApplication::CreateGUI - using the x11 windowing system 2025-01-18 15:38:34.116 T:840 info <general>: Checking resolution 16 2025-01-18 15:38:34.116 T:840 debug <general>: Window Manager Name: Fluxbox ... 2025-01-18 15:38:34.547 T:840 info <general>: RetroPlayer[RENDER]: Registering renderer factory for OpenGL 2025-01-18 15:38:34.552 T:840 error <general>: failed to initialize egl 2025-01-18 15:38:34.578 T:840 info <general>: Using visual 0x21 2025-01-18 15:38:34.579 T:840 error <general>: GLX Error: Could not create context 2025-01-18 15:38:34.581 T:840 error <general>: CWinSystemX11::XErrorHandler: BadValue (integer parameter out of range for operation), type:0, serial:87, error_code:2, request_code:150 minor_code:3 2025-01-18 15:38:34.581 T:840 debug <general>: GLX_EXTENSIONS: GLX_ARB_fbconfig_float GLX_ARB_framebuffer_sRGB GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_fbconfig_packed_float GLX_EXT_framebuffer_sRGB GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGIX_visual_select_group 2025-01-18 15:38:34.581 T:840 info <general>: CRenderSystemGL::InitRenderSystem - Version: <none>, Major: 0, Minor: 0 2025-01-18 15:38:34.581 T:840 critical <general>: Can not initialize OpenGL context. Exiting 2025-01-18 15:38:34.581 T:840 critical <general>: CApplication::Create: Unable to init rendering system^ from logs, but I'm not seeing the error/issue. It's a looong time since I poke Xorg stuff though.
Latest image in the share (update from .tar again) has this change per mglae suggestion:
DRIVER=="nouveau", ENV{xorg_driver}="nouveau", TAG+="systemd", ENV{SYSTEMD_WANTS}+="[email protected]"
For kicks, also add video=HDMI-A-1:1920x1080M@60 to kernel boot params in syslinux.cfg
-
You don't need bleeding edge, but it needs to be an RPi5 image.
-
See: https://github.com/emanuel4you/li…ic/dreamone.dts
It should be easy to have someone compile the dtb file from it.
-
If Samba is running (and it is by default) the service is advertised using mDNS via Avahi which helps Linux/macOS devices see the shares, and we also have WSDD2 which broadcasts in the modern format used by Windows.
If you don't need Samba shares turn the service off (10 seconds effort). If you do, configure a user/password credential (30 seconds).
-
I'm not seeing errors or warnings in the Xorg log and if you're seeing a mouse pointer that suggests Xorg is up/running. The Q is then why Kodi isn't rendering the GUI to the windowmanager?
At mglae suggestion I've made another VAAPI change, so please do the following:
a) Download the latest .tar file from my test share to /storage/.update
b) Create /storage/.kodi/userdata/advancedsettings.xml with this content to enable debug logging
XML<?xml version="1.0" encoding="utf-8" ?> <advancedsettings version="1.0"> <!-- enable debug logging --> <loglevel hide="false">1</loglevel> </advancedsettings>c) Reboot to initiate the update, then run "pastekodi" to share the system log and Kodi log.