OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Sharp ROMs => Topic started by: iamasmith on August 26, 2004, 12:43:10 pm
-
You now have the option of installing the test versions via IPK. (sorry you will have to uudecode it after download - it was the only way I could post it here).
Please note that this IPK installs to /usr/sbin and makes no attempt to check for previous files named...
/usr/sbin/fdisk
/usr/sbin/mke2fs
/usr/sbin/mkfs.ext2
/usr/sbin/e2fsck
/usr/sbin/fsck.ext2
/usr/sbin/fsck.ext3
/usr/sbin.tune2fs
So if you have these files installed from another source then you may want to back them up first - or at least determine the original IPK if you wish to roll back !
The package also doesn't attempt to rearrange the PATH variable so please READ the notes attached !
The binaries are identical to the original tests in all but name. In the IPK version I have dropped the -2.12a and -1.35 suffixes.
Please test and report on this thread.
Please report successes as well as failures and please state your model, ROM, ROM rev and Kernel version.
- Andy
/home/root/fsutils.readme.txt from IPK
Firstly a note regarding use..
Once the IPK has been installed it is suggested that you edit your .profile (roots too I would suggest) and rearrange the path order such that /usr/sbin appears before /sbin. This should enable the new tools to be run instead of any preinstalled tools.
This is particularly important with the Cacko ROM since tools of the same name are present in the read only /sbin directory. The install makes no attempt to correct paths for you so it's up to you to ensure that you are running the correct versions of the tools.
Once you have modified the path in qpe.sh restart your console app and check that the path to each tool is correct with the following commands..
which fdisk
which mke2fs
which mkfs.ext2
which e2fsck
which fsck.ext2
which fsck.ext3
which tune2fs
All of these commands should return paths to the /usr/sbin directory versions of the commands. If that is the case then you should pick up the correct versions of the tools by running them.
Please note, do NOT use fsck <dev> to test file systems if you want to use the newer versions of the tools. I would suggest using e2fsck but for your convenience the IPK includes symlinks for fsck.ext2 and fsck.ext3. Please use one of those to test your file systems.
About the tools versions
Original note...
This is a test version and we are looking for "Guinnea Pigs" who don't mind testing these tools on various SD Cards and CF Cards on a variety of Zaurii.
Update of this note - 8th September 2004
Tests thus far are promising. The tools seem to be well behaved and in their limited testing pool have gained approval over the original tools - read the rest of this file for more info.
This IPK release of the tools now names the tools appropriately and places them in the /usr/sbin directory so that they can be called as standard tools in place of the originals.
Note that this is also the default location for the original fdisk ipk present on the ZSI so you will need to reinstall this IPK if you wish to revert to the original. On Cacko ROMs with these tools present in the /sbin directory a simple uninstall should suffice to return to the original tools.
The main point of these tests are...
i. fdisk-2.12a gives accurate geometry readings on some larger cards - observed -(older version 2.11g doesn't).
ii. e2fsck-1.35 seems to handle the journal's in ext3 filesystem correctly - observed - (older 1.19 can destroy firstly the journal pointer and then orphan the inodes composing the journal, this reverts the fs to ext2 when it happens).
iii. mke2fs-1.35 and tune2fs-1.35 are the main tools expected for ext2/3 alongside e2fsck.
I would like experienced Zaurus users to try these out and am interested in providing feedback to Anton Maslovsky regarding suitability for inclusion into the Cacko 1.22 ROM so we really want to know if these tools improve the situation for anyone. - Although I'm not actually involved with the Cacko ROM.
Due to the fact that fdisk 2.11g seems to misdetect the geometry and that e2fsck 1.19 caused problems with some journals I would also be interested in knowing if anyone has been able to ressurect previously dead storage cards.
Final point, this is a test release.
This is not a DR release for people who have major problems with a card and can't use this release without an awful lot of hand holding.
We are looking for people to test this who are capable of running these tools without too much handholding and can provide detailed feedback in the event of problems.
For the interested the build details of these files are :-
fdisk 2.12a was built from util-linux-2.12a downloaded from www.kernel.org - no source modifications, however, one compiler flag (-mstructure-size-boundary=8) was required to get the compiler to produce code without a structure alignment bug.
the e2fs programs were built from e2fsprogs with no modification (no flag needed either) downloaded from the 1.35 link off e2fsprogs.sourceforge.net.
All source unmodified, compiled with devimg-1.5
Let me know your feedback on the forum please (let's keep it to one thread please).
-
*BUMP*
The file is now attached to the first posting.
By the way Maslovsky some of the files in the original archive that I sent you were unstripped, these are all stripped so they are quite a bit smaller.
-
Hi, could I just ask anyone that's using this to just drop a note on this thread to say what they are using it with.
BTW: All modules are compiled as armv4l and the only dependency is libc6, so in theory they should work on all Zaurii.
I'll start, seeing as though I build these tools.
SL-C860 with Cacko 1.21b.
Cards tested.
16Mb Unbranded CF card that came free with my digital camera.
96Mb Kingston CF card.
1Gb IBM Microdrive.
128Mb Unbranded SD Card (lost the box so I can't remember - made in Japan though).
512Mb Jessops (Camera shop in the UK) OEM SD Card (again made in Japan - possibly uses many manufacturers).
All these cards seem to be stable when formatted to ext3, my main focus is the 512Mb SD card and I have filled and stripped and forced checks on the card several times.
BTW: Let me remind you to check the card using e2fsck-1.35 from this package if you are using ext3 otherwise you may get false reports of corruption (i.e. the ext3 journal).
-
OK, for an adventurous test I just forced a byte swap with new version of e2fsck using -fS on an ext2 partition on my 128Mb SD card. This works fine, however, the Z won't mount ext2 unless it's in ordered data mode.
Swapped the card format back and the file system was intact and mounted.
BTW: If you really wish to try this don't do it with ext3, the tool (even on a desktop Linux system) isn't up to doing this and crashes out following a prompt saying that the lost+found directory has an incorrect inode. That's either a limitation of the current e2fsck or of ext3, the important thing is that the tools behave consistently between the desktop version and the Z version.
-
Portability seems to be there, I have just fdisked, created and checked an ext3 file system on an old iPAQ 3660 running Familiar 7.2 Linux so I know that the SA1100 is supported fine.
The only thing that I couldn't do was mount it because this version of Familiar did't have ext2 or ext3, but transferred the card back to the Z and it mounted fine
It would be good to see some responses from people with 5500s..... actually it would be good to see some responses
-
OK, I know of 7 downloads in total, 4 from where I originally uploaded the archive and 3 on this page.
Nobody's tried it after the download ? - Please report anything, we need this thread moving.
Would it help if I produced a test .ipk instead ?
Anyone that's running ext3 on a storage card that doesn't see the need for these tools should probably try 'e2fsck -f <device>' i.e. (e2fsck -f /dev/mmcda1) (DON'T CHOOSE TO FIX THE INODES) with their current tools (-f forces a check) - this shows the problem with the current e2fsck (1.19).
I have had one other tester now trying this with a 5500, unfortunately it turns out that there isn't an ext3 module for the 5500 so he's had to stick with ext2.
The sad fact is that without some reports back of positive success I am not going to generally publish this as a replacement IPK and I'm sure Anton won't take the tools for the new Cacko ROM.... we need to get some broad agreement that these tools are better and wanted.
BTW: It's about a week since I built these tools and started testing, to me they look as stable as the desktop linux versions, I have found only one problem with a function that you are never likely to use (byte swap the file system on ext3 volumes using e2fsck) and this problem is present on the desktop version of the tools. Nothing glaringly problematical like with the existing tools.
Finally: These tools are by no means beta, they are more mature than the existing tools, they just need affirmation that ARM compilation does not introduce some problem that has been introduced during their development since the current community versions. - Haven't found anything yet.
Please help, - Andy
-
iamasmith:
I downloaded your tools set from this thread, but they fail when I try to extract them from the tar ball (after I decode it from uue). I'm not sure what the problem is, tried twice in case it was a corrupted download. Anyone else have problems with the files not extracting? Maybe the decoding process screwed somting up, can you attach just the tar ball without the uue? After all it is a pretty small file anyway.
BTW, I was planning on trying it with the pdaxrom only because that's what is currently on my Z. I've got an old 512 SD card that I'd like to see if it'll bring it back from the dead.
Cheers,
Jerry
-
Did you decompress them using 'bzip2 -d' after uudecoding ?
Just tried it myself from the download...
uudecode fsutils.tar.bz2.uue
bzip2 -d fsutils.tar.bz2
tar -xf fsutils.tar
... no problems.. BTW: The forum didn't allow me to upload a .bz2 file, that's why it's uuencoded.
-
No, I used tar -jxvf I thought the j flag passed the tar file through bzip2. I'll try your method later today.
Thanks,
Jerry
-
Are you unpacking this on your Z, if so then your version of tar is actually linked to busybox and only supports piping through gzip (-zxf) and not bzip2 (-jxf) - bzip2 is an externally linked file.. this version of tar (busybox) doesn't understand that,
Try it as a seperate step if that's what you are doing...
BTW: Good luck with resurrecting the old card.
Just a reminder, I would suggest that you only use e2fsck from this package if you are going to use ext3, more info in the readme file (or posting 1 on this thread).
People using ext3 are definitely going to have problems if they eject with the card marked as dirty (surprise eject rather than dismount) because of the problem with the old versions of fsck.ext/e2fsck. You could e2fsck a cleanly dismounted card with these old tools quite happily and they won't check - therefore, won't produce the problem - it's only if they actually go into a file system check (or you force with -f) that they screw the journal on the card.
- Andy
-
Turns out bzip2 isn't installed on the pdaxrom by default. So I extracted on my pc. Anyway, I took an old Scandisk 512 SD that has lots of badblocks, I reformatted it with ext3 and ran e2fsck. (it had been ext2 before) It stumbled right away on inodes it couldn't read.
BTW, pdaxrom comes with fdisk 1.12. However the SD was screwed up while using Cacko. Anyway, I guess I'll try deleting the partition and recreating it next to see if that helps. Of course it could be that the card truly has badblocks, however, when it first went bad & I couldn't access it or reformat it , I reformatted it in my card reader using Slackware 10 and it worked for a while which makes me suspisciuos that it is not all hardware failure.
Cheers,
Jerry
-
Jerrybme,
Sorry but could I ask you to clarify if you used the new version of e2fsck on your ext3 partition.
I would be particularly interested in any differences that you experience between e2fsck-1.35 and a desktop version.
As I outlined in the readme file 1.19 of e2fsck doesn't seem to recognise the inode pointing at the journal. I have found with my tests that the version that I included seems to be far more reliable.
If you are using e2fsck-1.35 then could you tell me what your desktop system does when you check the partition. (also the desktop version of e2fsck would be good)
Regards,
- Andy
-
Sorry, of course I used your tools, e2fschk & tune2fs not the default ones in the pdaxrom. I'll try with my desktop tomorrow & report back, busy tonight
cheers
-
I just tried you new tools on a Stock SL-6000 (Sharp) ROM. With a 128 MB SD card (No brand, but made in Taiwan).
The utilities worked just fine. Unfortunately the Sharp ROM does not support ext3, so even thought I used mke2fs -j /dev/mmcda1, when mounted the card only showed up as ext2 (which is normal).
I have been fortunate enough (knock wood) to not have any "dead" cards, so I can't help in testing there.
Thanks for all your hard work in getting these utilities up and running,
Craig...
-
Hi all
I've used fdisk2.12a with success on an unbranded 256Mb sd card.
Intersestingly, I am currently testing out OZ3.3.6pre-1 & this comes with fdisk2.11z
fdisk2.11z produces partition errors on my card (sthng to do with overlapping logical partitions), but fdisk2.12a reports no such errors which is good news.
I recently returned a suspect PNY512Mb sd card to ebuyer because I could'nt get it to partition correctly using 2.11g - I'm wondering now if it would've worked with 2.12a
I'll be ordering a replacement SD card soon & will report my findings.
-
OK, nearly a couple of weeks testing and no real problems then,
My cards are certainly holding up well using ext3 with Cacko, I have been using the cards fairly heavily having been away from home for a week and trying to get Ruby 1.8.1 build from source using dev_img-1.5, therefore I have been creating lots of files (make) and deleting them again (make clean) when things didn't work , ah well I'm back now and I can try cross compilation... anyway that't not the point the cards do seem stable and I haven't had any reports of any problems to speak of yet (apart from one person with a generally suspect card).
Please, continue to provide feedback as this will help me gain some confidence that the tools are ready to turn into an .IPK for general use.
Regards,
Andy
-
*BUMP*
Now available in handy (fairly) IPK version !!
(see first posting in this thread)
-
Just picked up a Lexar 512 to replace a dead Sandisk 256. Using Cacko 1.21b, fdisk
reported that the original filesystem was larger than the available space (995 vs 994). Deleted and created a new partition, appeared to work but after a format the partition was gone. Downloaded these new versions and everything worked perfectly. Good Timing! Downloaded and uudecoded on a desktop, 'ipkg-install filename' didn't work, 'ipkg install filename' did.
-
*BUMP*
Now fairly confident that there aren't any real problems with these versions.
If you have the ability to modify the path statement in your .profiles then I would encourage a wider testing audience.
The new version of fdisk particularly seems to have helped a few people out.
- Andy
-
*BUMP*
Now fairly confident that there aren't any real problems with these versions.
If you have the ability to modify the path statement in your .profiles then I would encourage a wider testing audience.
The new version of fdisk particularly seems to have helped a few people out.
- Andy
Great news! This WILL go for sure into the next Cacko ROM...
-
Just formatted a PQI 45X 1Gb SD card with no probs.
(using OZ 3.51 & opie)
-
Ok, I downloaded and installed the package.
# which mkfs
/usr/sbin/mkfs
# which fdisk
/usr/sbin/fdisk
I didn't have to change qpe.sh... it looks like it found the files automatically.
I'm kinda' new to this, so forgive me if I missed something obvious. I'm trying to get my new 1 GB MMC card working on the Zaurus...
In su mode, I type (the card is already unmounted...):
(written by hand. Forgive the typos)
# fdisk /dev/mmcda1
Command (m for help): n
Command action
 e  extended
 p  primary partition (1-4)
e
Partition number (1-4): 1
First cylinder (1-1005, default 1): 1
Last cylinderor +size or +sizeM or +sizeK (1-1005, default 1005): 1005
Command (m for help): w
The partition table has been altered!
Calling ioct1() to re-read partition table.
Syncing disks.
# mkfs /dev/mmcda1
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
129676 inodes, 253504 blocks
12657 blocks (5.00%) reserved for the super user
First data block=0
8 block groups
32768 blocks per group, 32768 fragments per group
15872 inodes per group
Superblock backups stored on blocks:
    21768, 98304, 163840, 229376
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
# mount /dev/mmcda1
mount: Mounting /dev/mmcda1 on /mnt/card failed: invalid argument
If I eject the card and then reinsert it, the MMC/SD card icon never shows up.
I was hoping to get this working with Fat16/32 (so that my digital camera can also see it, but at this point I don't care and I'll go with E2FS if it means I can finally use my card.
My card is:
MyFlash
Multi Media Card
1 GB
A DATA
0408AD6
I've been able to format it and write large files to it from my windows laptop using my USB digital camera to host the MMC card. The Zaurus is able to read from this card and run the movies from it... but it can't seem to write to it, even though Windows appears to via the USB Digital Camera. I was told to try this fdisk and see if that fixes it, which I did above...
Please help me! (Thanks!)
-
Might be worth deleting all of the existing partitions before you start creating new ones.
Also you could try setting the partition type (type m to see what the command should be).
Other than that, not sure.
Si
-
Tony,
I would have suggested that you made a primary partition but it shouldn't stop you from doing what you are doing.
Most of the steps look OK, however, I have found that the Z doesn't recognise ext2 or ext3 from the command line mounts without using the -t parameter.
try..
mount -t ext2 /dev/mmcda1 /mnt/card
You should find that suspending the Z with the card in (or inserting the card) causes a mount that works fine.
BTW: If you are using the Cacko 1.21b ROM then I would suggest ext3 is a better choice.
Use..
mke2fs -j /dev/mmcda1
for ext3 - you do need a ROM/Kernel with an ext3 module though.
Also BTW: The default for a new partition type is 82 (Linux) so if you created a completely new partition table it should be correct for ext2/ext3.
I would suggest a new partitioning scheme starting with the 'o' command in fdisk to clear the existing table, create a new primary partition (number 1) that uses the whole card, use the w command to write the table and you are ready to mke2fs.
Final BTW: The version of mke2fs that mkfs is chaining to is not the version from the IPK, it's not showing 1.35, it is showing 1.19. Try using mke2fs instead of mkfs, I think that your mkfs may be linking against a previous version of mke2fs (not sure but there may be one present in the busybox util).
Hope this helps,
- Andy
-
Might be worth deleting all of the existing partitions before you start creating new ones.
I did that previously... I just forgot to show it.
Also you could try setting the partition type (type m to see what the command should be).
"l" if the command to "list known partition types". It lists 24*4=96 different parition types. I was looking for FAT16 (so that Windows and my digital camera would be able to read it too), but there appear to half a dozen variations of FAT16 in the list, and I don't know which one it is.
When I load up FDISK, it says:
# fdisk /dev/mmcda1
Warning: invalid flad 0x0000 of partition table 5 will be corrected by w(rite)
Command (m for help):
Does that mean that the partition was created incorrectly?
I would have suggested that you made a primary partition but it shouldn't stop you from doing what you are doing.
I agree. I should've gone with primary. I wasn't thinking. If the partition were on the internal flash then it would have to be extended, but this is a separate card, so it wouldn't have needed to be extended. I've gone through this whole process maybe a dozen times anyways and I'll probably do it again, so next time I'll make it primary.
try..
mount -t ext2 /dev/mmcda1 /mnt/card
# mount -t ext2 /dev/mmcda1 /mnt/card
mount: Mounting /dev/mmcda1 on /mnt/card failed: invalid argument
You should find that suspending the Z with the card in (or inserting the card) causes a mount that works fine.
Suspended and restored the unit and the card still wasn't mounted. Also tried reinserting it.
I was in SU when I suspended the unit. Whne it came back on, it said:
#
[1]+  Stopped     su
bash-2.05$
I assume that linux doesn't let SU exist through a suspend/restore. ...but when I type "exit", I have to type it like 3-4 times and it keeps telling me that there are stopped jobs.
BTW: If you are using the Cacko 1.21b ROM then I would suggest ext3 is a better choice.
I'm still hoping for FAT16... since that's what the digital cameras use and Windows would recognize it.
Use..
mke2fs -j /dev/mmcda1
for ext3 - you do need a ROM/Kernel with an ext3 module though.
Is there a FAT16 solution? Which MKFS command is used for FAT16? (I couldn't find a good format command for it)
I would suggest a new partitioning scheme starting with the 'o' command in fdisk to clear the existing table, create a new primary partition (number 1) that uses the whole card, use the w command to write the table and you are ready to mke2fs.
Final BTW: The version of mke2fs that mkfs is chaining to is not the version from the IPK, it's not showing 1.35, it is showing 1.19. Try using mke2fs instead of mkfs, I think that your mkfs may be linking against a previous version of mke2fs (not sure but there may be one present in the busybox util).
# fdisk /dev/mmcda1
Warning: invalid flad 0x0000 of partition table 5 will be corrected by w(rite)
Command (m for help): o
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.
Warning: invalid flad 0x0000 of partition table 5 will be corrected by w(rite)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1005, default 1): 1
Last cylinder or +size or +sizeM or +sizeK (1-1005, default 1005): 1005
Command (m for help): p
Disk /dev/mmcda1: 1038 MB, 1038352896 bytes
32 heads, 63 sectors/track, 1005 cylinders
Units = cylinders of 2016 * 512 = 1032192 bytes
Device Boot Start End Blocks Id System
/dev/mmcda1p1 1 1005 1013008+ 83 Linux
Command (m for help):
Ah.... I just I've figured out something... I need to now change the System ID of the partition from "Linux" to somehting else... I'll try FAT16 (ID: 6).
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 6
Changed system type of partition 1 to 6 (FAT16)
Command (m for help): w
The partition table has been altered!
Calling ioct1() to re-read partition table.
WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
#
Ok... now how do I format it to 1 GB FAT16 in the terminal?
# mkfs.vfat /dev/mmcda1
mkfs.vfat 2.8 (28 Feb 2001)
# mount /dev/mmcda1
#
The card shows up!
bash-2.05$ cd /mnt/card
bash-2.05$ mkdir test
mkdir: Cannot create directory 'test': Read-only file system
bash-2.05$
We've now come in full circle. This is what I got previously when I put the card in the Zaurus directly from the having formated it in my Digital Camera (via Windows).
Why does Linux think this is a read-only file system? I think THAT might be the real problem here... Did I choose the wrong Partition type? (If so, which FAT16 in the long list should I have chosen?). ...Does the Zaurus work with Fat16 MMC/SD cards?... or is everyone going to EXT2/3?
Also, what's the advantage of EXT2/3 over FAT16? Does it have a journaling filesystem? What else?
Thanks for your help!!
-
Is there a FAT16 solution? Which MKFS command is used for FAT16? (I couldn't find a good format command for it)
mkfs.msdos
Greg
-
Did I choose the wrong Partition type? (If so, which FAT16 in the long list should I have chosen?). ..
Just in case you need it...
6
(will select Fat-16 in fdisk)
Greg
-
mkfs.msdos
# umount /dev/mmcda1
# mkfs.msdos /dev/mmcda1
mkfs.msdos 2.8 (28 Feb 2001)
mkfs.msdos: Attempting to create a too large file system
#
I think that mkfs.msdos is FAT12 and mkfs.vfat is FAT16.
...but why is my VFAT partition set up as read-only? Why? Do I need to do something with CHMOD or something?
Thanks.
-
Here Tony, I had some trouble finding this:
http://www.zaurususergroup.com/modules.php...20for%20newbies (http://www.zaurususergroup.com/modules.php?op=modload&name=phpWiki&file=index&pagename=Step-by-step%20CF%2FSD%20fdisk%2Fformatting%20for%20newbies)
Hope it helps
Greg
-
# fdisk /dev/mmcda1
I note you keep writing this, hopefully it's just a typo, as it should be this:
fdisk /dev/mmcda
as mmcda1 is a partition and fdisk works on the device.
umount and mkfs.* work on partitions, so in these cases mmcda1 is correct.
Si
P.S.
I'll try FAT16 (ID: 6).
BTW this is the right one to use.
-
Here Tony, I had some trouble finding this:
http://www.zaurususergroup.com/modules.php...20for%20newbies (http://www.zaurususergroup.com/modules.php...20for%20newbies)
Thanks. I found this site previously and it gave me the base knowledge I was using here. It doens't offer a solution to this "read-only file system" problem...
What is a "read only file system"? Why would Linux ever have one? Is linux incorrectly reading the device as ROM? Is there a internal data setting for this on the MMC card?
QUOTE
# fdisk /dev/mmcda1
I note you keep writing this, hopefully it's just a typo, as it should be this:
fdisk /dev/mmcda
as mmcda1 is a partition and fdisk works on the device.
Yes, I'm using MMCDA1.
# umount /dev/mmcda
umount: /dev/mmcda: invalid argument
# umount /dev/mmcda1
#
The partitions themselves, from what I understand, are called: MMCDA1P1, MMCDA1P2, etc...
but... having said that, I tried MMCDA for fdisk... and it works!
# fdisk /dev/mmcda
Command (m for help): o
...
It worked... and I noticed that I got an extra cylinder doing it this way (1006 instead of 1005). I then did mkfs.vfat /dev/mmcda (without the 1) and that worked.
Then I did fsck.vfat /dev/mmcda (without the 1) and that worked too...
but...
# mount /dev/mmcda
Can't find /dev/mmcda in /etc/fstab
# mount /dev/mmcda1
mount: Mounting /dev/mmcda1 on /mnt/card failed: Invalid argument
#
So... I think before I was creating a partition within a partition? That might explain the read-only FS status... but why can't I mount the new VFAT FS now?
What is /etc/fstab?
Thanks again!
-
Oops... I misread what you wrote. I tried it again. In SU I did:
* fdisk /dev/mmcda
* mkfs.vfat /dev/mmcda1
* fsck.vfat /dev/mmcda1
(reported 0 files, 0/63359 clusters)
* mount /dev/mmcda1
(The device mounted and the icon showed up)
...but...
# cd /mnt/card
# mkdir test
# ls
test
# rmdir test
# ls
# exit
bash-2.05$ cd /mnt/card
bash-2.05$ mkdir test
mkdir: Cannot create directory 'test': Permission denied
bash-2.05$
Wow! This is the farthest I've ever gotten with this on the Zaurus! Now I only have some strange permissions thing going...
Should I have formated the card outside of SU?
-
I tried formating the card from outisde of SU, but it says:
bash-2.05$ mkfs.vfat /dev/mmcda1
mkfs.vfat 2.8 (28 Feb 2001)
mkfs.vfat: unable to open /dev/mmcda1
bash-2.05$
So... formating can only be done while in SU?
# cd /mnt
# ls -l
lrwxrwxrwx 1 root root 17 Nov 27 2003 card -> usr/mnt.rom/card
lrwxrwxrwx 1 root root 15 Nov 27 2003 cf -> usr/mnt.rom/cf
etc...
# cd /usr/mnt.rom
# ls -l
lrwxrwxrwx 3 root root 16384 Dec 31 1969 card
lrwxr-xr-x 2 root root 0 May 20 2002 cf
etc...
What is 1 Root, 2 Root and 3 Root? Why is the card directory date Dec 31, 1969? Why are the permissions different? Could this by my problem?
-
Try rebooting ur Z & see if that solves the problem.
-
I rebooted the Zaurus and reinserted the card. The card came up with the Documents and Install_Files directories, which is a good sign... it means that Zaurus was able to automatically create them... but I still think there's some weird problem with writing to the card. Check this out:
bash-2.05$ cd /mnt/card
bash-2.05$ ls
Documents Install_Files
bash-2.05$ mkdir test
bash-2.05$ ls
Now you see it, now you don't? I'm guessing the 2nd ls didn't show anything because the card is "busy" trying to finish the mkdir command...
Could it be a bad sectore or 2? I'll try checking it...
-
# umount /dev/mmcda1
umount: /dev/mmcda1: Device or resource busy
#
It looks like I was right... the card is locked up waiting for the mkdir command to complete...
-
Tony,
Could you please say what version comes back with ...
fdisk -v
Regards,
- Andy
-
Could you please say what version comes back with ...
fdisk -v
# which fdisk
/usr/sbin/fdisk
# fdisk -v
fdisk v2.12a
#
It's looking at the right place, and I installed the fdisk at the beginning of this thread... so hopefully that should be the correct version.
# fsck.vfat /dev/mmcda1 -a -t -v -V -w
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Boot sector contents:
System ID "mkdosfs"
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
126976 bytes per FAT (= 248 sectors)
Root directory starts at byte 254464 (sector 497)
512 root directory entries
Data area starts at byte 270848 (sector 529)
63359 data clusters (1038073856 bytes)
63 sectors/track, 32 heads
0 hidden sectors
2028032 sectors total
Starting check/repair pass.
Checking for bad clusters.
Reclaiming unconnected clusters.
Starting verification pass.
Checking for unused clusters.
/dev/mmcda1: 6 files, 0/63359 clusters
#
That means that my Zaurus was able to read and write (at a low level) to and from every single bit on the MMC card, I assume. It also means that it couldn't find any problems with the card, right? (Assuming I'm reading this right... if there WERE problems, I assume it would display them here.) That would mean that the card is fine, and I don't need to worry about returning it, and the problems are os/application related (is that correct? ....I worry since I hear so many stories about bad SD cards... and I got this one for so cheap... I worried that it may have been a dud...)
Above, in the fsck output, it says "2 FATs, 16 bit entries". What does that mean? I thought FAT was the information at the beginning of the partition... how coukd I has 2 of them? ...is one of them a backup copy, or does it indicate that I have 2 partitions with FAT16 on them?
Since I had previously ejected and reinserted the MMC card, I tried my mkdir test again...
# cd /mnt/card
# ls
Documents Install_Files test
# mkdir test2
# ls
#
I think I might be on to something here... The "test" directory I made last night is there (which means it actually wrote it), but when I tried creating "test2", they all disappeared again. Here's what I suspect might be happening (let me know what you think): When the Z writes to the card, it write the data, updates the main FAT but then has problems updating the backup FAT (FAT #2?), so it sits there waiting for something... but when the card is ejected/reinserted then the data and FAT #1 are still there and working fine... until something else needs to update the data and both FATs.
Does sound like a good theory? Would that imply a problem in mksf in how the backup FAT (FAT #2) was created, or would that mean there's a problem with how Linux on Z is writing to the FATs?
Has anyone out there succesfully tested VFAT on a 1 GB MMC on your Zaurus? Maybe this bug only happens past the 1 GB barrier... (should I try repartition to 900 MB and 100 MB partitions?)
Should I try the "Win95 FAT16 (LBA)" instead of "FAT16" (#6)? ...or how about any of the other FAT16 cousins on that long list?
Thanks again for everyone's help so far!
-
Another new finding... The MMC card remains busy whenever I do something that requires the MMC Card's FAT tables to update... until I eject the card. But I noticed that simply suspending the Zaurus has the same effect. Suspending the Zaurus causes Linux to give up on what it was forever waiting for. So... in the QTopia GUI, in the Files tab, I can go to the SD Card (MMC) and see the "test" and "test2" directory I created. I create a "test3" directory and all directories suddenly disappear. I suspend/restore the Zaurus and that same screen suddenly has all of the previous folders, including the new "test3".
Interesting.
If we could only find what Zaurus is attempting/waiting to do, then we could either fix the problem of why it's waiting and/or get Linux to stop attempting to do what it does everytime it updates the FATs.
Any ideas?
-
Whoa, lots of posts :-)
Oops... I misread what you wrote. I tried it again. In SU I did:
* fdisk /dev/mmcda
* mkfs.vfat /dev/mmcda1
* fsck.vfat /dev/mmcda1
(reported 0 files, 0/63359 clusters)
* mount /dev/mmcda1
(The device mounted and the icon showed up)
This is correct.
So... formating can only be done while in SU?
Yes. su allows a user to change to another (super)user. su on it's own changes you to the root user. By default zaurus can't format partitions, only root can (it's a dnagerous process for a normal user to be able to perform). Therefore yes, you must su to root before you can format, etc.
What is 1 Root, 2 Root and 3 Root? Why is the card directory date Dec 31, 1969? Why are the permissions different? Could this by my problem?
No; google up 'man ls' for an explanation. Not sure about the date (I didn't think pre 1969 was possible, odd), but probably not a problem anyway.
bash-2.05$ mkdir test
As FAT has no permissions, the entire partition is automatically owned by root. Therefore only root can write to it by default. To alter this (so zaurus can write to it) edit fstab. This is dangerous, I'd search the forum or get someone to give you the exact flags (can't remember off the top of my head) to add otherwise you may end up not being able to mount anything at all (including the ROM)!
A couple of other points:
If you are currently in a directory on the card, it will be busy and cannot be umounted.
Forcing the umount (or just ejecting it before it has been umounted) may well result in filesystem corruption.
Si
-
Thanks! That was a lot of good information to know.
I tried a variation of the umount...
bash-2.05$ cd /mnt/card
bash-2.05$ ls
Documents Install_Files test test2 test3
bash-2.05$ mkdir test4
bash-2.05$ ls
bash-2.05$ cd ..
bash-2.05$ ls
card cf ide net smb
bash-2.05$ umount /dev/mmcda1
umount: /dev/mmcda1: Operation not permitted
bash-2.05$ umount /dev/mmcda
umount: /dev/mmcda: Invalid argument
bash-2.05$
The problem with umount here appears to be something more than simply being in the directory.
Another test:
After the above input happened, I clicked on the SD icon in the system tray and selected "Eject SD-card". A message window said "Failed to eject the card. Please eject the card after you close all applications and turn off the Zaurus.". When I closed the terminal and clicked on the GUI to eject the card, it umounted (ejected) without a problem.
I reinserted the card and attempted to create a test5 directory, and ls suddenly was empty again. When closed the terminal and reopened it, it was still empty (ie. the resources were still busy).
The system is busy writing to the device (mmc). Somehow it appears to be stuck up on something... but whatever it is stuck up on isn't 100% necessary since the directory appears correctly after the card is ejected/reinserted. Does anyone else think that my theory is on to something here?
Above in my posts I showed the permissions to the mounted mmc card directory. If I'm reading that correctly, that card should be open to the whole world. ..doesn't that mean that there shouldn't be any permissions problems with creating directories in that card?
-
The problem with umount here appears to be something more than simply being in the directory.
Only superusers (root) can umount things.
After the above input happened, I clicked on the SD icon in the system tray and selected "Eject SD-card". A message window said "Failed to eject the card. Please eject the card after you close all applications and turn off the Zaurus.". When I closed the terminal and clicked on the GUI to eject the card, it umounted (ejected) without a problem.
Possibly because of what I said above - was the terminal's current directory somewhere on the card?
I reinserted the card and attempted to create a test5 directory, and ls suddenly was empty again. When closed the terminal and reopened it, it was still empty (ie. the resources were still busy).
Did you check mount to see that it had been mounted?
it was still empty (ie. the resources were still busy
This is not necessarily the reason... I think the id est is possibly a little premature :-)
Above in my posts I showed the permissions to the mounted mmc card directory. If I'm reading that correctly, that card should be open to the whole world. ..doesn't that mean that there shouldn't be any permissions problems with creating directories in that card?
The permissions of the directory on which it's mounted make no difference, fstab is the thing to look at.
Si
-
The problem with umount here appears to be something more than simply being in the directory.
Only superusers (root) can umount things.
I know. I was in SU at the time. Above, whenever you see "#" before the commands, then I'm in SU (logged in as root or super user). Whenever you see "bash-2.05$" then I'm outside of SU. Most of my stuff has been inside SU (just to make sure permissions aren't a problem.
After the above input happened, I clicked on the SD icon in the system tray and selected "Eject SD-card". A message window said "Failed to eject the card. Please eject the card after you close all applications and turn off the Zaurus.". When I closed the terminal and clicked on the GUI to eject the card, it umounted (ejected) without a problem.
Possibly because of what I said above - was the terminal's current directory somewhere on the card?
Yes, I was. Your point was correct.
I did the test again and although it still wouldn't show anything in the card directory (although now sometimes it shows the directory, although without the changes I made in the card directory, such as adding another "test" directory.
...BUT... if I "cd .." then "cd card" then "ls" then the new directory is there.
That's improvement... what happened?
This still doesn't solve the larger problem, though. Why doesn't Linux let ls see the updates until after I leave the directory? What is it trying to do which requires my absence from the directory before doing it?
I reinserted the card and attempted to create a test5 directory, and ls suddenly was empty again. When closed the terminal and reopened it, it was still empty (ie. the resources were still busy).
Did you check mount to see that it had been mounted?
I don't know how to check a mount other than performing a mount/umount. The icon was showing so I assumed it was mounted. So far it's been pretty consistant that the icon shows up when it's mounted and disappears when it is unmounted.
Attempting to delete one of my test folders from the QTopia GUI Files tab (after if asks me if I'm sure) causes the files tab to forever freeze. Forever... meaning it's still frozen now...
fstab is the thing to look at.
Ok. What's fstab? Where is it? How does it work? How do I change/update it?
Thanks!
-
lol
I know. I was in SU at the time.
You sure.... (perhaps it was just a typo in your post?)?:
I tried a variation of the umount...
<snip>
bash-2.05$ cd /mnt/card
bash-2.05$ ls
Documents Install_Files test test2 test3
bash-2.05$ mkdir test4
bash-2.05$ ls
bash-2.05$ cd ..
bash-2.05$ ls
card cf ide net smb
bash-2.05$ umount /dev/mmcda1
umount: /dev/mmcda1: Operation not permitted
bash-2.05$ umount /dev/mmcda
umount: /dev/mmcda: Invalid argument
bash-2.05$
I don't know how to check a mount other than performing a mount/umount.
Just type 'mount' with no arguments.
Ok. What's fstab? Where is it? How does it work? How do I change/update it?
Google for 'man fstab' or similar, far easier than my trying to explain (rusty memory and beer don't help ;-)
Si
-
Hello,
Post the output of
cat /etc/fstab
Greg
-
You are right. Some of my attempts above were in bash but all of the sucessful mont/umounts were in su.
Thanks for letting me know about mount itself.
Here's the output of "cat /atc/fstab"
bash-2.05$ cat /etc/fstab
/dev/mtdblock2 / jffs2 ro,noatime 1 1
/dev/mtdblock3 /home jffs2 defaults,noatime 1 2
none /dev/shm tmpfs size=1m,noauto 0 0
/dev/hda1 /mnt/cf auto noauto,owner 0 0
/dev/mmcda1 /mnt/card auto noauto,owner 0 0
none /dev/pts devpts gid=5,mode=620 0 0
bash-2.05$
Cool...
...so ... what does it mean?
-
...so ... what does it mean?
Well...it means your fstab is ok...
but I don't know what your prob is...sorry
Greg
-
--
-
Maybe my computer just has issues it needs to work through. Maybe it needs to see a phychiatrist or something...
Are there any physical settings/switches on the MMC itself which may need to be adjusted?
-
You are right. Some of my attempts above were in bash but all of the sucessful mont/umounts were in su.
Random point: You realise that bash is the program which you are using, while su simply changes the current user? So normally you run as user 'zaurus', but by using su (without an argument) you become user 'root'.
It's getting late for me. I'll take another look through your posts tomorrow, but I'd be tempted to start afresh (using root for everything, except when you want to prove a point):- remove current partitions, create anew, format, mount, then see what happens (I'm sure you've already done this, but, as I've indicated, I need some time to read through to work out what you were doing and when -- not now, too late, tomorrow.
Si
P.S. I don't think that MMC cards have a read-write tab on the side; If they do it's pretty obvious.
P.P.S you card seems to work after a fashion ;-), it might be worth summarising your current position... then we can go from there; tomorrow.
-
Tony,
Could I firstly ask for the following outputs.
Zaurus type and ROM version.
Type 'mount' on its own with the card mounted, I would like to see what switches it's mounting with. Probably most useful if you just plug in the card and let it automount.
ls -ld /mnt/card
(if symlinked please repeat to the syminked location).
Finally after attempting to write something to the card could you send the last few lines returned by the dmesg command.
Regards,
- Andy
-
Quick note before I address the questions above: In WhatsUpOnZ (version 0.3b) I notice the following threads in the list:So... the Zaurus uses these threads to communicate to the CF and SD/MMC cards? Could there be something wrong with these threads (or are these the drivers?)
Zaurus type and ROM version.
Sharp Zaurus SL-C860. The QTopia ROM that came with the machien from Dynamism. In system info, it says:- Metrowerks OpenPDA, Version: 1.0, Incorporating: <nothing>
- QTopia for OpenPDA, Version: 1.5.4, Compiled by: Trolltech - www.trolltech.com, Built on: Nov 6 2003
- Linux Kernel, Version:, 2.4.18-rmk7-pxa3-embedix, Compiled by: SHARP, ROM Version : 1.20 JP
I'll list the rest from my Zaurus itself (copy and paste is easier that way... )
-
Random point: You realise that bash is the program which you are using, while su simply changes the current user? So normally you run as user 'zaurus', but by using su (without an argument) you become user 'root'.
No, I didn't know that. I had always assumed "su" was the "super user" or "root". Thanjs for the note.
I'll take another look through your posts tomorrow, but I'd be tempted to start afresh (using root for everything, except when you want to prove a point):- remove current partitions, create anew, format, mount, then see what happens (I'm sure you've already done this, but, as I've indicated, I need some time to read through to work out what you were doing and when -- not now, too late, tomorrow.
I gone through the entire process from beginning to end maybe a dozen times during these posts. I have the process memorized now...
P.P.S you card seems to work after a fashion ;-), it might be worth summarising your current position..
My current position/status is that the card can be partitioned, formated, mounted, unmounted, and even pass (assuming I read the ouput I posted above correctly) a full surface scan... but as soon as new data gets written to the card in the Zaurus (this doesn't happen from Windows98) the write process never completes. Suspending th Zaurus appears to kick the frozen process and the changes appear, but until that point the card is locked up and can't be unmounted.
Figuring out what process is locking up during a write attempt to the card and why it is locking up... that sounds like it may be the solution. Outdated driver? 1 GB MMC card limit? (Has anyone known someone to use a 1 GB MMC succesfully in the Zaurus? Are we coming across somthing related to the new size?)
My mount info:
bash-2.05$ mount
/dev/root on / type jffs2 (ro)
/proc on /proc type proc (rw)
/dev/ram1 on /dev type minix (rw)
/dev/mtdblock3 on /home type jffs2 (rw,noatime)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw)
/dev/mmcda1 on /usr/mnt.rom/card type vfat (rw)
bash-2.05$
(My CF card isn't showing up because I don't currently have it plugged in... I'm instead using my CF Wireless card so that I can send this message)
ls -ld /mnt/card
(if symlinked please repeat to the syminked location).
bash-2.05$ ls -ld /mnt/card
lrwxrwxrwx 1 root root 17 Nov 27 2003 /mnt/card -> /usr/mnt.rom/card
bash-2.05$ ls -ld /usr/mnt.rom/card
drwxrwxrwx 12 root root 16384 Dec 31 1969 /usr/mnt.rom/card
bash-2.05$
Finally after attempting to write something to the card could you send the last few lines returned by the dmesg command.
I did:
su
cd /mnt/card
mkdir test9
ls
(all of the previous directories showed up minus the new test9 directory)
...etc... (pages and pages of stuff)
SD]-R 46200 0200 ERROR!
pxa_sd_wait_response: responce time out (cmd=07 MMC_STAT=0x2142)
sd_write_single(1) : select error
sd flush : ERROR adr = 32768 (0x8000) , len = 512 (0x200)
[SD]-R 46200 0200 ERROR!
pxa_sd_wait_response: responce time out (cmd=07 MMC_STAT=0x2142)
sd_write_single(1) : select error
sd flush : ERROR adr = 32768 (0x8000) , len = 512 (0x200)
[SD]-R 46200 0200 ERROR!
pxa_sd_wait_response: responce time out (cmd=07 MMC_STAT=0x2142)
sd_write_single(1) : select error
sd flush : ERROR adr = 32768 (0x8000) , len = 512 (0x200)
[SD]-R 46200 0200 ERROR!
pxa_sd_wait_response: responce time out (cmd=07 MMC_STAT=0x2142)
sd_write_single(1) : select error
sd flush : ERROR adr = 32768 (0x8000) , len = 512 (0x200)
[SD]-R 46200 0200 ERROR!
#
hm... a lot of errors. hm...
-
Tony,
It seems from looking at some of the other threads that this is a common issue with some cards that work well with other devices but not with the Z.
If you have the opportunity I would see if you can exchange the card for a different brand, if not then it may be worth trying to acquire the mmcda driver from the 1.40JP ROM and see if this is updated (I suspect there is a possibility that it may be because there are some SD/MMC fixes in the description). Please note, however, that if you flash 1.40JP then you will probably have to run an English conversion against it to get it back to a workable state for you. Alternatively you could try stripping the driver from the jffs2 image in the update as I believe the base kernel is the same.
Regards,
Andy
-
Ok... now we're getting somewhere! ...although the news isn't good.
So... it's most likely a software/driver issue then. (I thought MMC cards are the same. Maybe all MMC card interfaces are equal, but some are just more equal? )
I can't return the new MMC card... it had a limited time frame to return it and I've already used that up. That's ok, though... if worse comes to worst, then I'll simply use it in my digital camera (mega overkill, though).
Stripping the updated driver out and installing it here on my Zaurus sounds like a good idea. Can anyone help with this? I've never worked with the ROMs before. Is it simply replacing a single file (the SDMGR file I noticed above?)? Where would I find this new ROM?
Should I start a new thread for this, or should this continue here?
-
Tony,
OK, sorry, that was a bit lazy. Have grabbed the driver from this latest ROM and it seems to be the same version as the one in the current Cacko ROM (1.21b).
Drop to the command prompt and type :-
ls -l /lib/modules.rom/2.4.18-rmk7-pxa3-embedix/kernel/drivers/block
If this comes back with a file size for sharp_mmcsd_m.o of 40222 bytes then it sounds like you have the latest driver.
If not then leave a note and I will mail it to you.
Regards,
- Andy
-
No problem... you've already been extremely helpful to me here.
bash-2.05$ ls -l /lib/modules.rom/2.4.18-rmk7-pxa3-embedix/kernel/drivers/block
-rw-r--r-- 1 root root 40222 Oct 10 2003 sharp_mmcsd_m.o
bash-2.05$
*sigh*
Can we be pretty sure, though, that it isn' a hardware issue? If so, then I'm sure that eventually there will be an updated driver.
Am I the first person to try to use a 1 GB MMC card on the Zaurus? If not, has anyone gotten their 1 GB MMC working before?
I think I'll try partitioning it for 900 MB and see if that solves anything (in case the size is the probelm here...)
I AM relieved, though, that this doesn't appear to be due to any defect in the card itself. Since I bought the card for so cheap (less than $100), that was one of my first concerns.
-
Tony,
OK, that's a shame.
One last thing that has worked for some people (in other threads) although if it does work the only logic that I could apply would be some bizarre guesses is.
1. Create the partition table again with fdisk (o, n, primary partition 1, type 04, write).
2. Use mkfs.msdos /dev/mmcda1 (rather than vfat).
3. Eject the card, reinsert and give it a try.
For some inexplicable reason some people have managed to salvage their cards using this format - although why it would cause driver type issues causes for some deep speculation (logic on the card ?).
- Andy
-
My current position/status is that the card can be partitioned, formated, mounted, unmounted, and even pass (assuming I read the ouput I posted above correctly) a full surface scan... but as soon as new data gets written to the card in the Zaurus (this doesn't happen from Windows98) the write process never completes. Suspending th Zaurus appears to kick the frozen process and the changes appear, but until that point the card is locked up and can't be unmounted.
Sorry to labour the point; can you try this:
$ su
# mount /mnt/cf
# cd /
# touch /mnt/cf/test_file
# mkdir /mnt/cf/test_dir
# ls -rtl /mnt/cf
# umount /mnt/cf
# mount /mnt/cf
From what you've said I assume that one or both of mkdir and touch will not finish. If they do, then I assume that what you mean is that the changes won't be made, so ls shouldn't show anything. Your 'cat fstab' doesn't show the cf card so I can't tell whether sync is on or off (I think that's the right parameter), you might try looking into this before giving up - Linux caches disk writes, obviously umount'ing will cause the cache to be flushed to the disk, there's an option you can use in fstab to make writes happen immediately, though it's not recommeded as it can slow things down, but at least it'll eliminate a possibility.
See what happens (I'm sure you're bored of all of this by now, sorry ;-).
Si
-
From what you've said I assume that one or both of mkdir and touch will not finish. If they do, then I assume that what you mean is that the changes won't be made, so ls shouldn't show anything. Your 'cat fstab' doesn't show the cf card so I can't tell whether sync is on or off (I think that's the right parameter), you might try looking into this before giving up - Linux caches disk writes, obviously umount'ing will cause the cache to be flushed to the disk, there's an option you can use in fstab to make writes happen immediately, though it's not recommeded as it can slow things down, but at least it'll eliminate a possibility.
Lardman,
From the boxer-j file in linux/arch/arm/def-configs for the stock kernel source on the SL-C860 1.20JP (and 1.10JP) ROM...
CONFIG_FS_SYNC=y
This pararmeter was added by Sharp to force sync even without the mount options so it's probably going to make little difference with a stock kernel.
- Andy
-
I repartitioned the drive with only 1 100MB partition just to see if size was an issue. The card still acted the same way it did before.
I just read your posts above. I'll try those out and post the results.,
(Thanks )
-
I'm still trying the stuff you mentioned. I reformated using File System Type #4 "FAT16 <16MB" (eventhough I have 1024 MB). All of the old test directories I had made all appeared back on the list. (How do you "format" a drive and whipe the file allocation table clean?... mkfs.msdos didn't appear to do that).
The same problems as before.
One thing I noticed, though... the Documents directory points to itself. I don't think it's a symlink, but instead it appears to be some form of corruption in the FAT table. doing things like "find -name blah" will finally error out because "/Documents/Documents/Documents/ ... /Documents" is too long of a path name. Could this be the cause of the freezing up? (OS attempts to write data to the Documents directory and is never able to due to the infinite loop).
How do you wipe a FAT clean of its history?
I'm getting the other tests...
-
OK Tony,
I think this is getting conclusive, either there's a problem with your SD/MMC slot or there's a driver issue with this card.
Don't suppose you have another card you can try with the Z to rule out the possibility of a duff SD slot ?
- Andy
-
The card works fine from windows, so I would venture that it isn't the card itself.
-
Hm... you mentioned "cf", but I assumed you mean't "card". Let me know if you wanted me to take you literally there or not...
# mount /mnt/card
mount: Mounting /dev/mmcda1 on /mnt/card failed: Device or resource busy
# mount
/dev/root on / type jffs2 (ro)
/proc on /proc type proc (rw)
/dev/ram1 on /dev type minix (rw)
/dev/mtdblock3 on /home type jffs2 (rw,noatime)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw)
/dev/mmcda1 on /usr/mnt.rom/card type vfat (rw)
# cd /
# touch /mnt/card/testfile
# mkdir /mnt/card/testdir
# touch /mnt/card/testfile2
touch: /mnt/card/testfile2: Read-only file system
# ls -rtl /mnt/card
lrwxrwxrwx 1 root root 17 Nov 27 2003 /mnt/card -> /usr/mnt.rom/card
# mkdir /mnt/card/testdir2
mkdir: Cannot create directory `/mnt/card/testdir2': Read-only file system
# umount /mnt/card
# mount /mnt/card
-
Yeah sorry for the confusion.
I'm afraid I'm out of suggestions.
The only other thing I can add is that when using pdaXrom (and I think Cacko also to an extent) I used to get io errors on my mmc card when trying to install stuff (making dirs, etc.). This has *never* happened to me using OZ. I've no idea what's different between the two but I presume there's something.
I'm running OZ on my 5500 and 750 so if I can give you any info to compare I'm more than glad to help out.
Sorry I can't be of more help,
Si
-
Tony If I were you I would make this:
#umount /mnt/card
#mkfs.msdos /dev/mmcda
#fdisk /dev/mmcdaCreate new empty dos partition table and new partition
#mkfs.msdos /dev/mmcda1
#mount /mnt/cardI think this will wipe fat tables and if that is the problem you'll have a ok MMC card.
Just an idea don't know if it is good or bad someone of the gurus must say.
-
How do you wipe a FAT clean of its history?
If you want to *really* start over from scratch, you may want to try the following:
$ su
# umount /dev/mmcda1
# dd if=/dev/zero of=/dev/mmcda bs=512 count=20480
That last command will overwrite the first 10MiB of the card with zeros, thoroughly destroying what's left of your MSDOS filesystem. Be prepared for the command to take several minutes (i.e. make sure you're running on AC power and have timed power off set to a large timeout).
If the dd command fails to complete, then you have a hardware/driver problem and no amount of fdisk/mkfs work is going to help. If the dd command succeeds, then partitioning/reformatting should work at that point.
-
Instead what I did is repartitioned the disk and had that new partition start at cylinder 2 instead of 1 (wasting the first cylinder). Now there aren't any directories... but it's still back to the same old problem.
I'm guessing it's some driver issue.
-
OK, that was an interesting portion of the thread, sorry we couldn't help out more Tony.
My main reason for updating these tools was to see if we could effect a positive outcome for people with 'dead cards'.
Unofrtunately it seems that the problem is a little more fundamental and could be either driver related or something related to spec of card/card reader in Z (write voltage for card ?, clocking discrepency ?).
Anyway the tools do seem better at a couple of things, sizing large cards - getting the geometry right and maintaining ext3 file systems.
I think Tony's case illustrates, however, that you still need to be careful with your choice of card and your decision as to format it/repartition it or not.
- Andy
-
Yasen, I tried your idea...
bash-2.05$ su
# umount /mnt/card
# mkfs.msdos /dev/mmcda
mkfs.msdos 2.8 (28 Feb 2001)
mkfs.msdos: Attempting to create a too large file system
# fdisk /dev/mmcda
Unable to read /dev/mmcda
#
I'll try more later...
-
*BUMP*
Offroad geek, do you think this may be better on the download section ?
- Andy
-
I've read this thread over after bricking a 256M Sandisk SD card. I think I did it by suspending the zaurus before the card had finished loading.
I keep getting an error 'Attempting to create a too large file system' regardless if I use mkfs.msdos or .vfat. I think it may be how I'm trying to size the partition. How would I go about formatting the card for 256M? Using the defaults (1-976) doesn't work. I've also tried inputting +255M (256 gives me an error).
I also get an additional message when first running fdisk
'Warning: invalid flac 0x0000 of partition table 4 will be corrected by w(rite).
Any suggestions would be helpful
(Sharp 3.1, fdisk v2.12a)
-
Sounds like your partition table is hosed. You might want to try the following command (as root) to zero out the card's partition table:
dd if=/dev/zero of=/dev/mmcda bs=512 count=1After that you should be able to use fdisk (on /dev/mmcda) to create a "primary" partition, set its type, and save the partition table. Then you can mkfs.* on /dev/mmcda1 (your new partition) and it should work.
The thing that sometimes trips folks up is that the target for the fdisk and dd commands above is /dev/mmcda but the target for the mkfs.* commands is /dev/mmcda1.
-
Hi Kopsis
I had actually done that from your previous post using
dd if=/dev/zero of=/dev/mmcda bs=512 count=20480
with no joy. I don't have the offending card with me at work, but I'll play around with it a bit more when I get home.
I'll document the sequence of steps I've taken a little more clearly than I did in my preceding post.
-
I've read this thread over after bricking a 256M Sandisk SD card. I think I did it by suspending the zaurus before the card had finished loading.
I keep getting an error 'Attempting to create a too large file system' regardless if I use mkfs.msdos or .vfat. I think it may be how I'm trying to size the partition. How would I go about formatting the card for 256M? Using the defaults (1-976) doesn't work. I've also tried inputting +255M (256 gives me an error).
I also get an additional message when first running fdisk
'Warning: invalid flac 0x0000 of partition table 4 will be corrected by w(rite).
Any suggestions would be helpful
(Sharp 3.1, fdisk v2.12a)
You get this warning with a blank partition table.
I would suggest that you try the following.
fdisk /dev/mmcda
o
n
p
1
<cr>
<cr>
t
6
w
That's (o=new partition table, n=new partition, 1=partition 1, p=primary partition, <cr> on first cylinder, <cr> on last cylinder,t=type, 6 (Fat 16), w=write (and quit)).
This should create a new partition table. Then try
mkdosfs /dev/mmcda1
Pop out the card and reinsert to try the automount.
-
Hrmmm
Running Andy's series of commands, everything seemed to be going okay, until mkdosfs /dev/mmcda1 when I got the 'Attempting to create too large a file system error'. Same error if I use mkfs.vfat.
Going back to fdisk immediately gave me an unable to open /dev/mmcda error until I popped the card out and back.
Doing Kopsis' dd command had no effect on the outcome. The error message of the partition table flag persists when starting fdisk.
Doing -p from the fdisk gives the following info:
Disk /dev/mccda: 255 MB, 255852544 bytes
16 heads, 32 sectors/tracks, 976 cylinders
Unites = cylinders of 512 * 512 262144 bytes
with no partitions showing (even after going through the above to make a partition 1)
So it looks like I'm failling to write the new partition information.
Any other tricks I can put this thing through?
Cheers
Cam
-
The dd command is about the lowest level user space access you can get to the SD card. If it can't zero the partition table, there's no reason to expect that fdisk or any other app will work. It sounds to me like you've just managed to find a SD card that is incompatible with the Zaurus SD interface. From what I've seen on this board, that's not entirely uncommon (and is a problem that afflicts other non-Zaurus PDAs as well). There is no fix other than to exchange for a different make of card.
-
Well, nuts....
This card has been working fine for over a year. Mind you it's a SanDisk, so maybe this is just the inevitable happening.
I'll keep randomly poking it to see if I can come up with anything else.
Cam
-
These are noob questions. I am runnning a SL-6000L with the stock sharp rom 1.12. I installed the fdisk212ae2fsprogs135.ipk. I modified the /home/root/.profile file to put /usr/sbin before /sbin on the path line. But when I check to see which tool I am using with which, only the fdisk tool gives me the proper /usr/sbin path.
Question 1. The instructions refer to modifing the roots as well in parenthesies. What are the paths and full names of the roots I need to modify?
Question 2. The instructions refer to modifing the path in qpe.sh. What is the full path to the qpe.sh file?
Thanks to anyone who can help me with this.
-
This is an update to my above post.
I found the /root/.profile file. I used the instructions here
As long as you aren't using a Cacko rom then you can do
CODE
mount -o rw,remount /
To remount the / filesystem read-write.
Make sure you do
CODE
mount -o ro,remount /
when you are finished or you could do something stupid like delete your copy of busybox by mistake.
If you are using a Cacko rom then you will have to learn how to make squashfs or cramfs (depending on cacko rom version) filesystems and create a new /boot/usr.bin - I don't recommend this unless you are ready to reflash your Zaurus if you don't do it correctly.
Stu
from this thread
https://www.oesf.org/forums/index.php?showtopic=10086 (https://www.oesf.org/forums/index.php?showtopic=10086)
to mount the file systme as read/write, and modified the path statement to put /usr/sbin before /sbin. But when checking the path for the tools using which, I got the old /sbin tools. So I renamed all of the undesired tools in /sbin after making the file system read/write again. Checking the path for the tools installed with this ipk now gives me the proper path of /usr/sbin.
A word of warning to anyone trying this. Make sure to reset the filesystem to read-only after you do this. It may save you from days of grief later on.
Now, I realize this is a kluge. I don't know much about unix/linux. Is this a poor way to impliment these tools, or is it just as good as modifying the path variables in the .profile files, or is it better than modifying the path variables?
And does anyone know the full path for the qpe.sh file/folder that is mentioned in the instructions provided by Andy?
I would like to write a complete Howto for this package if I can get the answers to these questions.
-
delete of duplicate post
-
....
And does anyone know the full path for the qpe.sh file/folder that is mentioned in the instructions provided by Andy?
...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=62912\"][{POST_SNAPBACK}][/a][/div]
/opt/QtPalmtop/qpe.sh