Posts by chewitt

  • Odroid XU4 can't boot LE12/13.

    @Yasai-san I've submitted PR's to update the patch we use for the XU4 defconfig in LE13 (2025.04) and LE12 (2024.01). I've not boot tested either defconfig but the problem and fix are obvious (hopefully). The LE12 change can be cherry-picked for Lakka to resolve the issue for Lakka v6.x too.

    Thanks for the report and the detective work. I guess it slipped through the net as a) few people use the XU4 image with LE these days, and b) the few that do use the XU4 image probably first-installed an older release with working u-boot and then updated to newer OS versions over time, and updates don't touch the u-boot version.

    EDIT: I've not seen your patch until after I've submitted the PR's to our repo. It's better to regenerate the whole patch against the upstream u-boot source as u-boot make periodic "resync" changes that change/move items around in the file. This time I also made some cosmetic changes to the XU3 defconfig too; the idea being that future resync changes might cause the XU3 patch hunks to break and thus flag the need for the patch to be updated again (although it's a long-shot).

  • [x86-64] [LE 12.0.2] Skin's settings reset after exit...

    I won't be suprised if there's a bug in profiles as it's a neglected/unloved and not well maintained part of Kodi's vast codebase. It is known to be imperfect and need work, but until someone volunteers themselves for the task that's how it remains. It's best you post the bug report in Kodi forums as it won't be an LE specific issue and it's not something LE can fix.

  • "LibreELEC-RPi5.aarch64-13.0-nightly-20250427-34e4c98" seems to have a "bug"?

    Please (re)post the PVR issue in the Kodi forum. Provide English text (Deepl) and the original German text to ensure the context is correctly understood (the main developer who needs to read it is German).

    Kodi has some changes for speaker placement markings. The presentation will probably correct itself over the next couple of weeks as the bugs are ironed out. Ignore that when posting in the Kodi forum - focus on the main issue.

  • Don't reject "weak" passwords during setup

    Quote from VLouis

    These machines usually are connected to internet

    That's not correct. Most machines are in a home LAN behind a NAT router so unless the user explicitly port-fortwards or configures a VPN which results in the device having a secondary (external) IP address they are not exposed. Only a tiny percentage of our active userbase have devices exposed. I periodically check shodan scan results and the number of exposed systems is small, stable, and has been slowly declining over time.

  • [RPi5] WiFi Problem

    Devices need to use passwords when connecting and/or reauthenticating to the network. This happens in normal use. It happens a lot more frequently when signal/connectivity is poor; and RPi boards generally have poor(er) connectivity before we place them into cases that reduce it further. So the short answer is "nobody knows" (could be any and all of the items you've listed) but if the issues reduce when moving boxes closer to the router, it's probably the normal issues seen with RPi boards, and the solution(s) are moving things closer, using an external wifi dongle with better connectivity, using ethernet instead of wifi, etc. etc.

  • [x86-64] Random Crashing

    EXT4 is considered reliable and Ubuntu defaults will have formatted the drives appropriately for normal use like LE, and while Kodi crashes can corrupt files in the filesystem, esp. databases which Kodi is responsible for managing, they should not cause corruption to the filesystem itself. This means filesystem errors in the system log are more likely to be the result of power issues, i.e. sudden power loss, or issues with the physical disk media.

    If you are lucky it's minor corruption and running fsck against unmounted drives will fix things. If you're less lucky the physical drives are okay but the filesystem is properly messed up and needs a total rebuild. If you're properly unlucky there's physical media damage to the drives. These days physical media damage is rare unless some form of physical shock is also involved, but it's not completely impossible. Failures also follow a bell curve: if the drive is going to fail it's more likely to be when the drive is still very new, or years later when it's very old. Failure rates often correlate to the manufacturing batch of the drives too, so the ideal scenario when purchasing a set of disks is to acquire disks from a variety of different batches not all drives from the same batch.

    The only way to find out is trying to fsck, or trying to reformat and rebuild. Beware that if formatting, the default quick format done by most tools may not find physical media issues. That kind of thing is normally only found by trying to 'zero' the drive by writing to all sectors (also rather long and boring).

  • Transfer log to server systemd-journald-remote

    Quote from Mayoru

    What should I consider? How should I configure it?

    The need is somewhat moot because LE runs the core OS from a virtual filesystem in RAM on all boards with 1GB+ RAM so writing data to the journal is not writing constantly to the SD card like a standard Linux distro.

    To configure systemd-journald-remote you'll first need to compile a custom LE image that builds systemd with journald-remote support, and copy the required binaries and service files into the image, as we don't currently do that.

    The easier option will be to install the rsyslog add-on from the LE repo and use that to send logs to the NAS. I've never personally played around with it, but it exists and last time we broke it people complained. On that basis I assume it's used and working; else we'd be complained to again.