New versions of fdisk and e2fsprogs

[iamasmith]

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).

[iamasmith]

*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.

[iamasmith]

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).

[iamasmith]

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.

[iamasmith]

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  

[iamasmith]

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

[jerrybme]

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

[iamasmith]

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.

[jerrybme]

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

[iamasmith]

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

[jerrybme]

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

[iamasmith]

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

[jerrybme]

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

[cvmiller]

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...

[katufzed]

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.