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.
The common mistake with recursive copying is some form of cp -R /oldstorage/.kodi /newstorage/.kodi which results in the old Kodi userdata files being copied to /storage/.kodi/.kodi and since that's the wrong location you still see a clean install on restart.
It also sounds like the clone worked (it booted) so the missing step was editing syslinux.cfg in the boot partition to change default boot mode from 'run' to 'boot'
Hi chewitt Can you please share how to clear / erase the spi flash?
If asked, we would have advised to use the backup and restore functions in the LE settings add-on.
The file plays software decoded on an RPi5, albeit with an abysmal frame-rate (but frames are rendered). Have you done previous tests on the same 1080p display device? - forcing Kodi to downscale 4K prores to 1080p probably doesn't help the cause.
Probably impossible for the thread starter, and needs further explanations.
Most device-tree files are visibly littered with 'status' describing whether something should be 'enabled' or 'disabled' so as long as you have half a clue about includes/dtsi it's 'not rocket science' to disable something in a specific board dts that was enabled in the inherited board family or SoC dtsi.
The WiFi module is part of the RK3566 SoC, so not removable
That is incorrect. The WiFi module is a separate chip (Cypress CYW43455 according to schematics on the Pine64 website) connected to SDIO (WiFi) and serial UART (BT) lines of the SoC but not functionally part of the SoC itself. The module it always is a separate chip package soldered to the main PCB.
It would be easier to disable the SDIO/BT module through device-tree changes (disable the sdio node, disable the BT node) than to physically modify the board by unsoldering chips, although that could also be done if you have the tools/skills.
Mainline u-boot overwrites the 'memory' node in device-tree with what it detected, so 1MB is corrected to 2MB, whereas Amlogic u-boot uses the value described in device-tree, hence all the 1g/2/3g dtb variants you find in vendor kernel sources.
S905X5M SOC not supported yet? I think there is no dtb for it yet.
Amlogic are slowly upstreaming support for newer chips, but emphasis is on 'slowly' so ask me again in 2-3 years.
And it was already LibreELEC with iwd?
Correct.
1. I'll have to ask the upstream kernel maintainers if suspend/resume are supported and expected to work. I won't guarantee it.
2. In theory the kernel should handle the display device going away and coming back. Kodi only checks things at startup though so might not handle things properly even if things lower in the stack do. In either case the workaround will be (or should be) to run the 'getedid' script so the kernel (and thus Kodi) always sees the display device (via it's EDID data) as connected.
3. If you are using official nightlies please try the latest image in my testing share and see if that fixes the issue? - I've added some kernel options to make iptables work but can't remember if that change has made it into official nightlies. I'm also unsure if I added all the options for Docker though.
Seems like your USB drive is broken
That'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:
Switching to the Generic (GBM) image should sidestep the issue with Xorg and leave you with a working system?
Clean install using defaults and the internal Broadcom WiFi card. No Ethernet active so WiFi only on boot.
The single time I’ve seen this error was on a WeTek Play2 box; also using a BCM chip but no power pulling was involved, and it hasn’t been seen again since. The box is only used on WiFi due to lack of free Ethernet cables.
U-Boot SPL 2017.09-ge4e124926e-230922 #lxh (Sep 25 2023 - 10:58:38), fwver: v1.13You have an ancient Rockchip vendor u-boot installed (pre-installed by Radxa) in the SPI flash. Clear/erase the SPI flash and the board will boot from the SD card properly.
You can enable "disable password authentication" in the SSH service settings (in LE settings). Once this has been set there will still be a login prompt, so you can attempt password auth, but no password is accepted.
<KEY_B>runScript(script.audio.profiles,0)<KEY_B> <= two opening tags
<KEY_B>runScript(script.audio.profiles,0)</KEY_B> <= one opening, one closing tagIn the xml snippet you posted, KEY_B has no closing tag ^
But kodi doesn't move the files on the server: I'm confused.
Kodi is dependent on the structure you create, it will not restructure/move/tidy things up for you. So you need a consistent structure and then (via advancedsettings.xml, which you create if it doesn't exist) you map that structure by telling it where the extras folder will be (consistently, if you want consistent results).
If you found some pre-compiled module somewhere on the internet then you are stuck with trying to use a specific kernel version as the 'version magic' must match for the kernel to load the module.
Unless the driver code is shockingly bad: If you're going to compile the out-of-tree module (as you have stated) it can be built against whatever kernel version is latest/used in our buildsystem and you don't need to care about the version.
NB: User attempts to shortcut compiling in our buildsystem "because compiling an image takes ages" with some module compiled outside our buildsystem "because it'll be quicker" usually result in the user expending considerably more time/effort/frustration on the shortcut than just compiling the image in our buildsystem would have taken.
