Posts by chewitt

As a general rule Linux already "does the right thing" by down-clocking CPU/GPU etc. when not active. There isn't really anything specific that you can configure or do to achieve more.

There is nothing to stop someone changing how the OS is packaged to add more users and run apps/services under different creds, but the OS was originally and intentionally designed to keep things super-simple and running under a single user is part of that. The UX design goal is to achieve 99% of tasks in the GUI and thus negate any need to go near the console (which is default disabled) and the fact the entire core of the OS is read-only largely prevents users from causing problems with errant commands. Users can rm -rf their Kodi config but in most cases a simple reboot will regenerate anything essential so the main risk is losing personal media; and users accessing their own media under their own share don't need sudo for that task anyway.

From a security perspective running everything is root is bad (no disputing that) but I've spent the last decade in/around DFIR work for my day-job and I have observed real attackers and red-team staff compromising LE devices and while I have seen devices being accessed (via known passwords) the attacker has ultimately lost interest in the device because either our distro packaging defeats scripts and other attack tooling and/or because attacker Linux knowledge/assumptions are based on the RHEL/Ubuntu derived world and/or because they couldn't ascertain what the device was for and were cautious as a result. Attackers were never able to compromise devices with basic controls deployed; i.e. SSH/SMB disabled and the firewall enabled. I'd also argue that if you are a genuine target of interest to a real actor, the "runs everything as root" LE box in your home network is the least of your worries.

There are known issues with some of the RK devices and resolutions at the moment (there are some threads in the RK section of the forum). I'm not actively following but I believe they are being looked into.

Quote from wedok

LibreELEC-AMLGX.aarch64-12.0.0-wetek-play2.img inside a Minix Neo U1.Set extlinux.conf to: "meson-gxbb-p201.dtb"

No run. Why?

This image is design to boot WP2 boxes from emmc (or SD with emmc erased). It will not boot anything else (as you discovered).

Quote from wedok

One last try ... This time with LibreELEC-AMLGX.aarch64-11.95.1-box.img @ meson-gxbb-p201.dtb

This is the correct image to use with devices with vendor u-boot. The initial boot is successful and then when the device reboots after resizing this sometimes happens; and I have no idea why. All you can do is repeat the install process until it works. You might need to check and repair (fsck) the filesystems on the SD card.

The current LE12 beta should work the same too (as it uses the same kernel).

I've boot tested SD and eMMC installs on a C2 board recently without any issues so

If the 11.0.6 image boots, I'd suggest to use that then update to the current beta (no major changes, but hey.. latest)

If there are still problems I need to see UART boot logs to see where the issue is occurring.

Something from 2018 probably runs fine still (and better than an RPi3B+) so I'd update the Chromebox firmware to current using https://mrchromebox.tech/ and make a clean reinstall with the current LE12 beta to ensure a clean state. If the current version is LE9 we don't support direct update to later releases anyway due to the Python2 > Python3 change that takes place since LE10; the core OS updates fine but add-ons can cause issues that aren't always simple for users to figure out.

echo "sleep 10" > /storage/.config/autostart.sh
reboot

I'm wondering if the issue is related to timing/scheduling during boot. That ^ should force userspace boot to pause itself for 10 secs to allow more time for the kernel to finish loading drivers and settle itself etc. before connection manager and other network setup things run. Does that make any difference? .. share a log afterwards.

Narrowing the LE changes between the two dates (as you did) flags a list of changed packages and (as mglae already commented) the two probable causes are a kernel bump and bluez bump; and of the two both mglae and myself would make an educated guess that bluez is the priority to investigate.

What needs to happen next is "bisecting" the commits/changes between bluez 5.73 (non-working) and previous 5.72 (working) to find the specific commit (or series) that introduces the breaking change. This can then be flagged/reported to upstream maintainers to get a fix, or perhaps someone can see the issue and what's needed and then we can upstream a patch.

Have you ever self-built an LE image? i.e. if you have/can we can coach on how to bisect the changes. If we have to make images for you to test and report back which worked/didn't work it's the same process .. but it'll be a lot slower.

Update to an LE12 nightly or 11.95.1 and run "dmesg | paste" after boot and share the URL so we can see the log. LE12 is still built with "CONFIG_RTL8723BE=m" enabled in the kernel but the image might be missing firmware necessary for the card to work. If yes, that normally shows in the log.

Kodi rounds values in GUI/logs and often reports 23.98 when the actual rate is 23.976. So if you're seeing 23.98 all is fine. If you're truly seeing 23.95 then something is wrong.

If you update to an LE12 image (11.95.1 or a current nightly) with Linux 6.6 kernel it will work as I described. The Linux 6.1 kernel in LE11 images is older and doesn't support the card. LE12 images will work better on an RPi5 anyways.

You need to share the URLs generated by "paste" .. we're not clairvoyant.

** LOGS NEED TO DEMONSTRATE THE WRONG SCAN **

The Linux ecosystem is starting to evolve "DV support" but mostly in the form of workarounds meaning "can play DV media without the colours looking weird" and not true "native" support for DV, which isn't likely to happen due to the Dolby licensing regime being the polar opposite of open-source. TL/DR: the Intel hardware might support DV, but the Linux software stack doesn't.

Looks like you have the LTS board, see: https://github.com/LibreELEC/LibreELEC.tv/pull/7570

"journalctl -b 0 --no-pager | paste" <= gives you the current boot (index 0) and sends to our pastebin site

"journalctl -b 1 --no-pager | paste" <= gives you the previous boot (index 1) and sends to pastebin

increment the index to get the right logs (that exhibit the issue) then share the pastebin URLs

General advice for CEC issues is .. turn everything off and unplug devices. Leave for a while. Connect everything and power back on.

It often makes no sense but has a surprising hit-rate for success