Posts by chewitt

    If the box boots to the kernel a drive in an "unclean" state will be detected and automatically fsck'd. If the drive doesn't get that far, the issue resides in upstream u-boot; which likely follows the Linux "stop in case you break something" approach rather than the vendor u-boot) "run

    vendor code to fix things" approach. I'm not sure there's much to be done here, but the workaround would be to install HD vendor u-boot on the SD/eMMC and then boot LE using the "box" image instead of the "board" image. Then you have the benefits of very poorly written vendor code "fixing" your broken filesystem at the u-boot stage and it might continue booting.

    I used to live in a house with frequent power cuts and no amount of software workarounds ever beat running essentials (things that you don't want to constantly fix or risk breaking) from a small UPS.

    If the LE installer completed and system booted and on reboot the issue presents; the installer is not the issue.

    Ensure things like "Secure Boot" are disabled in BIOS, we don't support that. `If the bootloader is the issue (which we don't know) you could boot from an Ubuntu LiveUSB/CD image and install grub2 as a bootloader (overwriting the default syslinux). This will then need some boot config to be defined but there are lots of examples on the internet.

    If it's not the bootloader, eliminate the SSD by updating the drive firmware (should be possible with most branded drives; might need a Win box to do the update from). Installing/booting LE from USB (run mode) then attempt writing to the entire drive with "dd if=/dev/zero of=/dev/ssd-device bs=1m" will prove the device can write to all cells. If it throws errors in dmesg .. send it back.

    If it's none of the above .. /shrug

    Kodi uses it's internal sqlite DB or an external MySQL/MariaDB database, and those have a fixed schema that users don't just get to change ad-hoc (Kodi code needs to change). So I don't really understand what you mean about adding links to an external DB?

    RPi will be a little different from Amlogic (as the codebase is different) but improvements in performance will still be incremental not a huge leap forwards. LE12 will run all 64-bit ARM hardware with 64-bit userspace; including all binary add-ons available at the time. And nightlies are only built when there are new changes to build, and only uploaded if the build is successful, and when the server didn't fill it's disks again (none are guaranteed).

    If the device booted as far as it did, the app that was used to create the SD card is irrelevant because the bootloader on the SD card booted and found KERNEL which runs the init script that then failed to find the SYSTEM file in the same boot partition that KERNEL resides in; ergo the partitioning itself is not the issue. The problem resides in the kernel .. and it's usually something related to mmc support.

    RK3588 boards will be supported when upstream kernel support catches up with our requirements. Lots of the core bits already work (enough for a desktop OS) but "all the media stuff" that an LE image usually takes a while longer.

    The connman/iwd changes are already merged into LE11 branch. NB: I'm not sure what advantage you're expecting with aarch64, but it's not going to noticeably improve anything and you will have to reinstall or remove binary add-ons) as they are not aarch64 compatible; and there will be no replacement binary add-ons in the repo as there are no ARM aarch64 releases for LE11 so the add-ons weren't built/don't exist.

    The kernel patchset is ridiculously large but will reduce if I ever find the enthusiasm to rebase it on a newer kernel. I have no plans to do that in the near-term future though.

    The primary difference between Windows/Linux filesystems is that when problems arise Windows tries at all costs to keep things running and eventually just fails resulting in loss of access to data, while Linux fails at the first opportunity to avoid further problems, usually resulting in data being recoverable/moveable before you reach a complete loss. The difference often results in "but, but, it worked under Windows" type forum posts which are both correct and completely missing the point that Linux is doing the right thing.

    The best upgrade would be to a recent-ish Intel motherboard with integrated graphics, as those are going to support HEVC + 4K and most of the recent ones do HDR too (although HDR support is still work-in-progress in Kodi). I can't advise anything specific though as I didn't run an Intel CPU device for LE/OE use in the last decade (only ARM boards) and Intel breeds "lake" codenamed chips faster than I can keep tabs on the damn things.