Thanks for the log, I see mmc diagnostic errors in there but unfortunately the beginning of the log is missing.
Can you please add log_buf_len=4M to the end of cmdline.txt (everything must be on a single line, so add that just with a space separated from "quiet") and repeat that check?
so long,
Hias
Thanks for checking, this is already useful information!
You are going to need to create a bug report on https://github.com/raspberrypi/linux/issues but before you do that it's best to double check, take notes of the exact steps and run an additional test with LibreELEC to collect some more info:
Do a clean installation of LibreELEC 11.0.0 and grab a FAT formatted USB pendrive or harddisk (size doesn't matter, just that it's formatted with FAT so we can write boot logs to it).
Boot up your RPi3 with just the LE sdcard, the USB pendrive, keyboard and monitor connected.
When you get the "cannot mount" message run the following commands to mount your pendrive and save kernel log:
mount /dev/sda1 /storage
dmesg > /storage/dmesg.txt
umount /storage
poweroffIf you get some errors from these commands please post them here (or just take a picture with a camera). If everything worked you should have a file "dmesg.txt" on your pendrive. Please attach it here, then I'll have a glance through it if I can spot anything.
Please also verify the steps you did to test with RPiOS - best do them again to double check:
1. A clean installation of the current "Bullseye" RPiOS (2023-02-21-raspios-bullseye-armhf-lite.img.xz) doesn't boot. You should see some error messages on the screen, please take a picture of them with a camera
2. A clean installation of the legacy "Buster" RPiOS (2023-02-21-raspios-buster-armhf-lite.img.xz) boots fine.
3. running "sudo rpi-update 39821d33e777cde9ba1a3cc8a73cfdd62fbbd2de" "sudo reboot" works fine and "uname -a" show it's running kernel 5.10.95-v7+
4. running "sudo rpi-update 9c6362635308cb3034d22f42daf9bfda1e3d36de" "sudo reboot" results in a non-working boot - a picture of the error messages on the screen would again help.
so long,
Hias
I think it would be best to start with an RPiOS buster/legacy lite image (using kernel 5.10) from here, that should boot fine
Then use rpi-update to update to newer firmware/kernel versions. You can run "rpi-update GITHASH_OF_RPPI_FIRMWARE_RELEASE" to update to a specific firmware/kernel version.
Take the githashes from here:
You may want to start with rather old versions, eg the latest 5.10 version (go back several pages on the github page) which would be the 5.10.95 kernel from Feb 2 2022 with githash 39821d33e777cde9ba1a3cc8a73cfdd62fbbd2de - so run "rpi-update 39821d33e777cde9ba1a3cc8a73cfdd62fbbd2de"
If that works, check with the next newest version which switched to kernel 5.15 on Feb 4th.
If that works, too, go forward in time eg a month each until it stops booting, then reinstall from scratch and try with a version between the last working and the broken one. Repeat that until you narrowed it down to version X working and next one broken - that information will help RPi devs (and also us) a lot since it's usually a small set of changes which we'll have to look into (unless it was the switch from 5.10 to 5.15 - but still the info that it broke there will be helpful).
I'm not aware of any issues with SD cards ATM, but that doesn't mean much. It could be very specific to your SD card (and Sandisk produced a variety of 256GB cards with different speed classes, so the exact model number might matter, too).
And unfortunately searching for SD card issues in forums (or the web) is quite useless as tons of users reporting issues either had worn out or counterfeit cards, power problems, trashed filesystems because of unclean shutdowns, issues because of (too high) overclocking and whatnot - so the search turns up tons of non-issues and trying to finding actual issues in there is like finding a needle in a haystack...
I certainly wouldn't rule out that you might have hit an actual issue that no one experienced so far (or described in enough detail so it could be investigated) - I hit an odd issue on RPi4 a few month ago - SD card wasn't properly reset on reboots under certain conditions so cold boot worked, but reboot not (that should be completely unrelated to your issue though).
so long,
Hias
On RPi2/3 the kernel is 32bit, the official LE11.0.0 release uses kernel 6.1 (currently it's 6.1.19 on latest nightly).
LE10 uses kernel 5.10 (5.10.110 on latest LE10 build).
The earliest LE11 nightly build, 20220618, uses kernel 5.15.45.
You can look up the exact state the nightly was build from via the githash at the end of the image (eg b78941a for the 20220618-b78941a image) and feeding that into github. eg:
raspberrypi)
PKG_VERSION="6b945e6f05d5cb0a299dbbb9bdd285aff330a204" # 5.15.45so long,
Hias
We have a history of previous LE11 (nightly test ) builds here:
https://test.libreelec.tv/11.0/RPi/RPi2/
You could check through them, finding out with which build the issue started might give some clues.
so long,
Hias
frakkin64 no, we don't publish stats, they are rather boring anyways as they didn't change too much over the years (total RPi userbase always was in the 70-80% ballpark, only a few shifts between RPi1, 2/3, 4 over time).
And, yes, forum posts are only about issues, the users without problems are mainly silent - except for some rare "thank you"s here and there.
OFC there's still a significant amount of RPi2/3 users on LE9 (because of HEVC) and the absolute number of RPi2/3 installations is still very large.
And we also see still lots of other devices on older LE versions, most likely because they still "work just fine" - so no need to upgrade.
Chip crisis prevented lots of users from upgrading to RPi4, this might change in the next half year when RPi4 production (hopefully) ramps up and shops can stock them again. So I expect to see RPi2 (which is already down to about 5%) and RPi3 installations to decline in numbers and RPi4 to increase.
so long,
Hias
I don't know what the installs look like with LE11, but the impression from the release notes is that most RPi3 users may not be upgrading due to the loss of HEVC accelerated decoding.
The number of RPi2/3 users on LE10 and LE11 is actually quite high, during the last year the overall userbase distribution has been quite stable at roughly 40% RPi4, 30% RPi2/3, 20% Generic/x86, 10% everything else.
LE11 is quite new which means we have roughly 5 times as many LE10 users as LE11 users, but still this means quite a lot of LE11 RPi2/3 installations.
I'd also recommend testing with RPiOS and current "rpi-update" kernel, this will be the same as current LE11 nightly build and if there's an actual issue with the mmc driver (which is not caused by wearing out SD card, overclock, undervoltage etc) then RPi engineers would be the ones who could analyze and fix the issue - so posting on RPi forums would be best.
Personally I've never had such an issue on RPi2/3 (mainly using Sandisk Extreme and Extreme Pro 32GB SD cards here).
so long,
Hias
Please test with the latest LE11 nightly build (20230312) from here:
https://test.libreelec.tv/11.0/
They include a kodi update to 20.1-Nexus with several HD audio fixes.
Beware though that wifi may be broken, that's a known issue that will be fixed in future nighlies - and the upcoming LE 11.0.1 release.
so long,
Hias
Enable debug logging and use "pastekodi" to provide logs - the stuff you uploaded to google is inaccessible.
so long,
Hias
Thanks a lot for reporting back and glad it's working now!
You can simply use the image for now until we release LE 11.0.1. Of course we'll include the fix in future versions and I also created a pull request on the RPi linux kernel as it's affecting RPiOS as well
so long,
Hias
Can you please test with a clean install of this build:
and add "ssh video=HDMI-A-1:1280x1024D drm.debug=0x04" to cmdline.txt
I noticed a bug in the RPi video driver which prevented working around EDID issues (like you have) with video=... which I've fixed in the above image.
If it works please report back (and then you can drop the drm.debug=0x04 option in cmdline.txt), if it does not please run "pastekodi" and post the URL.
so long,
Hias
Re-encode the files on your PC and apply HDR_>SDR tonemapping. There's no other way if you are playing the videos on RPi4.
so long,
Hias
LibreELEC 11 has aarch64 kernel but arm (32bit) userspace so you can't use aarch64 docker containers, you need to use arm (32bit) containers.
LibreELEC 12 (development just started this week) switched RPi4 to aarch64 - but it will take a while until it's out and as it's bleeding new edge right now I wouldn't recommend switching to it unless you are prepared for a bumpy ride, constant breakage and lots of bugs.
so long,
Hias
Well, it went quicker as expected, LE12 addons, including aarch64 are now available from the repo (just do a manual update).
Note that a few retroplayer addons are currently missing for aarch64 (I'll look into that the next days) and inputstream.adaptive is currently missing the aarch64 widevine update - that will follow the next days.
Also note that inputstream helper currently does not support installing widevine libs for aarch64, you have to do it manually for now - eg using the instructions from here:
https://github.com/emilsvennesson…ment-1423115046
so long,
Hias
aarch64 addon build seems to have finished fine, but they still need to be pushed to the server.
Fingers crossed that works fine and will be happening soon.
I won't promise an ETA for that though, we had to deal with a couple of issues setting up CI builds for the new LE11nightlies, adding aarch64 addons and switching RPi4 (and some Allwinner devices) to aarch64 the past few days.
so long,
Hias
It will take a few days until the updated inputstream.adaptive addon has been built and uploaded to our servers, but - yes - we've switched RPi4 to 64bit in our LE12 / master branch and it's working fine.
so long,
Hias
