This is a companion page to http://sdjf.esmartdesign.com/cards.html,
where I give instructions on how
to use the mount, fsck, and fdisk commands to test the integrity of a card and it's files.
If you are attempting to check integrity of an SD
or CF card or other media, I recommend referring
to that page for detailed explanation.
It is very, very easy to get misleading output from fsck and from fdisk if you do not use the correct syntax or version of the command. So, if your output looks different from the examples I have posted on the companion page, do not immediately conclude that the card is bad!
I recommend that you first take a look at the examples below, to see if you have made some syntax error that has resulted in misleading or disturbing but innocuous output.
This is not a complete list, but simply a compilation of examples from the mistakes and discoveries that I have made, while attempting to learn how to use the commands on my Zaurus sl5500, running Sharp ROM 2.38., on my Zaurus sl6000, running Sharp ROM 1.12, and on my Raspberry Pi running ArchLinuxArm. If you have other examples of common mistakes, you would like me to post here, please contact me.
I have learned to not trust alarming file system errors when attempting to check file system and card integrity on expansion cards. This is as true for the Linux journaling file systems ext3 and ext4 as for ext2 and vfat systems, and as true for more recent Linux kernels being run on the Raspberry Pi as for the older kernels I am running on my Zaurus.
The following is the kind of output achieved after rebooting my Zaurus twice in a row. It is good and will result in no problems mounting the file system:
hub.c: USB new device connect on bus1/1/4, assigned device number 10
usb.c: USB device 10 (vend/prod 0xbda/0x119) is not claimed by any active driver.
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
scsi0 : SCSI emulation for USB Mass Storage devices
Vendor: Generic- Model: SD/MMC Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 2012160 512-byte hdwr sectors
(1030 MB)
sda: Write Protect is off
sda: sda1
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 10
USB Mass Storage support registered.
However, when I removed the above card, and put another one into my card reader, I get the following output from dmesg. The only way to resolve this is to reboot my Zaurus:
bash$ dmesg |tail -n4
usb.c: USB disconnect on device 10
hub.c: USB new device connect on bus1/1/4, assigned device number 11
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 11
bash$ sudo mount /dev/sda1
mount: Mounting /dev/sda1 on /mnt/usbstorage1 failed: Invalid argument
bash$ dmesg |tail
USB Mass Storage device found at 11
EXT2-fs: Unrecognized mount option umask
cramfs: wrong magic
VFS: Can't find a Minix or Minix V2 filesystem on device 08:01.
MSDOS FS: IO charset utf8
MSDOS FS: Using codepage 932
FAT: bogus logical sector size 0
VFS: Can't find a valid FAT filesystem on dev 08:01.
FAT: freeing iocharset=utf8
jffs2: attempt to mount non-MTD device 08:01
bash$
While I have not yet found an instance where fsck or fdisk displayed inappropriate errors on the Raspberry Pi when checking an SD card that could be fixed by rebooting, I have discovered that sometimes there are spurious errors that can be fixed by simply removing and reinserting the card reader. The following is one such example which occurred using ArchLinuxArm running a 3.2 kernel.
[alarmpi]# fsck.ext4 -v /dev/sdb2
e2fsck
1.42.5 (29-Jul-2012)
fsck.ext4: No such file or directory while trying
to open /dev/sdb2
Possibly non-existent device?
[alarmpi]# fsck.ext4 -v /dev/sda2
e2fsck 1.42.5 (29-Jul-2012)
fsck.ext4: No such file or directory while trying
to open /dev/sda2
Possibly non-existent device?
[alarmpi]#
I decided to next examine the card with parted rather than with fdisk, and parted also could not find a valid partition or file system structure for /dev/sdb:
[alarmpi]# parted -l
Error: /dev/sdb: unrecognised disk label
Model: Generic- SD/MMC (scsi)
Disk /dev/sdb: 3905MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Model: SD 00000 (sd/mmc)
Disk /dev/mmcblk0: 2030MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 99.6MB 98.6MB primary fat16
boot, lba
2 99.6MB 1978MB 1878MB primary ext4
[alarmpi]#
[alarmpi]#
[alarmpi]# fsck.ext4 -v /dev/sdb2
e2fsck
1.42.5 (29-Jul-2012)
fsck.ext4: No such file or directory while trying
to open /dev/sdb2
Possibly non-existent device?
[alarmpi]#
Then I tried running fdisk on the card. There was absolutely no output when I tried using fdisk non-interactively, so then I invoked it interactively, and it still could not examine the card properly.
[alarmpi]# fdisk -l /dev/sdb
[alarmpi]# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.21.2).
Changes will remain in memory only, until you decide
to write them.
Be careful before using the write command.
fdisk: unable to read /dev/sdb: Input/output error
[alarmpi]#
This was a serious situation, my good Raspberry Pi card could not be read by file system checking tools at all! I did not want to believe that the card was badly trashed, I had properly issued the sync and poweroff commands before turning off the power and removing the card from my Pi. So, I decided to try removing the SD card reader with the card still in it, from my USB hub, and then plugged them back in.
And, I was in luck, this time when I tried running fdisk on the card, it recognized the partitions and file system without any problem at all:
[alarmpi]# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.21.2).
Changes will remain in memory only, until you decide
to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sdb: 3904 MB, 3904897024 bytes
4 heads, 16 sectors/track, 119168 cylinders, total
7626752 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0004f23a
Device Boot Start End Blocks
Id System
/dev/sdb1 * 2048 186367 92160
c W95 FAT32 (LBA)
/dev/sdb2 186368 6737919 3275776
83 Linux
/dev/sdb3 6737920 7626751 444416
83 Linux
Command (m for help): q
[alarmpi]#
Then, since I had seen in my logs that the root file system did have errors in it, I ran fsck.ext4, and the following output confirms that. But my point here is that I was ready to totally give up being able to repair the card at all, because the initial output of fsck was that there was no possibility of repairing the file system, which was not true. Here is the output showing successful repair of the file system:
[alarmpi]# fsck.ext4 -v /dev/sdb2 e2fsck
1.42.5 (29-Jul-2012)
/dev/sdb2 contains a file system with errors, check
forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
92857 inodes used (47.77%, out of 194400)
169 non-contiguous files (0.2%)
72 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks:
0/0/0
Extent depth histogram: 80198/161
464140 blocks used (56.68%, out of 818944)
0 bad blocks
1 large file
73974 regular files
6258 directories
3 character device files
0 block device files
1 fifo
2070 links
12612 symbolic links (12486 fast symbolic links)
0 sockets
------------
94918 files
[alarmpi]#
And I reran fsck, just to make sure the file system was repaired, and it tells me the file system is clean:
[alarmpi]# fsck.ext4 -v /dev/sdb2
e2fsck 1.42.5 (29-Jul-2012)
/dev/sdb2: clean, 92857/194400 files, 464140/818944 blocks
[alarmpi]#
I just made the unsettling discovery that fsck.vfat runs without complaining on both my sl5500 and my sl600 when my SD card is mounted! However, I would not trust the results without issuing the umount command.
bash$ sudo df /dev/mmcda1
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/mmcda1 993408 992096 1312 100% /usr/mnt.rom/card
bash$
bash$ fsck.vfat /dev/mmcda1
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
/dev/mmcda1: 6386 files, 62006/62088 clusters
bash$
The above does not happen when running fsck.ext2 on my Zaurus, or any type of fsck on my Raspberry Pi. When I try to run fsck on an ext2 card which is mounted on my Zaurus, I get the following error message. For more information about the proper way to unmount a file system, see my companion page about Checking Expansion Card Integrity.
bash$ fsck.ext2 /dev/hda1
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
/dev/hda1 is mounted.
WARNING!!! Running e2fsck on a mounted filesystem may cause SEVERE filesystem damage.
Do you really want to continue (y/n)? no
check aborted.
bash$
Sharp's rendition of fsck.vfat (at least on ROMs 2.38 and 1.12) does not yield clear output when it is not given arguments. If the output does not say "clean", and there are no errors for fsck to fix, then the results are inconclusive, as in the following example. Note the word "clean" is not present in the output:
bash-2.05# fsck.vfat /dev/hda1
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
/dev/hda1: 178 files, 62868/62918 clusters
bash-2.05#
One solution for this is to run fsck.vfat with the "-v -t -a" flags, as illustrated here.
I often get an "/dev/hda1 was not cleanly unmounted" error message such as the following. I believe this is because I sometimes forget to eject a card using the GUI before pulling it out.
bash-2.05# umount /mnt/cfbash-2.05# fsck.ext2 /dev/hda1
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
/dev/hda1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda1: 11/125488 files (0.0% non-contiguous),
15851/500440 blocks
bash-2.05#
However, if I want to make sure that the card is okay, again, I then get the following output. The above fsck.ext2 corrected the problem:
bash-2.05# fsck.ext2 /dev/hda1
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
/dev/hda1: clean, 11/125488 files, 15851/500440 blocks
bash-2.05#
If I try to run fsck.vfat on an ext2 card, l I get the following erroneous output:
bash-2.05# fsck.vfat /dev/hda1
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Logical sector size is zero.
bash-2.05#
But if I check to make sure that the card is okay, properly using fsck.ext2, I get the following output:
bash-2.05# fsck.ext2 /dev/hda1
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
/dev/hda1: clean, 11/125488 files, 15851/500440 blocks
bash-2.05#
Another vfat CF card yielded the following output when I incorrectly attempted to perform an ext2 file system check on it:
bash-2.05# fsck.ext2 -ncfv /dev/hda1
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/hda1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
bash-2.05#
Instead of /mnt/card/ or /mnt/cf, you must use /dev/mmcda1 or /dev/hda1 to refer to your expansion card, or you may get output like the following:
bash-2.05# fsck.vfat /mnt/card/
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Read 512 bytes at 0:Is a directory
bash-2.05#
Here is sample output from examining a vfat CF card. Note that adding the arguments to fsck does not make any difference in this case, since I am calling the device inappropriately as "/dev/hda", when it should have been called as "/dev/hda1":
bash-2.05# umount /mnt/cf
bash-2.05# fsck.vfat /dev/hda
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Currently, only 2 FATs are supported, not 165.
bash-2.05# fsck.vfat -v -t -a /dev/hda
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Currently, only 2 FATs are supported, not 165.
bash-2.05# fsck /dev/hda
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/hda
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else),
then the superblock
is corrupt, and you might try running e2fsck with
an alternate superblock:
e2fsck -b 8193 <device>
bash-2.05#
It is important to put what kind of fsck to run. Otherwise, you may get output like the following:
bash-2.05# fsck /dev/hda1
Parallelizing fsck version 1.19 (13-Jul-2000)
fsck: fsck.auto: not found
fsck: Error 2 while executing fsck.auto for /dev/hda1
bash-2.05#
Note what happened in the following example, when I again tried running fsck without the appropriate device name, and how fdisk came out fine for the same card:
bash-2.05# fsck.msdos /dev/hda
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Currently, only 2 FATs are supported, not 165.
bash-2.05#
bash-2.05# Programs/fdisk -l /dev/hda
Disk /dev/hda: 8 heads, 32 sectors, 984 cylinders
Units = cylinders of 256 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 983 125808 6 FAT16
bash-2.05#
Note that there is no output about start and end cylinders, etc., when I inappropriately try to run fdisk on "/dev/mmcda1" instead of on "/dev/mmcda":
bash-2.05# fdisk /dev/mmcda1
Command (m for help): p
Disk /dev/mmcda1: 16 heads, 63 sectors, 992 cylinders
Units = cylinders of 1008 * 512 bytes
Device Boot Start End Blocks Id System
Command (m for help): q
bash-2.05#
Here is another example of what can happen when using the wrong name for this command. The card used in this example has an ext2 file system:
bash-2.05# fdisk /dev/mmcda1
Device contains neither a valid DOS partition table, nor Sun, SGI, or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Command (m for help): p
Disk /dev/mmcda1: 32 heads, 63 sectors, 998 cylinders
Units = cylinders of 2016 * 512 bytes
Device Boot Start End Blocks Id System
Command (m for help): q
bash-2.05#
Here is another example of output I obtained from running fdisk with a wrong device reference:
bash-2.05# Programs/fdisk -l /dev/hda1
Disk /dev/hda1: 16 heads, 63 sectors, 994 cylinders
Units = cylinders of 1008 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1p1 ? 1904714 2444830 272218546+ 20 Unknown
Partition 1 has different physical/logical beginnings (non-Linux?):
phys=(356, 97, 46) logical=(1904713, 4, 3)Partition 1 has different physical/logical endings:
phys=(357, 116, 40) logical=(2444829, 6, 41)
Partition 1 does not end on cylinder boundary:
phys=(357, 116, 40) should be (357, 15, 63)
/dev/hda1p2 ? 1319628 1854326 269488144
6b Unknown
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(288, 110, 57) logical=(1319627, 2, 61)
Partition 2 has different physical/logical endings:
phys=(269, 101, 57) logical=(1854325, 14,8)
Partition 2 does not end on cylinder boundary:
phys=(269, 101, 57) should be (269, 15, 63)
/dev/hda1p3 ? 534712 1921977 699181456
53 OnTrack DM6 Aux3
Partition 3 has different physical/logical beginnings (non-Linux?):
phys=(345, 32, 19) logical=(534711, 11, 11)
Partition 3 has different physical/logical endings:
phys=(324, 77, 19) logical=(1921976, 7, 54)
Partition 3 does not end on cylinder boundary:
phys=(324, 77, 19) should be (324, 15, 63)/dev/hda1p4 * 1383560 1383581 10668+
49 Unknown
Partition 4 has different physical/logical beginnings (non-Linux?):
phys=(87, 1, 0) logical=(1383559, 3, 3)
Partition 4 has different physical/logical endings:
phys=(335, 78, 2) logical=(1383580, 5, 45)Partition 4 does not end on cylinder boundary:
phys=(335, 78, 2) should be (335, 15, 63)
bash-2.05#
The following output is on the same card, with the proper device reference:
bash-2.05# fdisk -l /dev/hda
Disk /dev/hda: 16 heads, 63 sectors, 994 cylinders
Units = cylinders of 1008 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 993 500440+ 6 FAT16
bash-2.05#
Contents Last Revised 16 Feb 2013