So I have been trying to install OpenELEC on my brand new RPi3B+ multiple times but everytime I install it, upon the next reboot I get this annoying warning that the file system is corrupted:
Filesystem corruption has been detected
To prevent an automatic repair attempt continuing
press any key or power off your system within the next 120 seconds
It seems to be coming from this script.
So the first boot is OK since I can go all the way to the end of the KODI installer. The installer goes through all the steps of selecting name, network, ssh/samba...
So the SDcard appears as valid whenever I use dd from the laptop, but for some reason appears as broken when used from the RPi3B+.
Here is what I have over here:
laptop $ sha1sum OpenELEC-RPi2.arm-7.0.1.img
9ef893344ed3f34e8902ef1acd72529cfd9c566e OpenELEC-RPi2.arm-7.0.1.img
Here is how I created the disk:
laptop $ sudo dd if=OpenELEC-RPi2.arm-7.0.1.img of=/dev/sdb bs=4M
laptop $ sudo sync
During installation, I can start the ssh server, and login as root. Here is what dmesg reveals:
[ 89.339021] EXT4-fs error (device mmcblk0p2): ext4_mb_generate_buddy:758: group 1424, block bitmap and bg descriptor inconsistent: 0 vs 4064 free clusters
[ 89.499420] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p2, blocknr = 1). There's a risk of filesystem corruption in case of system crash.
[ 143.674137] EXT4-fs error (device mmcblk0p2): ext4_mb_generate_buddy:758: group 1440, block bitmap and bg descriptor inconsistent: 0 vs 4064 free clusters
[ 143.870981] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p2, blocknr = 1). There's a risk of filesystem corruption in case of system crash.
[ 161.030349] EXT4-fs error (device mmcblk0p2): ext4_mb_generate_buddy:758: group 1456, block bitmap and bg descriptor inconsistent: 0 vs 4064 free clusters
[ 161.605868] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p2, blocknr = 1). There's a risk of filesystem corruption in case of system crash.
[ 161.611432] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p2, blocknr = 1). There's a risk of filesystem corruption in case of system crash.
If I remove the sdcard and load it from my laptop I can see:
[14504.911446] scsi 11:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS
[14504.912444] sd 11:0:0:0: Attached scsi generic sg2 type 0
[14505.902820] sd 11:0:0:0: [sdb] 32768000 512-byte logical blocks: (16.7 GB/15.6 GiB)
[14505.903882] sd 11:0:0:0: [sdb] Write Protect is off
[14505.903889] sd 11:0:0:0: [sdb] Mode Sense: 03 00 00 00
[14505.905013] sd 11:0:0:0: [sdb] No Caching mode page found
[14505.905021] sd 11:0:0:0: [sdb] Assuming drive cache: write through
[14505.909812] sdb: sdb1 sdb2
[14505.913914] sd 11:0:0:0: [sdb] Attached SCSI removable disk
[14506.405694] EXT4-fs (sdb2): warning: mounting fs with errors, running e2fsck is recommended
[14506.428429] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)
[14506.601421] EXT4-fs error (device sdb2): ext4_iget:4222: inode #851969: comm pool: bad extended attribute block 4294967295
[14506.606328] EXT4-fs error (device sdb2): ext4_iget:4222: inode #917505: comm pool: bad extended attribute block 4294967295
[14506.769229] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
I was hoping to simply run fsck to fix this, but I cannot apply suggestion from here, since I get:
OpenELEC:~ # fsck -fy /dev/mmcblk0p2
fsck from util-linux 2.29
e2fsck 1.43.3 (04-Sep-2016)
/dev/mmcblk0p2 is mounted.
e2fsck: Cannot continue, aborting.
And same with:
OpenELEC:~ # touch /forcefsck
touch: /forcefsck: Read-only file system
The card is brand new (I did format it completly using gnome-disks to all zeros), I find it hard to believe it is dying. Is there a way for sure to test the card from another linux laptop if this is the case ?
Here is what I did (following info from here), which gave me:
It is labeled Kingston 16GB class 10 Micro SDHC. Since I did not see anything wrong in the dmesg log from my laptop, I would think the SD card is in good shape.
Running some additional tests (from here), leads to:
# ./run_test.sh /dev/sdb
Running flashbench
4MiB 3.84M/s
2MiB 2.38M/s
1MiB 1.32M/s
512KiB 858K/s
256KiB 437K/s
128KiB 221K/s
64KiB 112K/s
32KiB 56.1K/s
16KiB 27.7K/s
8KiB 13.4K/s
4KiB 6.72K/s
