Posts by chewitt

    At the boot menu .. hit a key on the keyboard (connect a USB one if needed) and type the command "live" or "run" then hit enter. If you do nothing it defaults to "install" but this requires you to select and confirm the target USB/HDD device to install LE to. Install repartitions and formats the target device exclusively for LE use (no installing to a partition like some Generic distros do).

    The main challenge will be booting the device without an SD card slot and no UART cable to show you what's actually happening in the early stages of boot when you need to trick the device into booting Linux not Android. In practice; that'll be damn complicated and I'll say "no, not possible" simply to avoid the 500 hours of blind guesswork required.

    You're over-thinking the problem. Just buy the 65"+ 4K TV that makes sense for your future 4K viewing needs and budget. In 99% of 4K setups Kodi is still running the GUI at 1080p and only switches to 4K when playing 4K media so it's basically the same experience you have today except for the minor size difference between a 58" and 65" panel. The TV will still handle upscaling from 1080p to the true native 4K resolution of the panel, but it's still basically playing the same SD media at the same 1080p. In theory the 1080p pixel blocks render bigger on a 65" vs 58" so it should look worse, but since colour technology advanced by a mile since ye olden days of Plasma screens so you won't notice that; you'll only notice the colours are wildly better.

    NFS has a reputation for being "lighter" which is great for low-bandwidth crap WiFi but SMB is often more resilient with dropouts and other forms of crap WiFi. There's no universal answer as WiFi is inherently a bit crap, and RPi4 WiFi is at the low-expectations end of on-board WiFi implementations so it's best to experiment and see what works best (or least-worst) for you.

    If everything works briliant when you run an Ethernet cable you can join me (and the rest of staff) finger-pointing the WiFi connection :)

    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.