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:

enter image description here

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 
  • You have told us lots, mostly irrelevent, but not what "this annoying warning" says. – Milliways Mar 23 '17 at 22:51
  • @Milliways sorry I forgot to copy/paste the complete message. I updated the question. – malat Mar 24 '17 at 7:27
  • Have you successfully run the installation on the Pi? "upon the next reboot" is ambiguous. Did you verify the checksum before copying the image? – Milliways Mar 24 '17 at 7:46
  • @Milliways first boot is just fine. Kodi is 100% operational, but upon reboot the installer starts over again ! The img checksum looks right at least the two times I tried. – malat Mar 24 '17 at 7:49
up vote 0 down vote accepted

Well it looks like this is simply just a fake SDcard (cheap from ebay). Using some low level utils on Linux here is what I get:

$ f3write /media/mathieu/NEW\ VOLUME
Free space: 15.61 GB
Creating file 1.h2w ... OK!                           
Creating file 2.h2w ... OK!                         
Creating file 3.h2w ... OK!                         
Creating file 4.h2w ... OK!                         
Creating file 5.h2w ... OK!                         
Creating file 6.h2w ... OK!                         
Creating file 7.h2w ... OK!                         
Creating file 8.h2w ... OK!                         
Creating file 9.h2w ... OK!                         
Creating file 10.h2w ... OK!                         
Creating file 11.h2w ... OK!                         
Creating file 12.h2w ... OK!                        
Creating file 13.h2w ... OK!                        
Creating file 14.h2w ... OK!                        
Creating file 15.h2w ... OK!                        
Creating file 16.h2w ... OK!                        
Free space: 0.00 Byte
Average writing speed: 8.48 MB/s

And then:

$ f3read /media/mathieu/NEW\ VOLUME
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 1533687/   563465/      0/      0
Validating file 5.h2w ...       0/  2097152/      0/      0
Validating file 6.h2w ...       0/  2097152/      0/      0
Validating file 7.h2w ...       0/  2097152/      0/      0
Validating file 8.h2w ...       0/  2097152/      0/      0
Validating file 9.h2w ...       0/  2097152/      0/      0
Validating file 10.h2w ...       0/  2097152/      0/      0
Validating file 11.h2w ...       0/  2097152/      0/      0
Validating file 12.h2w ...       0/  2097152/      0/      0
Validating file 13.h2w ...       0/  2097152/      0/      0
Validating file 14.h2w ...       0/  2097152/      0/      0
Validating file 15.h2w ...       0/  2097152/      0/      0
Validating file 16.h2w ...      16/  1273792/      0/      0

  Data OK: 3.73 GB (7825159 sectors)
Data LOST: 11.88 GB (24905929 sectors)
           Corrupted: 11.88 GB (24905929 sectors)
    Slightly changed: 0.00 Byte (0 sectors)
         Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 3.20 MB/s

Also confirmed with the f3probe:

# f3probe --destructive --time-ops /dev/sdb
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Bad news: The device `/dev/sdb' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=7860034 /dev/sdb

Device geometry:
             *Usable* size: 3.75 GB (7860035 blocks)
            Announced size: 15.62 GB (32768000 blocks)
                    Module: 16.00 GB (2^34 Bytes)
    Approximate cache size: 1.00 MB (2048 blocks), need-reset=no
       Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 1'11"
 Operation: total time / count = avg time
      Read: 336.9ms / 4260 = 79us
     Write: 1'10" / 57554 = 1.2ms
     Reset: 164.9ms / 1 = 164.9ms

Kudos to folks at http://oss.digirati.com.br/f3/ for this tool. At least I understand what is going on now.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.