@natterstefan
Sorry, then grab-logs -P -A should write it to SD card and then upload from PC.
Alternative do you have a wireless stick available to test?
Are any USB devices working?
should look something like this when you do it
osmc@MediacenterOSMC:~$ sudo -s
root@MediacenterOSMC:/home/osmc# umount /boot
root@MediacenterOSMC:/home/osmc# fsck.fat -V /dev/mmcblk0p1
fsck.fat 3.0.27 (2014-11-12)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Starting check/repair pass.
Starting verification pass.
Leaving filesystem unchanged.
/dev/mmcblk0p1: 64 files, 40711/489976 clusters
root@MediacenterOSMC:/home/osmc# fsck.fat -a /dev/mmcblk0p1
fsck.fat 3.0.27 (2014-11-12)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Automatically removing dirty bit.
Performing changes.
/dev/mmcblk0p1: 64 files, 40711/489976 clusters
root@MediacenterOSMC:/home/osmc# mount /boot
this only fixes the boot partition not the root partition so you need to try and force the fsck to run at boot again
okay, but how can I get the log then from the PC? Can I access it just by pluging in the SD card?
No, but I could buy one to test this. Yes, there is a Sundtek MediaStick (for DVB-C TV) 1 external harddrive attached, both are still working.
@toast: I did what you told me. see screenshot: http://d.pr/i/1gn2a.
I then run the touch /forcefsck again. Is there a way to kill this watchdog? I always have to wait until it stoppedā¦
ā¦ I have to wait until this watchdog thing is goneā¦ or otherwise I need to kill it again. But maybe then the forcefsck does no work?
umount not unmount tend to do the same thing when im stressed
1 Like
With that command the log files are copied on the boot partition which can be read by any Windows PC or MAC
wow, what just happened? It looks like the ethernet eth0 is back again. I cannot confirm that it will be stable as OSMC just crashed (saw the sad smiley) but It was back.
Let me see what happens after the reboot. Update: yes it is still here.
@toast I think your proposed solution worked! THANK YOU! Please send me a link where I can wire you money for a beer 
@fzinken too bad it worked before I could save the log (thinking about other people). But if I get the error again - I will test it in the next few days by shutting down the Pi and restarting it - I will come back to this thread and let you know!
sent in pm dont forget to click solution on the post that made it work for ya and tnx for the beer 
@toast I will.
BTW I think this could help others to avoid the watchdog issue. I read something about it here (http://crunchbang.org/forums/viewtopic.php?id=39521).
In Jessie, I use:
systemctl reboot -i
Creating /forcefsck will not by default do anything in OSMC. For this to have any effect you would have to edit your /etc/fstab and change the 0 at the end of the line for the root file system for 1. Then touch /forcefsck would trigger systemd to do a filesystem scan.
However the recommended way to force a full fsck on boot in OSMC is to edit /boot/cmdline.txt and add the word forcefsck there.
This will trigger a full deep fsck scan and repair in the initramfs which runs very early during boot.
BTW, donāt worry about messages like Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. for the FAT partition - this is fairly normal because we do not run an automated fsck of any kind for the fat partition - so after you have had even one unclean shutdown it will always say this.
If you want to you can change the 0 to a 1 on the end of the /etc/fstab line for the /boot partition which will cause it to be fsckāed on boot, however this will slow your boot down by a few seconds.
1 Like
@DBMandrake so, yesterday the eth0 went down again (after a reboot) and came back a few reboots later (donāt ask me why). Anyway, do you think I should try it again with forcefsck as you suggested?
@Toast yeah, I hope you enjoyed it!
This really sound strange and might not only be related to corruption. But it would not harm if you would try the forcefsck as suggested by DBmandrake.
But more important next time when the eth0 is not working execute grab-logs -P -A to store the logfiles on the SD card so that we know whats going wrong.
Also just two more questions:
- Why do you reboot it so often?
- Are you 100% sure your powersupply and cables work well?
@fzinken I will when I get back home today.
Answer: Why I had to restart the Pi again
I tried to modify the remote-keymap. Because suddenly (again) when I press the Volume button on my All-in-One Remote (Amazon: Amazon.de) I start seeing the āCodec Informationā Overlay. It disappears when I hit it twice. I had this issue a while ago after I updated the Pi (think it was in December). Too bad I forgot how to fix it.
The remote controls my Teufel Audio System (Amazon.de). And whilst trying to fix this I turned off the turbo mode and rebooted the Pi.
Answer: Power Supply
Maybe I should try to use some other cables, you are right. There are other Pis in my flat, and I am gonna try it with one of their setup again.
Just for future help, no need to reboot for that (unless you make changes to config.txt). Just login with ssh and restart the mediacenter sudo systemctl restart mediacenter
Also if they are the same type (means RPi2) then maybe just swap the SD card between them. Then you could figure out if it is hardware or SD card related.