I think that’s the issue. The container only sees the limited bits of filesystem you expose to it, so doesn’t have permission to walk the filesystem from the symlink to the original file.
Posts by chewitt
-
-
RPi4 or (better) RPi5 are great devices for LE and our go-to recommendation.
-
You probably need to map the folder the app inside the container expects to find the file under, to the folder on the host that the file actually resides in, using appropriate permissions.
-
Different locales/charactersets?
e.g. cmdline.txt and сmdline.txt appear identical but the second starts with the Russian letter 's' (looks like English c)
-
RPi5 will automatically boot when power is applied (cannot be changed to do otherwise) so the remaining challenges (in rough order of priority) will be:
a) Ensuring uses don't shut-down the device. This is easily done with a skin hack to Home.xml, although LE makes that a little more complicated vs. a conventional distro as the default skin files are inside the read-only SYSTEM file. You need to clone the Estuary skin files to /storage/.kodi/add-ons/skin.custom and rename the skin add-on.xml (to avoid name-clash with the embedded one) before editing Home.xml to hide the button.
b) Ensuring the configuration remains consistent. This can be done with an /storage/autostart.sh script which runs early in the boot process to remove the existing /storage/.kodi and replace with a known-good copy: e.g. setup the device, stop Kodi, then clone files from /storage/.kodi to /storage/.kodi-good and then restore /storage/.kodi-good to /storage/.kodi in the script.
c) Ensuring the device always boots to a working LE install. This is mostly about avoiding SD card corruption from uninstended power off events (more about power-cord pulls than unwanted GUI shutdowns). Booting from USB or an NVME drive (needs an NVME HAT) are generally considered to be more reliable than SD.
I'd probably do A only unless I really saw issues that needed B or C.
-
-
RPi5 is designed to power-on when power is applied. The RP1 chip might evolve programmable power-button behaviour over time (there were pre-launch rumours in that direction) but I haven't see it mentioned anywhere since. On RPi4 boards I've seen small circuits combined with the gpio-poweroff overlay to detect a switch state (on/off) and if left in the off position the board boots when power is applied (as that can't be stopped) but gpio-poweroff triggers shutdown almost immediately once firmware loads and applies the overlay.
but sometimes low-tech solutions are best: https://www.amazon.com/Raspberry-Supp…d/dp/B097P2NLVH
-
Have you set the Wireless Regulatory Domain? .. this can help with ensuring country-specific radio properties are aligned with the router capabilities.
-
Large numbers of Kodi users configure things from the command-line, so it's a consequence of that. If you're concerned you can install an SSH key and then disable password access.
-
calmos Are you using 4K60 'certified' cables and a 5V/3A (or better) PSU?. If it can work the config is done correctly on the RPi4, but you need to have an HDMI cable that will support higher bandwidth and a decent PSU.
-
The dbus error is harmless and seen on 100% of LE installs.
-
I got bored in a hotel lobby this morning and pushed a change to LE master to add “tree” to the system-tools addon. If it doesn’t throw any compile issues I’ll backport the change to LE12 too.
-
Random guess .. You are navigating to the files using a video view and trying to open them as video files (and not finding video)
-
-
Use `/storage/.kodi/userdata/addon_data/service.system.docker/config/daemon.json` for the config files.
-
-
What is not the right? it also have a fake android 14.
No clue with these frankensystems. You need to open the box and see what's under the heatsink
-
Create a systemd .mount file; see the example in /storage/.config/system.d/