When I'm using an external disk and dragging one folder to
the other, the system crashed (the crash may not be
neccessarily related to the dragging).
When the system is rebooted, automount failed. I did:
[gromit:~] root# fsck_ext2 /dev/rdisk1s2
e2fsck 1.33 (21-Apr-2003)
External was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #375 (39,
counted=35).
Fix<y>? yes
Free blocks count wrong (2376059, counted=2376055).
Fix<y>? yes
Free inodes count wrong for group #281 (16226,
counted=16225).
Fix<y>? yes
Free inodes count wrong for group #360 (16298,
counted=16297).
Fix<y>? yes
Free inodes count wrong (14597178,
counted=14597176).
Fix<y>? yes
External: ***** FILE SYSTEM WAS MODIFIED *****
External: 66504/14663680 files (3.1% non-contiguous),
26929142/29305197 blocks
After this, disktool -r doesn't automout the disk. And when
I unpluged and pluged the disk to the computer again (to
see if automount works), and ran disktools, the disk was
accessed for a long time (and Finder is frozen) and after a
few minutes an error message says:
"A disk attempting to mount as Unknown has failed
verification or has failed to mount. Please use Disk Utility to
check the disk and correct any errors"
Currently I'm unable to remount the disk...
System running os-x 10.2.8 on ibook 800 Mhz, 384 MB
ram, with external firewire 120 GB disk attached.
/var/logs/system.log attached
Thanks,
George
/var/logs/system/log
Logged In: NO
Here is manual mount message:
[gromit:~] root# mount -t ext2 /dev/rdisk1s2 /Volumes/
kextload: /System/Library/Extensions/ext2fs.kext loaded
successfully
/sbin/mount_ext2: /dev/rdisk1s2 on /Volumes: Block device
required
Logged In: YES
user_id=595265
George,
First, make sure you are running the final version of 1.0. Previous
versions contained two bugs that could panic/freeze the machine
during a copy.
Second:
disktool -r only refreshes the disk state, so you'll have to do a
manual mount first:
mkdir /Volumes/External
mount_ext2 /dev/disk1s2 /Volumes/External
disktool -r
Note: mount takes a a block device, not a char device as you
specified (rdisk1s2). Also, don't mount directly on Volumes, or you
will surley freak out some part of OS X -- mount on a sub-dir.
Before mounting force an fsck on the disk for good measure:
fsck_ext2 -fy /dev/disk1s2
Please let me know ASAP if you having panics/lock ups with 1.0
final, as that would be very critical. A panic.log file would be very
helpful too.
Thanks.
Logged In: NO
Many thanks for looking into it so quickly and giving such detailed
response. Unfortunately I have already given up and reformatted
the disk to UFS, since I have a flight to catch in a few hours and
just need to bring the data with me. So I'm afraid I can't help
with the tests.
Yes, I'm running v1.0 (15 Nov).
After the last bug report I sent, and before I saw your reply, I
tried to manually fsck the disk, and then mount it. I ran
fsck_ext2 (no options) /dev/rdisk1s2
The fsck will report the identical message as the one attached
above (Free blocks count wrong..free inodes count wrong). I
chose "Y" for all. But then when I tried to mount the disk it fails
and says that some error is still present on the disk. And then
every time I ran fsck, and the same message as above appeared.
The same message is also seen when I did "verify disk" in Disk
Utilities (which I guess ran fsck_ext2 with "no" for the fix
options).
All the time I was specifying /dev/rdisk1s2 instead of /dev/
disk1s2. Could this be the reason of the errorr?
Anyway, I hope this is a one off thing, probably due to some of
my own stupidity. Pity I can't try out your suggestions now since
I've already reformatted the disk :( But thanks for all your help.
best regards,
George Hau
ghau AT eso.org
Logged In: YES
user_id=595265
The corruption may have been due to the bug fixed in 1.0.1
(doesn't look like that problem though). I haven't heard back from
the user, and no other problems have been reported. Closing.