#16 system crash/ unable to remount

Crash (44)

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,
Fix<y>? yes

Free blocks count wrong (2376059, counted=2376055).
Fix<y>? yes

Free inodes count wrong for group #281 (16226,
Fix<y>? yes

Free inodes count wrong for group #360 (16298,
Fix<y>? yes

Free inodes count wrong (14597178,
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



  • Nobody/Anonymous


  • Nobody/Anonymous

    Logged In: NO

    Here is manual mount message:

    [gromit:~] root# mount -t ext2 /dev/rdisk1s2 /Volumes/
    kextload: /System/Library/Extensions/ext2fs.kext loaded
    /sbin/mount_ext2: /dev/rdisk1s2 on /Volumes: Block device

  • Brian Bergstrand

    Logged In: YES


    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.

    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.


  • Nobody/Anonymous

    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

    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

  • Brian Bergstrand

    Logged In: YES

    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.

  • Brian Bergstrand

    • status: open --> closed-out-of-date

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks