After initiating the September update via OSMC GUI, a sad face appeared repeatedly. Log files show that Kodi was in a restart loop. I’ve then moved the .kodi directory away to try with a fresh configuration to no avail. A reboot did not fix it either.
Did the following:
apt-get update
apt-get dist-upgrade
dpkg -l | grab-logs -A
Output is:
root@mc-schlafzimmer:/home/osmc# apt-get update
Hit http://security.debian.org jessie/updates InRelease
Ign http://ftp.debian.org jessie InRelease
Hit http://ftp.debian.org jessie-updates InRelease
Hit http://ftp.debian.org jessie Release.gpg
Hit http://ftp.debian.org jessie Release
Hit http://apt.osmc.tv jessie InRelease
Hit http://security.debian.org jessie/updates/main armhf Packages
Hit http://security.debian.org jessie/updates/contrib armhf Packages
Hit http://security.debian.org jessie/updates/non-free armhf Packages
Hit http://security.debian.org jessie/updates/contrib Translation-en
Hit http://security.debian.org jessie/updates/main Translation-en
Hit http://security.debian.org jessie/updates/non-free Translation-en
Get:1 http://ftp.debian.org jessie-updates/main armhf Packages/DiffIndex [8.884 B]
Hit http://ftp.debian.org jessie-updates/contrib armhf Packages
Get:2 http://ftp.debian.org jessie-updates/non-free armhf Packages/DiffIndex [736 B]
Hit http://ftp.debian.org jessie-updates/contrib Translation-en
Get:3 http://ftp.debian.org jessie-updates/main Translation-en/DiffIndex [3.688 B]
Get:4 http://ftp.debian.org jessie-updates/non-free Translation-en/DiffIndex [736 B]
Hit http://ftp.debian.org jessie/main armhf Packages
Hit http://ftp.debian.org jessie/contrib armhf Packages
Hit http://ftp.debian.org jessie/non-free armhf Packages
Hit http://ftp.debian.org jessie/contrib Translation-en
Hit http://ftp.debian.org jessie/main Translation-en
Get:5 http://apt.osmc.tv jessie/main armhf Packages/DiffIndex [2.023 B]
Hit http://ftp.debian.org jessie/non-free Translation-en
Ign http://apt.osmc.tv jessie/main Translation-en_US
Ign http://apt.osmc.tv jessie/main Translation-en
Fetched 16,1 kB in 18s (852 B/s)
Reading package lists... Done
root@mc-schlafzimmer:/home/osmc# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@mc-schlafzimmer:/home/osmc# dpkg -l | grab-logs -A
Logs successfully uploaded.
Logs available at https://paste.osmc.tv/ivoyesocoq
Hi,
It seems like your SD card may be problematic.
Some SD cards are not genuine or have a lower capacity than advertised. Some simply fail over time.
Symptoms of SD cards not working correctly are:
- Read-only behaviour, or changes made not persisting
- A filesystem corruption error
Symptoms of counterfeit SD cards are:
- Writing works until a certain filesystem size is reached, thereafter, writes seem to cause issues where existing data is lost or newly written data is not preserved.
- SD card fails after a short amount of time.
Counterfeit cards are usually found on Amazon and eBay.
SD cards have a limited lifespan. I recommend you change SD card and suspect that issues will no longer persist with a good card. If you would like to be a good quality SD card purpose manufactured for OSMC, then you can find one in the Store.
1 Like
Hi Sam,
thanks for the quick response.
Before switching to OSMC-branded SD cards, I had indeed experienced SD card problems. These problems (in the old times) were accompanied by write errors appearing in the log file.
Now, my 2 RPis (including the one experiencing the problem now) are equipped with OSMC SD cards bought from the Store on May 19, 2017. The RPi affected this time is rarely used (maybe one or two days per month). As far as I have seen, there were no write errors or update problems in the logs posted above. I should also note that I was able to successfully update and use my other RPi which is used on a daily basis.
What makes you think it could be SD card related in this case? Any indication in the logs I’ve uploaded?
Have a great weekend!
Well I guess the main reason assuming that is that you mentioned it happened after an update and in 90% of all cases that we saw been reported after an update it was related to power. Also as your Kodi crashes very early in the process that also could point in that direction.
Now assuming that the card is fine your first try could be to reinstall kernel and mediacenter run the commands and post the output.
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install --reinstall rbp2-image-4.9.29-9-osmc
sudo apt-get install --reinstall rbp2-mediacenter-osmc=17.4.0-9
reboot
OK, thanks. I’ll try that on Monday and report results. Just before reinstalling, I’ll compare the file system contents of my two RPi’s to check if there are any relevant differences.
Output is:
osmc@mc-schlafzimmer:~$ sudo apt-get update
Get:1 http://security.debian.org jessie/updates InRelease [63,1 kB]
Ign http://ftp.debian.org jessie InRelease
Get:2 http://ftp.debian.org jessie-updates InRelease [145 kB]
Hit http://ftp.debian.org jessie Release.gpg
Hit http://apt.osmc.tv jessie InRelease
Hit http://ftp.debian.org jessie Release
Get:3 http://security.debian.org jessie/updates/main armhf Packages [423 kB]
Hit http://security.debian.org jessie/updates/contrib armhf Packages
Get:4 http://ftp.debian.org jessie-updates/main armhf Packages/DiffIndex [8.884 B]
Hit http://security.debian.org jessie/updates/non-free armhf Packages
Hit http://security.debian.org jessie/updates/contrib Translation-en
Hit http://security.debian.org jessie/updates/main Translation-en
Hit http://security.debian.org jessie/updates/non-free Translation-en
Hit http://ftp.debian.org jessie-updates/contrib armhf Packages
Get:5 http://apt.osmc.tv jessie/main armhf Packages/DiffIndex [2.023 B]
Get:6 http://ftp.debian.org jessie-updates/non-free armhf Packages/DiffIndex [736 B]
Hit http://ftp.debian.org jessie-updates/contrib Translation-en
Get:7 http://ftp.debian.org jessie-updates/main Translation-en/DiffIndex [3.688 B]
Get:8 http://ftp.debian.org jessie-updates/non-free Translation-en/DiffIndex [736 B]
Hit http://ftp.debian.org jessie/main armhf Packages
Hit http://ftp.debian.org jessie/contrib armhf Packages
Hit http://ftp.debian.org jessie/non-free armhf Packages
Hit http://ftp.debian.org jessie/contrib Translation-en
Ign http://apt.osmc.tv jessie/main Translation-en_US
Hit http://ftp.debian.org jessie/main Translation-en
Ign http://apt.osmc.tv jessie/main Translation-en
Hit http://ftp.debian.org jessie/non-free Translation-en
Fetched 648 kB in 17s (36,7 kB/s)
Reading package lists... Done
osmc@mc-schlafzimmer:~$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
wpasupplicant
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 804 kB of archives.
After this operation, 5.120 B of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://security.debian.org/ jessie/updates/main wpasupplicant armhf 2.3-1+deb8u5 [804 kB]
Fetched 804 kB in 0s (2.332 kB/s)
(Reading database ... 22825 files and directories currently installed.)
Preparing to unpack .../wpasupplicant_2.3-1+deb8u5_armhf.deb ...
Unpacking wpasupplicant (2.3-1+deb8u5) over (2.3-1+deb8u4) ...
Processing triggers for dbus (1.8.22-0+deb8u1) ...
Setting up wpasupplicant (2.3-1+deb8u5) ...
osmc@mc-schlafzimmer:~$ sudo apt-get install --reinstall rbp2-image-4.9.29-9-osmc
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/19,5 MB of archives.
After this operation, 0 B of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 22825 files and directories currently installed.)
Preparing to unpack .../rbp2-image-4.9.29-9-osmc_9_armhf.deb ...
Examining /etc/kernel/preinst.d/
run-parts: executing /etc/kernel/preinst.d/001-preprocess-rbp 4.9.29-9-osmc /boot/vmlinuz-4.9.29-9-osmc
Done.
Unpacking rbp2-image-4.9.29-9-osmc (9) over (9) ...
Examining /etc/kernel/postrm.d .
Setting up rbp2-image-4.9.29-9-osmc (9) ...
Hmm. There is a symbolic link /lib/modules/4.9.29-9-osmc/build
However, I can not read it: No such file or directory
Therefore, I am deleting /lib/modules/4.9.29-9-osmc/build
Hmm. The package shipped with a symbolic link /lib/modules/4.9.29-9-osmc/source
However, I can not read the target: No such file or directory
Therefore, I am deleting /lib/modules/4.9.29-9-osmc/source
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.9.29-9-osmc /boot/vmlinuz-4.9.29-9-osmc
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal-osmc 4.9.29-9-osmc /boot/vmlinuz-4.9.29-9-osmc
run-parts: executing /etc/kernel/postinst.d/inform-updater 4.9.29-9-osmc /boot/vmlinuz-4.9.29-9-osmc
run-parts: executing /etc/kernel/postinst.d/process-vmlinuz-rbp 4.9.29-9-osmc /boot/vmlinuz-4.9.29-9-osmc
osmc@mc-schlafzimmer:~$ sudo apt-get install --reinstall rbp2-mediacenter-osmc=17.4.0-9
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/39,1 MB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 22825 files and directories currently installed.)
Preparing to unpack .../rbp2-mediacenter-osmc_17.4.0-9_armhf.deb ...
Unpacking rbp2-mediacenter-osmc (17.4.0-9) over (17.4.0-9) ...
Processing triggers for mime-support (3.58) ...
Setting up rbp2-mediacenter-osmc (17.4.0-9) ...
osmc@mc-schlafzimmer:~$
After the reboot, looks like Kodi is still in a restart loop.
[correction: login problem was temporary]
There must be a hardware issue in your setup that creates this problem as you are the only user with this issue. How are you powering the pi?
Really strange. So I guess the next try is a full reinstall
The power supply I’m using is a Goobay Model 43651, output 5.25 V, 2.1 A.
I use the same power supply for both of my Pi’s, one working, one experiencing the above symptoms. These are my hardware setups:
-
Problem Pi:
- Pi 2 Model B
- Goobay 43651 power supply
- OSMC 16GB SD card
- IR receiver TSOP31236 connected to GPIO via 100 Ohm resistor and a 0,1µF capacitor
- WiFi: EDIMAX EW-7811UN
-
Working Pi:
- Pi 2 Model B
- Goobay 43651 power supply
- OSMC 16GB SD card
- IR receiver TSOP31236 connected to GPIO via 100 Ohm resistor and a 0,1µF capacitor
- Ethernet connection using on-board interface
-
7 Port USB Hub (The Pi Hut) powered by its own power supply
- DVD drive connected via 7 port hub.
Another difference between those Pi’s is the usage and upgrade pattern. The working Pi is used on a daily basis and updated frequently. The “Problem Pi” is used about 2 days a month and updated less frequently.
I have noticed that some installation files differ between the two Pi’s suggesting that the update sequence did not produce identical results where it probably should have (I’m not talking about expected differences in configuration or hardware support files here). I’ll try to look into this before attempting a re-install and I’ll post the results.
What if you disconnect the wifi dongle? Does it boot then?
Zinken may be right as well though. That system may have some corruption that only a reinstall can resolve.
Well, it was booting correctly all the time. It’s just Kodi in a restart loop (sad face appearing, plus: see logs at the top). Booting without WiFi dongle also made Kodi go into a restart loop.
Seems like that. What I’m trying to figure out is whether this corruption might be caused by problems in the package update sequence due to infrequent updating (e.g. when a package skips some versions) or by some hardware error (then it could be about anything, including a faulty mainboard).
Have tried a new install. Now Kodi starts correctly.
Before reinstalling, I ran file system comparisons between my “Working Pi2” and my “Problem Pi”. Some files were different where they should not have been. Digging further showed that some files had a series of null bytes at the end, starting at offsets which were a multiple of 1024 bytes. These corrupted files (at seemingly arbitrary locations) appeared on both systems, the “Working Pi2” and the “Problem Pi2”.
So I created a new installation with osmcinstaller, went through the initial setup, ran apt update and apt dist-upgrade, then rebooted. Afterwards even on this pretty fresh installation, null byte sequences appeared at the end of some files where they should not:
usr/share/doc/perl/README.Debian: ending with 1361 null bytes starting at 0, 1361 bytes total
usr/share/doc/perl/changelog.Debian.gz: ending with 12315 null bytes starting at 40960, 53275 bytes total
usr/share/kodi/addons/resource.language.eu_es/addon.xml: ending with 643 null bytes starting at 0, 643 bytes total
The complete listing of files ending with at least 8 null bytes is at https://paste.osmc.tv/rogalunetu.m
If arbitrary files on the Pi become corrupted in this way, it is only a matter of luck whether the system works or not.
Is this a known phenomenon, given that my hardware setup (OSMC SD cards, strong power supplies) looks pretty safe?
No that is surely not a known phenomenon. I think you need to individually check your components. Start with the SD card and test it using H2testw
Have tested the SD card on Ubuntu 16.04 with F3 (a Linux alternative to h2testw):
Data OK: 14.63 GB (30685720 sectors)
Data LOST: 0.00 Byte (0 sectors)
Corrupted: 0.00 Byte (0 sectors)
Slightly changed: 0.00 Byte (0 sectors)
Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 22.95 MB/s
Cross-compiled F3 for the RPi.
Have tested the SD card on a fresh OSMC installation on the RPi2 (slightly less capacity tested due to installed OS):
Data OK: 12.99 GB (27242096 sectors)
Data LOST: 0.00 Byte (0 sectors)
Corrupted: 0.00 Byte (0 sectors)
Slightly changed: 0.00 Byte (0 sectors)
Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 22.50 MB/s
So the OSMC SD card seems perfectly OK, even when used on the RPi.
Additionally, I have checked a fresh OSMC installation:
- After installation of
OSMC_TGT_rbp2_20171001.img.gz and initial setup all files seem OK
-
apt dist-upgrade introduced files ending with null bytes:
usr/lib/arm-linux-gnueabihf/samba/libgpo.so.0: ending with 5968 null bytes starting at 45056, 51024 bytes total
usr/share/kodi/addons/pvr.demo/data/05.png: ending with 2294 null bytes starting at 0, 2294 bytes total
usr/share/kodi/addons/pvr.demo/data/07.png: ending with 2171 null bytes starting at 0, 2171 bytes total
usr/share/kodi/addons/resource.language.eu_es/addon.xml: ending with 643 null bytes starting at 0, 643 bytes total
usr/share/kodi/addons/resource.language.eu_es/icon.png: ending with 1994 null bytes starting at 0, 1994 bytes total
usr/share/kodi/addons/resource.language.eu_es/resources/langinfo.xml: ending with 366 null bytes starting at 0, 366 bytes total
usr/share/kodi/addons/screensaver.xbmc.builtin.dim/resources/settings.xml: ending with 161 null bytes starting at 0, 161 bytes total
This doesn’t look like generic spurious write errors to me.
Update: Added previously overlooked files ending with null bytes
1 Like
Results after more testing:
System S1 (Pi2 Model B “mc-s”)
| Installation |
SD card |
Corrupted Files |
Notes |
| S1.1 |
OSMC |
8 |
In use since May 2017, Kodi in restart loop |
| S1.2 |
OSMC |
4 |
Fresh installation up to dist-upgrade |
| S1.3 |
OSMC |
7 |
Fresh installation up to dist-upgrade |
| S1.4 |
OSMC |
0 |
Fresh installation up to dist-upgrade |
| S1.5 |
Samsung EVO |
0 |
Fresh installation up to dist-upgrade |
System S2 (Pi2 Model B “mc-w”)
| Installation |
SD card |
Corrupted Files |
Notes |
| S2.1 |
OSMC |
8 |
In use since May 2017, working |
| S2.2 |
OSMC |
2 |
Fresh installation up to dist-upgrade |
| S2.3 |
OSMC |
3 |
Fresh installation up to dist-upgrade |
| S2.4 |
Samsung EVO |
0 |
Fresh installation up to dist-upgrade |
| S2.5 |
OSMC |
9 |
Fresh installation up to dist-upgrade |
Note that with one OSMC SD card I was able to achieve a seemingly non-corrupted installation once (S1.4), but all others failed.
Conclusion
There seems to be a problem with the OSMC SD cards on the Pi2. Corruption occurs infrequently and seems to depend on the write pattern used:
- SD card tests mentioned in my previous post completed OK even when run on a Pi2.
-
apt dist-upgrade after initial installation was frequently able to trigger corruption.
Maybe the problem is related to firmware issue #397 and could be debugged using the strategies mentioned there. Before buying the OSMC cards in May 2017, I have experienced file system corruption from time to time with the Samsung Evo cards (with write errors appearing on-screen). Currently these Samsung Evo cards seem fine, while the OSMC cards appear problematic now. Could this be due to updated firmware bundled with OSMC releases since May?
While the problem is solved for me currently, as it seems to be related to OSMC SD cards, maybe you OSMC guys (@sam_nazarko, @ActionA, @fzinken) might want to look at it. If you’d like to try to reproduce the results, would you like me to send a version of the corruption discovery script I’ve used (to find files with an unusual amount of null bytes at the end)? Anything else I could do to help out?
Hi
Thanks for the detailed report.
That’s quite an old GitHub issue, and relates to the introduction of the SDHost driver which has matured some time ago.
It’s certainly very strange that you’ve experienced the corruption with these cards.
If you have time, it would be interesting to know if dtoverlay=mmc in config.txt remedies this issue. Note that this would have to be applied after the target installer runs and before the first proper boot. The target installer still uses mmc SD driver at this time.
In May I updated from 4.9.20 → 4.9.29; which should have only been an incremental kernel release and hopefully didn’t cause any problems here.
In May we would’ve used these firmwares. You should be able to adjust the script trivially to copy the files to /boot.
Sending the script over would be handy; and may even benefit users in the future or allow us to test for regressions to the SDHost driver in the future.
Sam
Hi Sam,
thanks for the quick response.
I have backported my corruption discovery script called show-files-ending-with-null-bytes to Python2 so that it is usable on an OSMC installation. It is here for you to access: https://paste.osmc.tv/jokufiroba.py
Of course, the script only checks for a certain type of file corruption. It may or may not be the case that other forms of file corruption are present as well without being detected.
Done. Installed to an OSMC SD card, let the installer format and proceed through the initial setup, shut down the system and used this config.txt before rebooting:
gpu_mem_1024=256
dtoverlay=mmc
hdmi_ignore_cec_init=1
disable_overscan=1
start_x=1
disable_splash=1
Then stored my script under /home/osmc/show-files-ending-with-null-bytes and ran:
sudo apt update && sudo apt -y dist-upgrade && sudo ./show-files-ending-with-null-bytes /
Resulting output from show-files-ending-with-null-bytes:
/usr/share/kodi/addons/skin.estouchy/xml/DialogTextViewer.xml: ending with 1900 null bytes starting at 0 [1K boundary], 1900 bytes total
/usr/share/kodi/addons/skin.estouchy/xml/IncludesCodecFlagging.xml: ending with 4080 null bytes starting at 0 [1K boundary], 4080 bytes total
/usr/share/kodi/addons/skin.estouchy/xml/MyVideoNav.xml: ending with 2350 null bytes starting at 0 [1K boundary], 2350 bytes total
/usr/share/kodi/addons/skin.estouchy/xml/PlayerControls.xml: ending with 58 null bytes starting at 0 [1K boundary], 58 bytes total
As you can see, dtoverlay=mmc did not remedy the issue.
Hope this helps. Could you try to reproduce the situation and post your results? As the file corruption is not that widespread and does not trigger any error messages in the system journal, it is possible that other systems are affected without users taking notice.
Oliver
Hi Oliver.
Thanks for the script.
I’ll look at it when I get a bit of free time. Should be mid week 
Sam
1 Like
i tested your script, and found a few problems with it, if running with python2.x (My test platform is Linux Mint 18.2)
First, you are missing:
from __future__ import print_function
as the first import.
And second, there is a problem with using range (If I remember correctly, range is different between Py2 and Py3)
This is the proper way in Py2
for index in xrange(1, file_size + 1):
Or, another idea I had was to do it this way:
for index in range(file_size - arguments.minimum_count, file_size + 1):
I didn’t do any testing to see if there was any difference in performance. I do know that with your original:
for index in range(1, filesize+1):
totally kills my laptop. Just for fun, try opening a Py2 console, and just try this:
> range(1, 85000000)
and see what happens 
I got MemoryError, assume related to the issues @bmillham highlighted