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?
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. Exiting...
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 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.
The issue has nothing to do with passphrase characters and it's definitely influenced by signal strength. The error message shown is probably the result of an error handling failure in iwd code. Instead of correctly catching the error and failing gracefully with a meaningful message you end up falling-through to a unintended wrong point in code and seeing "invalid key" instead.
The Amlogic S922X chip in DreamBox I/II devices have HDR to SDR conversion capabilties in hardware, but software support for this is not currently implemented in the upstream Linux kernel used with the AMLGX image.
Kodi supports forced tonemapping in Windows and Android devices should support it subject to underlying hardware support. The Shield does handle conversion. Linux support for colorimetry changes in upstream kernels is currently rather limited. CE images that use Amlogic vendor kernels should support conversion, but CE is someone else's problem (we don't track their releases or state) so you need to visit their forum for info.
The image I posted to my share yesterday morning addresses udev and adds VAAPI support .. I'd already spotted those 
I've squashed/pushed the current changes to https://github.com/chewitt/LibreELEC.tv/commits/nouveau
I was using a GBM based LE master OVA under ESXi over Christmas to poke ideas for tailscale support. ESXi != Workstation/Fusion but no issues seen, so if we broke something it's either a very recent change or something specific to Workstation.
Nothing was breached. LE intentionally ships with Samba enabled to mitigate support issues with typically low/no Linux skilled users and the default shares expose /storage/.kodi/userdata where Kodi subsequently stores passwords in cleartext. You can either disable Samba in the LE settings add-on (as you didn't choose to disable it when prompted during the first-run wizard) or you can configure a credential so there is no open access to the Samba shares.
NB: I'll take an action to formally document our insecurities in the wiki alongside installation instructions. They are widely discussed in the forum for anyone searching for info, but not the wiki.
I wouldn't expect any real-world differences between releases as nothing on the kernel side has really changed (nobody did any real work on the decoders since 2020). That said, Kodi and ffmpeg versions changed so it's not impossible. Seeking is generally okay on H264 in my testing, but the decoders are all known to be imperfect, and there are some unresolved memory buffer management issues that when provoked with lots of stop/start/seek activity will leave the decoder driver in a bad state, although I've not see any Kodi crash/restarts from them.
The sole real-world decoding change is https://github.com/chewitt/linux/…aa21f07ee54d028
I am surprised about the [DEPEND] Dependency failed for windowmanager.service I have seen one time. I did not expect gbm needs an X-server and the X-server needs a window manager (or maybe a display manager?).
I also should expect Kodi should be compiled against gl instead of gles.
The first image I shared was GBM based but after having suspicions on GLES support I switched to X11/GL, and we use fluxbox as a minimal window manager (Xorg requires there to be one).
If you stop xorg.service and manually run /usr/bin/xorg-launch -nolisten tcp vt01 -logverbose 6 -verbose 6 what output do you get on the console?
You can create /storage/.config/udev.rules.d/98-eventlircd.rules with the changes and reboot, or update to the nightly. I wouldn't worry about stability with LE12 nightlies as we don't bump much in release branches. Most changes are for add-ons.
Disabling WiFi isn't going to help with the 2.4GHz device when USB 3.0 is the source of issues.
If the media is 1080p it's unlikely to be an HDMI bandwidth issue unless you're using a particularly rubbish cable. However, 1080p content is normally 8-bit not 10-bit which suggests media has been intentionally encoded that way, which opens the door to people using exotic encoding configs, e.g. in the past the Animé scene used 10-bit H264 which often caused issues. So plan B might be to rerip the media using Handbrake default HEVC settings.
Honestly, no clue.
