One question, is there any way to confirm via the logs that that a machine is not running generic_legacy?
In Kodi you can check if X11 is mentioned in Settings -> System Information -> Video.
From console do cat /etc/os-release.
One question, is there any way to confirm via the logs that that a machine is not running generic_legacy?
In Kodi you can check if X11 is mentioned in Settings -> System Information -> Video.
From console do cat /etc/os-release.
The CN60 is using the crocus DRI driver:
[ 16.712] (II) intel(0): [DRI2] DRI driver: crocus
[ 20.046] (II) AIGLX: Loaded and initialized crocus
Having the choice of disabling ASPM or AER I would ever choose ASPM because this is more likely the cause of the error.
ath9k seem still being blacklisted, is it failing with kernel 6.17 too?
emveepee i965 is the vaapi driver. For intel iHD of "media-driver" package or i965 of "mesa" is used.
The i915 driver mentioned is the intel graphics kernel driver name. LE "xorg-xonfigure" package use the kernel name to choose a X11 config file if required.
Now to the confusion:
The current intel mesa Gallium3D drivers since 21.1 are named i915 (!), crocus and iris. They are chosen according to the GPU, a paste /var/log/Xorg.0.log will show the one used.
Old mesa legacy driver are named i915 (again) and i965 (but not the vaapi driver). They are still available in the mesa-amber branch, the i915 may be named i915g too.
:-(((((
Edit:
PS: is the pci=noaer still required?
Mesa 4.2 disabled DRI2 by default and Mesa 5.2 removed it completely. We had to force DRI3 for intel driver in LE13 development () and there seem to be no issues but your GPU is likely not supported.
I'm interested in /var/log/Xorg.0.log for the error case (and we should include it to pastekodi). Please cp /var/log/Xorg.0.log ~ in error case and paste it when having network.
You can try the "modesetting" driver:
and change Driver "intel" to Driver "modesetting"
Please test if the aspm parameter of post #23 does improve your wifi experience.
There is no KEY_B in Lircmap.xml of kodi.
but I'm wondering if x86_64 is somehow different ..
ASPM was an issue over years e.g for the realtek r8169 driver.
and adding the config pcie_aspm=off
If disabling ASPM is not working another parameter to try is pci=noaer.
my setting was 10s seconds
The 10 seconds default is known to be optimistic, in ideal case DHCP take ~6 sec. If e.g. the router does not react on DHCP_REQUESTED_IP option there is an additional 15 sec delay.
Job wait time-sync.servce/start running
I'm wondering if changing the TTYPath= from /dev/console to /dev/tty1 in journald.conf of Generic will improve the debug console user experience...
The job running indicates there is no network connection (as you assumed). Temporary work around may be using ethernet but commands can be typed blind even with this message..
Without network you can store pastekodi output locally with pastekodi -c >log.file and upload it later with paste log.file
With adding systemd.debug_shell parameter to the APPEND line you do get a debug shell on console 3. Press <Ctrl><Alt><F3> to select it. Switch back to X or default console with <Ctrl><Alt><F1>. The debug console is accessible too when booting the USB install stick into installer.
For testing multiple boot configurations can be used in syslinux. cfg. Replace the PROMPT 0 line with e.g. (using your UUIDs):
and you can select textmode at boot with typing txt
GBM connector can be forced via advancedsettings.xml.
First ssh in and use kmsprint to get the connected connector name of the screen.
Create advancedsettings.xml (replace "Virtual-1" with your connector name):
<advancedsettings version="1.0">
<!-- Debug Logging -->
<loglevel hide="false">1</loglevel>
<!-- No monitor selection on GBM but connector can be forced: -->
<videoscreen>
<monitor>Virtual-1</monitor>
</videoscreen>
</advancedsettings>
Display More
Debug logging is enabled to ease the setup.
Perform systemctl restart kodi to test the configuration.
The log only show a crash of the LE-Settings log uploader. ![]()
To work around the issue please enable (and test) ssh access first. After the original crash log in via ssh and use the pastecrash command.
Patch is accepted upstream in inputstream.ffmpegdirect. I've created a LE13 PR.
Can be the reason, the kodi CURL constructor is called but then inputstream.ffmpegdirectCURL::Parse() used.
This patch does fix the issue in my tests. Will try to create a PR tomorrow.
It is crashing in inputstream.ffmpegdirect calling CURL. But ![]()
You can increase crash log verbosity with touch /storage/.config/debug.enhanced from ssh. This may or may not show information.
Did you attach the power supply to the stick?
Do I have to delay kodi startup for update to fetch release information after network is up and ntp sets up clock?
In any case increase the max. network wait time in LibreELEC-Settings -> Network to e.g.45 sec.
There is no fix in kodi yet therefore nothing that can be updated.
Find all addons using <reuselanguageinvoker>: