EnigmaForum: Other Help Topics Topic: Enigma started by: mikshaw Posted by mikshaw on Oct. 27 2005,17:19
I can't figure this one out...it's perplexing. It's an enigma.I've been attempting to build a new uci file using the same method as any other uci i've built. The package runs fine from /opt, and the cloop file is built properly it seems. It mounts and umounts without trouble, and the application runs when mounted. Then I reboot and the file is somehow broken. It's just this particular uci...all others remain intact. Boot into Suse or Slackware and i can chown, chmod, file, and delete, but cannot copy the file. Copying with mc results in "Input/output error (5)". md5sum check in these systems results in the following error:
I boot back into DSL, and i can still mount and run the program. but an md5sum check gives me a similar error:
I thought at first that it was something broken in DSL2.0RC1, but i get the same result rebuilding the package in Suse and booting into a vanilla DSL 1.5. One possible problem is maybe the partition's filesystem has become corrupted...it's ext3 but gets mounted as ext2 in DSL with a warning. This has been the case since the very beginning, though, and as I said no other uci files on that partition have been affected. Another thing i thought is maybe it has to do with the size, since it is larger than any other uci i have made. However, it's nothing compared to the size of open office, so that's probably not the issue. I really have no clue....I used exactly the same method to build this package as i used with all the others, but this one keeps dying. Is it possible that a corrupted file within the package could corrupt the UCI, even after the UCI has been built? Pentium 4, 256mb Frugal DSL 1.5 (base/norestore) on 775mb ext3 partition, 57% used Built once in DSL, and rebuilt in Suse Command used to build (one line): cd opt/ && mkisofs -R -hide-rr-moved -cache-inodes -pad enigma/ | create_compressed_fs - 65536 > ../enigma.uci Posted by ke4nt1 on Oct. 27 2005,19:28
yes, to both...I have had several 'surprises' when using ext2 partitions, that have been unmounted improperly, and/or give the famous "warning" messages.. For the most part, until something REALLY burps, you can ignore those messages, and put off running e2fsck until later. But, ESPECIALLY WITH large extensions and .uci builds, I have seen crazy stuff. and rebuilding the .uci source onto a 'clean' partition, and rebuilding the .uci itself on a 'clean' partition , did solve the issues for me.. Maybe waiting to run e2fsck isn't always such a good idea? Since your 'creating' a MOUNT, and not a file, I'm supposing you can create a corrupt one just as easily as a clean one ? 73 ke4nt Posted by mikshaw on Oct. 27 2005,19:59
The source was built on a reiserfs partition, as all the others were. As far as I can recall, I've been building the cloops on the ext3 partition from the start...copying the program from the reiserfs partition to a work directory on ext3 and then clooping. I suppose maybe i should reformat the partition as ext2? Would that be better than ext3, or do you think it would be good enough just to e2fsck?Maybe i should experiment with DSL on reiser.... Thanks for the input...it seems a little less of a mystery now. Posted by mikshaw on Oct. 27 2005,21:18
Well that seems to have been the problem...it's all good now.I went ahead and formatted as ext2, even though it probably wasn't necessary. I wanted to see what would happen with reiserfs, so i had to format anyway. With reiser i got the dreaded limited shell, so went with ext2. So then i copied everything back and ran e2fsck on it...clean. Then edited fstab in my other 2 systems and added a "2" at the end of the hda4 line so it will be checked each time i boot....probably should have done that originally =o) Thank you for helping....that was a completely unexpected problem, but i'm happy that it was easy to fix. Posted by ke4nt1 on Oct. 27 2005,21:35
I'll have to do a little testing myself on ext3/reiserfs partitions and clooping stuff.. Thanks for your feedback.. Usually, I see the issues on the bigger files.. ( Doom3.uci, UT2004.uci, Quake3.uci, OO-2.0.uci, etc. ) Maybe the smaller ones can 'get away' with working on a possibly corrupt filesystem/index/table, whereas the big builds fail.. Maybe I've been lucky, and not accessed the corrupted portion of the partition when building small ones? 73 ke4nt |