For reference, the 4.3.3-3-osmc kernel that was released last night has made mmc the default SD card driver again as it was in all releases before December.
So anybody updating from November or earlier to the December release from today onwards will get 4.3.3-3-osmc which will still default to the mmc driver instead of sdhost, so this issue will not occur for them.
The decision to revert back to the mmc driver by default was made after seeing the feedback on the forum that showed a lot more SD cards had compatibility issues than initially thought.
It’s unfortunate we have to do this because the Pi Foundation (who maintain the Raspberry Pi Kernel on which we base the OSMC kernel on Pi 1/2) have made it clear that they are moving to sdhost as the default driver, and very soon, however we had to weigh up the benefits of the improved performance of sdhost and staying current with our kernels with the drawback of sdhost seemingly still having some compatibility issues with a significant number of SD cards.
At some point in the next few months we will probably move back to sdhost again when the sdhost driver has had a bit more work and wider testing done on it.
For those that were affected by this issue who are interested in helping test improvements to the sdhost driver keep a watch on this thread and we may have some test kernel builds for you to try in the next few weeks. Only by testing with affected cards will any bugs or issues in the driver eventually be worked out.
For those for whom sdhost worked fine for (the vast majority) who would like to keep the performance benefits of sdhost, you can still enable it with the following line in config.txt:
dtoverlay=sdhost
(and remove any line that says dtoverlay=mmc)
You can test whether your kernel is currently using the sdhost driver or not with the following command:
I’m in a nightmare now
I have had the update that prompt from smbd.conf and i have accept-it
pi2 won’t boot anymore
I have try to update the mmc and change config.txt but that has no resolve this issus
My SDCard is a Samsung Evo 16Gb (1 years old)
Do you think the problem is only on the fat / boot partition ?
I will try to reinstall from scratch and only copy fat partition to my old card to try
[Edit] : copy of fat partition from fresh install work for me (I think that kernel was not correctly updated to last 4.3.3-3
pouffff !!!
Alright so I was and still am not able to get past the sad smiley face screen. I am using a rpi2 with SanDisk Ultra 32 GB MicroSDHC UHS-I. I inserted the SD card into a PC and managed to add the dtoverlay=mmc line at the end of config.txt file. Unfortunately I am still not able to boot - the sad smiley face appears. Are there any other workarounds? I am literally going crazy over this - the first experience with OSMC was so good, but this update has made it sooooooo bad. Can someone please post a solid solution to this? Will a clean OSMC install work 100%? Thank you!
boot with this, configure initial setup ( country, timezone,…)
go to myosmc et install latest update
if reboot work, shutdown rpi, go on your mac and copy all file from the fresh install boot (fat partition) to your old card fat partition (save your old fat part before)
It’s work for me
I have the same problem with December update. OSMC start up screen hanging. LAN is not active, changing “recovery.cmdline” to enter recovery mode failed on both accounts.
My SD Card: Verbatim MicroSDHC 32GB (Class 10) for Tablets - like this one.
Running OSMC on Pi2, installed via Noobs. Osmc is the only operating system installed.
I replaced overlays/mmc-overlay.dtb, but I did not manage to change config.txt (edit icon was greyed out +I did not manage to find the FAT partition) and to see if the fix works.
Ok, so the sad smile face actually is different to “not booting” as which this thread is about. Is OSMC still visible on the network and can you still SSH into OSMC? If yes provide the URL of grab-logs -A
Alright - good to find out that smiley face is not the same as not booting - my bad. So even though rpi2 is connected to my router via a WiFi dongle and osmc is showing the sad smiley face, it has managed to connect to the router successfully and I indeed can connect to it via ssh. So I connected via SSH (I have to note that somehow ssh seems significantly slower than usual), typed grab-logs -A and this is the output I got: http://paste.osmc.io/axovaxuzaw . I would be really thankful if someone found the problem and pointed to the solution - clean install is a no-go. Thanks!
Your Pi seems to be having trouble reading from the SD card:
Jan 04 18:27:58 osmc kernel: INFO: task kworker/u8:0:6 blocked for more than 120 seconds.
Jan 04 18:27:58 osmc kernel: Tainted: G C O 4.3.3-2-osmc #1
Jan 04 18:27:58 osmc kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 04 18:27:58 osmc kernel: kworker/u8:0 D 807386d4 0 6 2 0x00000000
Jan 04 18:27:58 osmc kernel: Workqueue: writeback wb_workfn (flush-179:0)
Jan 04 18:27:58 osmc kernel: [<807386d4>] (__schedule) from [<80738cd8>] (schedule+0x58/0xc8)
Jan 04 18:27:58 osmc kernel: [<80738cd8>] (schedule) from [<8073c608>] (schedule_timeout+0x240/0x2e0)
Jan 04 18:27:58 osmc kernel: [<8073c608>] (schedule_timeout) from [<80738358>] (io_schedule_timeout+0xc0/0x138)
Jan 04 18:27:58 osmc kernel: [<80738358>] (io_schedule_timeout) from [<807395b0>] (bit_wait_io+0x48/0x70)
Jan 04 18:27:58 osmc kernel: [<807395b0>] (bit_wait_io) from [<80739c08>] (__wait_on_bit_lock+0xcc/0x220)
This could be a problem with the SD card, but you could try temporarily reverting the kernel to your previous version with the following commands from SSH:
If this works OK you could try running updates again as there is an even newer kernel available now (4.3.3-3) than the one you are on just at the moment. (4.3.3-2)
If it doesn’t help it could possibly be a failing SD card.
Thanks for the advice. I did what you said, but the sad smiley face was still there. Then I upgraded to the newest version via ssh, and I still cannot get past the sad smiley face. However, in the log it seems that osmc is not having trouble reading from the sd card. Here is the log: http://paste.osmc.io/desotixege
Do I really have to buy a new SD card? Isn’t there really a different issue showing up in the logs? I have to add that everything was working fine until the December update - only sad smiley face after that.
If that helps then you have experienced file system corruption at some point that has corrupted system files including those belonging to Kodi. (A fresh install would be recommended)
I’ve been testing with a Transcend card on a Pi 2 using sdhost, and I’ve not seen any problems (even when overclocked with the SD card at 100MHz). Unfortunately the card I received was a 400x (16GB), so perhaps the technology has changed and the problem has disappeared, or perhaps it is in some way related to the content or the file history; I ran a clean install and then updated, with a subsequent downgrade to 4.3.3-1, trying with and without dtoverlay=sdhost at all steps.
Is there anybody, preferably in the UK for reasons of speed, who has a card that fails with sdhost that they would be willing to send to me at Pi Towers? I will compensate you for the card and the postage, or I can get an equivalent replacement sent to you.
Message me if you can help.
N.B. I want the card to be shipped in the failing state, so that all I need to do is plug it into a Pi of the same model and watch it fail - this isn’t laziness, I’m just trying to maximise the chances of reproducing the problem.
I have not updated to December yet but my OSMC says “A new version has been downloaded, would you like to install it now?”
Is there a download that needs to be purged from before the fix or will the downloading of the update actually happen after the reboot so I would be on the freshest version?
That’s correct - the manual update check first performs the equivalent of apt-get update which will re-download the package list and thus find the newer version of the kernel packages. So even if it may have downloaded the debs for the older kernel in the cache it will not use them - it will skip to the newest version of each package.
If you want to be really paranoid, you could run sudo apt-get clean from SSH first - this will delete both the package cache that is created by apt-get update (containing the list of available packages) and all previously downloaded debs.
Unfortunately that did not help. I will try a clean install later today. Also, I am wondering how did I get my file system corrupt. Could it be that it got corrupted because I was just unplugging the pi from power supply when wanting to shut down? Is there an official/support way to shut down? Thanks
