Posts by chewitt

popcornmix ^

Once the filesystem is unmounted you should be able to run fsck against it. From personal experience if you then cannot access the drive, it's usually because the drive has major problems (and it's time for a new drive). How many hours on it?

Using a cached EDID file might solve the first problem, it won't be part of the second. If you Google remote wake issues you'll find articles on setting USB devices as wake devices, and that might not be happening, in which case you can concoct a systemd service that runs when the box is suspended .. allowing you to wake again.

2023-02-12 14:55:34.538 T:3226    ERROR <general>: SQL: [MyVideos119.db] SQLite error SQLITE_CORRUPT (database disk image is malformed)

You'll need to delete the MyVideos119.db file and Kodi will boot again. If there's an older file it will be migrated and you can re-scrape the content added since. If that was the only MyVideos DB file you'll need to re-scrape from the start.

There are a couple of Meson8b (S805) device-trees. See what works most.

If the WiFi is still not working you need to connect Ethernet or do the textmode change I described before to get the boot log so we can see whether the device probes or not, or if firmware is missing, or something else.

If you enable persistent logging in the settings add-on there is a log-file on disk to copy. Otherwise logs are not persisted between boots and you'll need to access the box whilst running to get the log (hence previous advice).

Post review for new users stops LOTS of spam and forum abuse and the 1% of users with greatest experience and highest probability of replying all have mod rights and can see your posts, so in the real-world it's a perception problem not a real problem.

The error message is irrelevant.

There are some additional fixes for rtw88 merged yesterday in https://github.com/LibreELEC/LibreELEC.tv/pull/7496 so update to last nights nightly or be patient and wait 24h for tonight's and it might be resolved.

Try the latest nightly (not stable) as some fixes for AMD GPUs were merged a couple of days ago.

If you add "textmode" to kernel boot params in syslinux.cfg the box will boot to a local text console (not Kodi) allowing you to poke around with a USB keyboard attached to investigate the WiFi problem. To diagnose anything we'll need to know what the WiFi chipset is, and see the system boot log (dmesg).

Layer 8 networking issues are the hardest to solve

There's only one upstream developer working on Meson8 support (Martin B) and he has a busy day job so output comes and goes depending on when he has some free time (and enthusiasm). I rebased the pre-pre-Alpha AMLMX image on LE master and Martin's latest kernel branch one month ago and built this image:

https://chewitt.libreelec.tv/testing/LibreELEC-AMLMX.arm-10.88.0-box.img.gz

It's been boot tested by a couple of people but might need some manual finessing of the u-boot environment to get it booting - I one have one Meson8 box (and one board) and vendor u-boot from 2013 is an archaeology experience, so the scripts used to hook and boot into LE aren't finalised.

You are welcome to report bugs (there will be some) but this is completely unsupported

Quote from michale32086

Where is this Key-Only Auth setting you speak of??

In the LE settings add-on, next to the SSH enable on/off .. and users occasionally get enthusiastic and flick everything on, which means they enabled key-only authentication (after which, passwords are unsurprisingly no longer accepted).

dtb_name=/dtb/meson-gxl-s905d-sml5442tw.dtb
bootargs=boot=LABEL=LIBREELEC disk=LABEL=STORAGE quiet systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0

^ Modify the bootargs line in uEnv.ini to look like ^ this with everything on one line (beware, the forum wraps lines). Working?

Kodi only detects output config at startup so if you connect to the TV after boot it didn't receive necessary info. You can run "getedid create" to cache/force the EDID data from the HDMI connection, then the box will never see HDMI state changes that might be upsetting things.

There's not much we can do locally if suspend/wake doesn't work; it's all about the upstream kernel and what that inherently supports on your device. The challenge with mac mini's has always been that there's no BIOS that power states can be tweaked from, and no upstream kernel developers are using decade-old Apple hardware to validate Linux support so regressions can creep in over time (or things never worked in the first place). Your best bet is generall Googling .. if there's a patch we can add or a missing kernel module to enable; we can probably do that, but nobody on the team has old mac kit for testing so we're shooting blind on the problem. You can also report the issue to upstream kernel maintainers and see what they suggest. If you do, feel free to cc me (chewitt@ the LE domain). The power-management and ACPI mailing lists are probably the ones to target for Qs:

Linux power management - Patchwork

Linux ACPI - Patchwork

You need to replace /path/to/share with the path to your media share or maybe even just / (the root of the filesystem) and then it will crawl the entire box. The find command will run recurrsively so it's the easier one to use.

I'm happily connecting from Win11 (using the native support not PuTTY) and macOS to a range of LE devices using SSH, and if it didn't work for everyone there'd be a wave of forum posts complaining about it. So whatever the issue is, I'm confident it's local to your environment.

Make sure you didn't enable key-only auth. It doesn't stop SSH prompting for passwords. It does stop passwords from being accepted.

In the Rock Pi 4 A/B+ (the plus is important) there is a change on the boad that requires different u-boot. I'm not sure if the C follows the same change. There will be a new image for Rock Pi A/B+ added to the next beta so perhaps try that when it ships (soon).

The GUI shows Hardware/Revision/Serial here. It's a custom image I make for myself and not the official beta, but I'm not patching anything that would affect this. The info in /proc/cpuinfo is not the same on 64-bit kernels as 32-bit, but that's a general Linux thing.

I was thinking you were wanting to add tuners to the install. If you already did that and the tuners work fine under LE10 (not sure what kernel but it's upstream) I would expect them to continue working fine under LE11.