In the best of all possible worlds, the CF and SD cards we buy would work every time, and we would never have to be concerned about their integrity. But, sad to say, that is not the case. Anyone using SD or CF cards on their Zaurus has probably had a problem with expansion cards at some point or other.
There are plenty of other discussions out there about reformatting, compatibility, accessing files, and transferring data to and from SD and CF cards. What I want to focus on here is how to test the integrity of a card and it's files.
While the general principles I will discuss here
probably apply to all Zauruses, please note that
I am posting examples and caveats based on running
the commands using an sl5500 with Sharp ROM 2.38,
which uses the 2.4.6 Linux Kernel, and the output
from other ROMs and kernels may vary.
In some cases, you may be unable to get a card's icon to appear in the taskbar after inserting the card, and be unable to get the following commands to run as shown because the file system has not mounted (example here). Before you give up, reboot your system with the card inserted. This may clear any problems preventing you from successfully doing the suggested diagnostics, with the icon appearing and commands working as shown below after rebooting.
I believe that the first thing we all should do when we buy a new card is test it's physical integrity, as a piece of hardware.
In order to test the physical integrity of a card, however, we need to determine what type of file system is on the card, if there is one. Confused? Huh? What difference does the file system make if I want to test the hardware, not the file system? Does that seem backwards? I understand, but just read on. I think that is part of why it has been hard for me to figure out how to do this myself, so if you feel like a nerd about it, you are not alone. ;)
We will need to use the "mount" command to find out the file system type.
And we will not give it any arguments in this case, or it will not yield the information we want.
Here is some sample output:
bash-2.05# mount
/dev/mtdblock0 on / type cramfs (ro)
/proc on /proc type proc (rw)
/dev/ram1 on /dev type minix (rw)
/dev/mtdblock1 on /home type ext2 (rw,sync)
none on /dev/pts type devpts (rw)
/dev/mmcda1 on /usr/mnt.rom/card type vfat (rw)
bash-2.05#
Now, if parsing the output of "mount" is confusing to you, just "pipe" the output through "grep" as follows. The first example below is for an SD card, and the second is for a CF card:
bash-2.05# mount | grep card
/dev/mmcda1 on /usr/mnt.rom/card type vfat (rw)
bash-2.05#
bash-2.05# mount | grep cf
/dev/hda1 on /usr/mnt.rom/cf type ext2 (rw)
bash-2.05#
The above output tells me that my SD card has a vfat file system, and that my CF card is formatted with ext2.
The next thing we will do with a card that is not new, is run the fsck command, the acronym for "file system check." But this can get weird, as we have more than one fsck command on the Zaurus! To see which fsck commands I have on my Zaurus, I use something called "tab expansion". I simply enter just the first two letters of "fsck" (i.e., "fs") on the command line, and then hit the tab three times:
bash-2.05# fsck
fsck fsck.ext3 fsck.msdos
fsck.ext2 fsck.minix fsck.vfat
bash-2.05#
So, since my SD card has a vfat file system, I see I can use fsck.vfat to check it. And, since my CF card is formatted in ext2, I should use fsck.ext2 to check it's file system.
However, in order to run fsck, we must first detach the file system by using the "umount" command. Note that while the purpose of "umount" is to unmount the file system while the card is still physically attached to your Zaurus, the command is "umount", without any "un" in it.
After issuing the "umount" command, you will need to
wait until the SD card icon has disappeared from
the bottom tray on your Zaurus before you enter the fsck command.
On my Sharp ROM 2.38, the display freezes a little while and then the
SD card icon disappears, as it should.
However, when I attempt to "umount" the card in my CF slot, the CF card icon remains in the bottom tray, even after the card has been unmounted. So, to confirm that the unmounting is complete, I run the "df" command.
The following is sample output from the "df" command, showing both an SD and a CF card mounted on my Zaurus:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/ram1 44 25 19 57% /dev
/dev/mtdblock1 32619 31519 0 100% /home
/dev/mmcda1 499968 397216 102752 79% /usr/mnt.rom/card
/dev/hda1 1006688 758848 247840 75% /usr/mnt.rom/cf
The following shows my Zaurus with just an SD card mounted:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/ram1 44 26 18 59% /dev
/dev/mtdblock1 32619 31273 0 100% /home
/dev/mmcda1 499968 390544 109424 78% /usr/mnt.rom/card
The following shows my Zaurus with just a CF card mounted:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/ram1 44 25 19 57% /dev
/dev/mtdblock1 32619 26690 4189 86% /home
/dev/hda1 500176 16 500160 0% /usr/mnt.rom/cf
And the following shows my Zaurus without any cards mounted:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/ram1 ; 44 26 18 59% /dev
/dev/mtdblock1 32619 32044 0 100% /home
Once a SD card has been successfully unmounted, there will be no output from "df" showing "/usr/mnt.rom/card". And, similarly, once a CF card has been unmounted. there will be no lines with information about "/usr/mnt.rom/cf".
Note that on later ROMs, which usually have the user logged in as "zaurus" rather than as "root", you may be unable to run the umount and other commands because of security issues, unless you utilize the sudo command.
In the following example, I was not able to run the umount command on my sl6000.
Here is the error message:
bash-2.05# umount /dev/mmcda1
umount: /dev/mmcda1: Operation not permitted
bash-2.05#
I had to preface the umount command with sudo,
which gave me root permissions.
I used sudo to run the umount command as follows to unmount my SD card:
bash-2.05# sudo umount /dev/mmcda1
bash-2.05#
Sudo is not necessarily built in to all Zaurus ROMs, so you many need to install it off of one of the feeds if you have a later ROM and have not already installed it.
If you do not have sudo, you will get output like the following from the type command:
bash-2.05# type sudo
bash: type: sudo: not found
bash-2.05#
If you have it installed properly, you will get a message about it's location if you run the type command for it, as follows:
bash-2.05# type sudo
sudo is hashed (/usr/bin/sudo)
bash-2.05#
Most of the commands recommended below also require root privileges but, for the sake of simplicity, I have not shown sudo in the discussion.
I will write more about sudo when I can squeeze it in to my schedule.
In the meantime, just remember that any time you get an "Operation not permitted" message, it might mean you need to preface the command with sudo in order to proceed.
The version of sudo I have gives me root privileges when I issue it, but not all installations do that.
After successfully unmounting the card, since the output of the "mount" command told me that my SD card has a vfat file system, I will want to use fsck.vfat to check the integrity of my SD cards.
Unfortunately, though, Sharp's fsck.vfat is a little buggey on ROMS 2.38 and 3.10, and you can not count on it detecting problems, not unless you give it some arguments.
For example, the following output from running plain fsck.vfat on an SD card that has been giving me trouble shows no errors. But notice there is no statement about whether or not the card is "clean::
bash-2.05# umount /mnt/card
bash-2.05# fsck.vfat /dev/mmcda1
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
/dev/mmcda1: 3075 files, 24409/31248 clusters
bash-2.05#
The output from running fsck.vfat on a "clean" card should look more like the following example. Notice the word "clean" on the last line.
bash-2.05# fsck.vfat /dev/mmcda1
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
/dev/mmcda1: clean, 11/125488 files, 15851/500440 clusters
bash-2.05#
Sharp's fsck will correct typical errors if there are any, but it will not give diagnostics if there are other problems
unless it is given the proper flags on the command line.
Here is the output obtained when I added appropriate options:
bash-2.05# fsck.vfat -v -t -a /dev/mmcda1
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Boot sector contents:
System ID " "
Media byte 0xf8 (hard disk)
512 bytes per logical sector
16384 bytes per cluster
1 reserved sector
First FAT starts at byte 512 (sector 1)
2 FATs, 16 bit entries
62976 bytes per FAT (= 123 sectors)
Root directory starts at byte 126464 (sector 247)
512 root directory entries
Data area starts at byte 142848 (sector 279)
31248 data clusters (511967232 bytes)
63 sectors/track, 16 heads
233 hidden sectors
1000215 sectors total
/2005-12-14-11-31.backup
Cluster 950 (31249) is unreadable. Skipping it.
Internal error: next_cluster on bad cluster
bash-2.05#
So, if you have a vfat card, and do not see the word "clean" in the last line of the output, then I would recommend running fsck.vfat with the arguments shown in the latter example above. If you want to automatically let fsck make repairs, then substitute "-r" for "repair", instead of using "-a" for "ask", in the above example.
Here is sample fsck output from a brand new card, which came as vfat from the factory. First let us look at output from fsck.vfat with the appropriate options:
bash-2.05# fsck.vfat -f -a -t -v /dev/mmcda1
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Boot sector contents:
System ID " "
Media byte 0xf8 (hard disk)
512 bytes per logical sector
16384 bytes per cluster
1 reserved sector
First FAT starts at byte 512 (sector 1)
2 FATs, 16 bit entries
125952 bytes per FAT (= 246 sectors)
Root directory starts at byte 252416 (sector 493)
512 root directory entries
Data area starts at byte 268800 (sector 525)
62856 data clusters (1029832704 bytes)
63 sectors/track, 32 heads
243 hidden sectors
2011917 sectors total
Checking for bad clusters.
Cluster 62857 is unreadable.
Reclaiming unconnected clusters.
Performing changes.
/dev/mmcda1: 0 files, 1/62856 clusters
bash-2.05#
Note that in this example, fsck finds 62856 data clusters, and complains that cluster number 62857 is unreadable.
Since it found 1029832704 bytes, and that is definitely more than a gigabyte, I will
not worry about it complaining that it cannot read more bytes.
Remember Sharp's fsck.vfat is broken, so it's output needs to be confirmed using other commands as well.
Then again, maybe the manufacturer just failed to mark the end of the partition!
What counts are the numbers and any other error messages that appear.
Remember that you will probably need root privileges to run fsck on a specific card. See the discussion above about sudo if you get an error like the following:
bash-2.05# fsck.vfat -v -t -a /dev/mmcda1
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
open /dev/mmcda1:Permission denied
bash-2.05#
Okay, now, on to a CF card example. Since my CF card is formatted with ext2, I will use fsck.ext2 to examine the integrity of my CF card. A clean card will show output similar to the following:
bash-2.05# fsck.ext2 /dev/hda1
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/0
/dev/hda1: clean, 11/125488 files, 15851/500440
bash-2.05#
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 above or below, do not immediately conclude that the card is bad! If you get discouraging or alarming output, you may want to take a look at this page, where I have posted examples of misleading output due to benign problems and syntax errors.
If the card is a brand new one, or a used card that we want to reformat, we can use the "fdisk" command to show us whether it already has been partitioned, or has any bad spots on it (as hardware).
Please note that the "fdisk" command is a very powerful, but also dangerous tool, so you should not use it on any media that already has files on it unless you know what you are doing. One of my Linux mentors said that he always uninstalls "fdisk" after he finishes using it, just to make sure he does not do a lot of damage by accidentally invoking it when he does not intend to.
Just the same as with fsck, in order to run fdisk, you first must detach any possible file system by using the "umount" command. Remember to use "umount" without any "un". You then need to wait until the card icon in the bottom tray on your zaurus has disappeared, or no longer shows up in the output of the "df" command, before you enter the fdisk command.
So, for example, to run fdisk on an SD card, the commands you would enter to begin with would be:
bash-2.05# umount /mnt/card
bash-2.05# fdisk -l /dev/mmcda
Or, to run fdisk on an CF card, the commands you would enter to begin with would be:
bash-2.05# umount /mnt/cf
bash-2.05# fdisk -l /dev/hda
Now, since you just want to examine the card, I recommend you make sure to run fdisk with the "-l" flag, as shown above, so you do not take the risks associated with running it interactively.
On ROM 2.38, I have been unable to get an fdisk for any of my SD cards to produce a "perfect" example of what output from fdisk should look like.
So, here is what I believe the output for checking an SD card should look something
like (where I used "nnn" in lieu of the numbers that should appear):
bash-2.05# umount /mnt/card
bash-2.05# fdisk -l /dev/mmcda
Disk /dev/mmcda: nnn heads, nn sectors/track, nnnn cylinders
Units = cylinders of nnnn * 512 = nnnnnn bytes
Device Boot Start End Blocks Id System
/dev/mmcda1 * 1 nnn nnnnnn 6 FAT16
bash-2.05#
Here is a real example of the output when I ran fdisk on a new vfat SD card. Note that fdisk complained about a problem with Partition 1 on a brand new vfat card. This is just a warning that is not critical, which means there is a little bit of unused space at the end of the card. What counts are the numbers and any other messages that may appear.
bash-2.05# umount /mnt/card
bash-2.05# fdisk -l /dev/mmcda
Disk /dev/mmcda: 16 heads, 63 sectors, 970 cylinders
Units = cylinders of 1008 * 512 bytes
Device Boot Start End Blocks Id System
/dev/mmcda1 1 971 488840+
6 FAT16
Partition 1 does not end on cylinder boundary:
phys=(970, 2, 34) should be (970, 15, 63)
bash-2.05#
I do not recommend running fdisk interactively unless you definitely plan on reformatting the card and have read the resources I have listed below. However, in case you accidentally forget to put the "-l" flag in, you can enter the "p" command so that it will "print" (i.e. display) the card's contents. When it prompts you for the next command, you can enter a "q" to quit or exit without taking any action. Here is sample output from checking a CF card with fdisk interactively:
bash-2.05# umount /mnt/cf
bash-2.05# fdisk /dev/hda
Command (m for help): p
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
Command (m for help): q
bash-2.05#
If you get discouraging or alarming output from fdisk, you may want to take a look at this page, where I have posted examples of misleading output due to benign problems and syntax errors for both fsck and fdisk. Most of the errors shown there have been due to using the wrong name for the media, so double check your "fdisk -l" to make sure that you use /dev/hda or /dev/mmcda without a number at the end of the device name.
The idea seems to be that if you are having trouble with a card, you do everything you can to let fsck repair the problem. You can use the fdisk and the badblocks commands to help ascertain the nature of the problem. The badblocks command can also be directed to repair bad blocks, but I have no experience using it, except to hunt for bad blocks, and I have not found any that needed repairing.
If you run fsck a few times with repairs enabled, and the problem is not resolved, then chances are that there is either a broken file system, or a hardware problem. In either case, the problem usually can only be resolved by backing up the contents of the card, repartitioning and reformatting it, and then copying your data back to the card. See the resources below for instructions on how to repartition and reformat a card.
If you find any errors or unclear sections on this page, please notify me.
Here are some resources with more information related to this topic:
http://www.oesf.org/index.php?title=SD_And_CF_FAQ (see note below)
http://www.oesf.org/index.php?title=Step-by-step_CF/SD_fdisk/formatting_for_newbies (see note below)
http://tldp.org/LDP/abs/html/system.html
Partitioning with fdisk
http://tldp.org/HOWTO/Partition/fdisk_partitioning.html#fdisk
Recovering a Deleted Partition Table
http://tldp.org/HOWTO/Partition/recovering.html
NOTE: The wiki pages at oesf have been subject to spammers. If you find either of the above two pages at oesf to have been defaced, please notify an admin at oesf or log in and restore the page if you are registered at the wiki. If you urgently need the information, you also should be able to retrieve it from the Wayback Machine at http://www.archive.org/index.php, or you can contact me.