The CN60 is using the crocus DRI driver:
[ 16.712] (II) intel(0): [DRI2] DRI driver: crocus
[ 20.046] (II) AIGLX: Loaded and initialized crocusHaving 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?
I thought you recommend pci=noaer changed back to pcie_aspm=off
Here is the log with the blacklist removed and toggled wifi on to see it working https://paste.libreelec.tv/driven-polliwog.log
All is good.
Display MoreThat's no the problem, because of how LE is packaged. To explain:
In a conventional distro there are many thousands of files stored on disk with each file occupying at least one sector and some occupying many sectors. Bad sectors thus impact only a small number of files and if those are non-critical files you might throw some odd errors but the system keeps running until you do finally lose something important.
LE is packaged as two compressed read-only files (KERNEL and SYSTEM) which are expanded into a virtual root filesystem on boot, with persistent storage (containing largely non-critical data) in /storage. If you have a bad sector impacting either KERNEL or SYSTEM their decompression fails fatally and the OS does not boot.
Thus if the system boots, some odd USB errors from the boot drive were not fatal and the OS (in its entirety) is running.
The log shows USB device 1-3 being mounted as /dev/sda without any issues. This is the boot device.
The log shows USB device 1-4 throwing usb 1-4: string descriptor 0 read error: -22 but this is not the boot device.
The log also shows Xorg failing to start an i915 (Intel GPU) card due to lack of DRI2 or DRI3.
I would do the following:
- Run "systemctl stop kodi" to stop the Xorg boot loop.
- Move /storage/.kodi to /storage/.kodi-old to sidestep possible add-on issues
- Use "connmanctl" to connect to WiFi and the Internet if needed (looks to have a stored config so prob. not needed)
- Download (wget) the latest nightly 'Generic' (not Generic-Legacy) image to /storage/.update
- Reboot to update
Switching to the Generic (GBM) image should sidestep the issue with Xorg and leave you with a working system?
Ah that explains the why 12.0.2 didn't choke on the USB storage error.
Thanks, I will try this.
One question, is there any way to confirm via the logs that that a machine is not running generic_legacy? I want to double-check my memory before attempting to update.
I'm looking at the logs from my OTHER box that is running genreic_legacy, and the only hit I have on the word "legacy" is a name resolution error:
2025-10-27 14:06:36.447 T:972 error <general>: SETTINGS: load_url # Error loading url: https://update.libreelec.tv/updates.php?i=6c062aee00a7e558a44043d16277f4e3&d=LibreELEC&pa=Generic-legacy.x86_64&v=12.0.2&f=i915 Reason: [Errno -3] Temporary failure in name resolution
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.
In Kodi you can check if X11 is mentioned in Settings -> System Information -> Video.
From console do cat /etc/os-release.
Well, it looks like a mea-culpa is in order, that's reporting:
LIBREELEC_ARCH="Generic-legacy.X86_64"
I had not recalled having installed legacy on this particular box. That having been said, I am now unsure why 12.2 showed as available for upgrade in the LibreElec settings page on this box, yet it does not for my other Generic-legacy box that's currently on 12.0.2?
I am assuming that the 12.2 version that was presented as an upgrade was the legacy version... is there any way to tell what was applied?
is there any way to tell what was applied?
If the system boots /etc/os-release will tell you what is running. If the system does not boot you can compare the md5 hashes of the KERNEL and SYSTEM files in the boot partition with hashes of files in the released Generic and Generic-Legacy images to see which ones match.
Having the choice of disabling ASPM or AER I would ever choose ASPM because this is more likely the cause of the error.
I updated to the latest Matt Devo firmware and it turns out I don't need either setting https://paste.libreelec.tv/master-antelope.log
Display MoreThat's no the problem, because of how LE is packaged. To explain:
In a conventional distro there are many thousands of files stored on disk with each file occupying at least one sector and some occupying many sectors. Bad sectors thus impact only a small number of files and if those are non-critical files you might throw some odd errors but the system keeps running until you do finally lose something important.
LE is packaged as two compressed read-only files (KERNEL and SYSTEM) which are expanded into a virtual root filesystem on boot, with persistent storage (containing largely non-critical data) in /storage. If you have a bad sector impacting either KERNEL or SYSTEM their decompression fails fatally and the OS does not boot.
Thus if the system boots, some odd USB errors from the boot drive were not fatal and the OS (in its entirety) is running.
The log shows USB device 1-3 being mounted as /dev/sda without any issues. This is the boot device.
The log shows USB device 1-4 throwing usb 1-4: string descriptor 0 read error: -22 but this is not the boot device.
The log also shows Xorg failing to start an i915 (Intel GPU) card due to lack of DRI2 or DRI3.
I would do the following:
- Run "systemctl stop kodi" to stop the Xorg boot loop.
- Move /storage/.kodi to /storage/.kodi-old to sidestep possible add-on issues
- Use "connmanctl" to connect to WiFi and the Internet if needed (looks to have a stored config so prob. not needed)
- Download (wget) the latest nightly 'Generic' (not Generic-Legacy) image to /storage/.update
- Reboot to update
Switching to the Generic (GBM) image should sidestep the issue with Xorg and leave you with a working system?
Did this, and it's booted into the installer wizard, (as did booting with the USB with the 12.2 nightly build).
So it seems like this doesn't recognize the previous install to upgrade, and is installing fresh.
If I copy back from /storage/.kodi-old to /storage/.kodi, would it restore my previous config?
Are you talking about the OS configuration wizard in the Kodi GUI (system name, wifi, services, etc.) or the installer wizard used for selecting a target disk to install the OS to?
If the former, this is good and the box is booting okay and you have a clean Kodi environment (as /storage/.kodi was renamed out of the way). This was intentional to ensure there is no conflicts with add-ons compiled for Xorg not GBM. You can restore the previous config by stopping Kodi and swapping the folders around again; or if there are any issues, by stopping Kodi and moving specific bits of config back again (add-on settings, sources, passwords, etc.). Binary add-ons like screensavers/visualisers compiled for the Generic Legacy (Xorg) image are not compatible with the Generic (GBM) image so I would normally suggest the partial restore option, or swap folders back but deliberately nuke /storage/.kodi/addons/* then reinstall add-ons.
If the latter, no idea what's going on..
