Keep in mind that libreelec use U-Boot mainline (not the legacy one with proprietary blobs that maybe librecompurer folks suggests)
LibreComputer are upstream champions so I would expect their boards to work correctly. Their lead (Da Xue) is normally reachable in Slack in East Coast US hours to check things.
I'd guess they broke support for detecting LibreELEC as the add-on is trying to "apt-get" packages in the background, i.e. thinks it's running on a Debian based distro like Ubuntu, and that doesn't work on LE. You need to post the issue on their GitHub issue tracker.
Seems that it has ARM A53 CPU so I think it is a SOC S905 and that I could use the LibreELEC-AMLGX.arm-11.0.3-box image to root it.
If you scroll down the page far enough it shows "CPU: Hisilicon Quad-core" which means it's not Amlogic and we currently have zero support for any HiSilicon chips (all their chips require horrid vendor kernels, nothing upstream).
LE has no current support for 32-bit (ARMv7) boards of any kind, and that's unlikely to change.
New wiki article to cover this topic: https://wiki.libreelec.tv/configuration/ssl-tls-certificates
All you need to do is put your own certs in /storage/.config/cacert.pem and reboot. On restart ssl-config.service appends that content to the default cacert.pem file when creating /run/libreelec/cacert.pem which is the symlink target for /etc/ssl/cacert.pem.
If you edit syslinux.cfg (cmdline.txt is a Pi only thing) add "ssh" to kernel boot params (on the same line) and reboot. This forces the SSH daemon to be started and you can access the box to run "jouranlctl | paste" and share the URL generated.
I'd also try a current LE12 nightly https://test.libreelec.tv/12.0/Generic/Generic/ in case newer kernel/drivers magically fixes something.
Creating an installer USB with dd doesn't cause any issues.
Odd to see that kind of thing from a new SD card (unless it was bad before you started; but then writing the card would likely fail). I'd suggest trying to run any other OS on the same (new) SD card to prove the Pi board is fine.
Random guess: The laptop has an nVidia chipset and you're not using the Generic Legacy image?
It's not the default behaviour but you can drop a udev rule in /storage/.config/udev.rules.d that matches against the partition IDs or drive names and if triggered, runs a bash script to check if the drives have errors, and if yes run fsck against them.
I think this one is a better template to follow, but with the cmd data and sequences from the MediaTek driver (which won't work as it's based on a BSP kernel source): https://github.com/torvalds/linux…-tv101wum-nl6.c
Nov 16 22:05:14 LibreELEC dcb104c3506c[1344]: [Info] SonarrBootstrapper: Starting Web Server ^ Users running Sonarr are probably running other apps to download of content from torrent networks. Running piracy crapware on your LE install will a) result in no support in this forum (you can run what you like, but we don't support pirates) and b) it's almostly certainly the cause of your "system degrades to the point where it's unusable" problem. Just look at all the errors being spewed into the journal.
Solution A: Remove the background crapware and run the OS as it was intended and it won't degrade
Solution B: Run another distro and become someone else's problem
If you're not a pirate and want support to continue: prove it with clean logs and configuration examples.
Hopefully it makes it one day to the official LibreELEC builds..
Never unless xhbl submits the feature changes upstream to Kodi. LE will patch Kodi for basic config and backport fixes, and in a couple of places where kernel UAPIs are still being defined (and thus Kodi cannot implement a standard yet) but we aren't interested in hacking major feature changes in - as our intent is to follow the upstream source as closely as possible.
I'd guess the USB drive is presented to the OS as a hard disk and not a removable storage device (flash stick). The creator app is hardcoded to hide hard drives to stop users overwriting something important. Perhaps try other apps like Win32DiskImager or Etcher?
jernej does Allwinner have an "internal PHY" option similar to Amlogic? .. or only external?
_emanuel_ I picked the MIPI-DSI patches currently on the mailing list to https://github.com/chewitt/linux/commits/amlogic-6.7.y so use that branch for device-tree experiments. AFAIK the kernel does not support output on MIPI and HDMI at the same time currently, but the folks working on the MNT Reform laptop + BananaPi CM4 (A311D) module should investigate that. So focus on getting normal output on the LCD working first. NB: The two patches I didn't pick to my branch (which are important for prior-art) are:
[v8,11/12] DONOTMERGE: arm64: meson: khadas-vim3l: add DSI panel - Patchwork
The Khadas TS050 driver is already upstream in the kernel (hence the compatible can be used). Same for the Innolinux LCD used in the Reform laptop. You might end up needing to author a driver for the LCD panel; I'm not sure what part is used in the DB2?
EDIT: found some more useful stuff:
Share photo's of the PCB (both sides)
