Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: [SOLVED] problem mounting partition after data recovery

  1. #11
    Join Date
    Jun 2006
    Beans
    7,419
    Distro
    Ubuntu 8.04 Hardy Heron

    Re: problem mounting partition after data recovery

    Quote Originally Posted by unutbu View Post
    This is just a guess, but perhaps sdb1 is an ext2 partition instead of ext3. The only difference between ext2 and ext3 is the lack of a journal in ext2.
    dmesg complains, "journal_bmap: journal block not found at offset 0 on sdb1" which is consistent with this guess.
    Nice job! I'll have to remember that in the future.

  2. #12
    Join Date
    Sep 2007
    Beans
    183

    Question Re: problem mounting partition after data recovery

    One more thing guys, the fstab in the first line says:

    Code:
    # /dev/sda9
    UUID=d271ff7f-ed90-4a84-9d85-92771e89054b /    ext3 defaults,errors=remount-ro 0       1
    It still sees the partition as ext3 (!)

    How can I fix this?

  3. #13
    Join Date
    Mar 2008
    Beans
    4,714
    Distro
    Ubuntu 9.10 Karmic Koala

    Re: problem mounting partition after data recovery

    sda9 is your root partition. it probably is ext3 so there is nothing to fix there.

    However, it's a good idea to make sdb1 an ext3 partition. The journal may save you if you ever have a power outage or abruptly shut off the computer.
    Code:
    sudo umount /dev/sdb1                     # unmount sdb1
    tune2fs -j /dev/sdb1                      # add a journal to sdb1. Now sdb1 is ext3
    sudo mount -t ext3 /dev/sdb1 /media/sdb1  # test that sdb1 is ext3
    Stop and report back if you encounter any errors.

    To make the change permanent:
    Run
    Code:
    blkid /dev/sdb1
    This should return a line similar to this:
    Code:
    /dev/sdb1: UUID="03a507ee-cdac-4bd9-b438-eccd616b66ed" SEC_TYPE="ext2" TYPE="ext3"
    Notice the UUID="..." part. We'll use that in /etc/fstab:

    Code:
    gksu gedit /etc/fstab
    Add the lines
    Code:
    # /dev/sdb1
    UUID=03a507ee-cdac-4bd9-b438-eccd616b66ed /media/sdb1 ext3 defaults 0 2
    changing "03a507ee-cdac-4bd9-b438-eccd616b66ed" to your real UUID. Next time you boot up sdb1 should be mounted at /media/sdb1.

  4. #14
    Join Date
    Sep 2007
    Beans
    183

    Re: problem mounting partition after data recovery

    Thanks, I will check that and let you know. My major problem is solved, the partition is mounted.

    I will report back the last issue; and then will mark the thread as solved. Thanks again for the help.

  5. #15
    Join Date
    Sep 2007
    Beans
    183

    Exclamation Re: problem mounting partition after data recovery

    Quote Originally Posted by unutbu View Post
    sda9 is your root partition. it probably is ext3 so there is nothing to fix there.

    However, it's a good idea to make sdb1 an ext3 partition. The journal may save you if you ever have a power outage or abruptly shut off the computer.
    [CODE]
    sudo umount /dev/sdb1 # unmount sdb1
    tune2fs -j /dev/sdb1 # add a journal to sdb1. Now sdb1 is ext3
    tune2fs -j /dev/sdb1 says:
    Code:
    tune2fs 1.40.2 (12-Jul-2007)
    The filesystem already has a journal.
    This means that sdb1 is already ext3 but can not be mounted with its native journal. Correct me if I am wrong. Right?

  6. #16
    Join Date
    Mar 2008
    Beans
    4,714
    Distro
    Ubuntu 9.10 Karmic Koala

    Re: problem mounting partition after data recovery

    Hm. I'm not sure why it is saying that there already exists a journal. Please post
    Code:
    tune2fs -l /dev/sdb1
    You might be right -- perhaps the Windows recovery program did create a journal, but it is somehow incompatible with linux's idea of a journal? I really don't know.

    Do you have any extra space where you can backup your sdb1 data? The easiest way to solve this problem may be to back up, then destroy the partition using GParted, create a new ext3 partition, then copy the data back...

    Or we could try editing /etc/fstab first as described in post #13 and just see what happens...
    Last edited by unutbu; July 19th, 2008 at 01:19 PM.

  7. #17
    Join Date
    Sep 2007
    Beans
    183

    Talking Re: problem mounting partition after data recovery

    Aaaa, I think I can find another hard disk to make a backup copy and repartition the current disk.
    I will let you know if I could find that then we can forget about the fstab thing.

    But the question still remains why "Diskinterval" can recognize the filesystem. Beside that Diskinterval can read both ext2 and ext3 filesystems.

    Will need some rest Be back soon.

  8. #18
    Join Date
    Sep 2007
    Beans
    183

    Exclamation Re: problem mounting partition after data recovery

    Hi again,
    here is what the tune2fd -l /dev/sdb1 says:

    Code:
    tune2fs 1.40.2 (12-Jul-2007)
    Filesystem volume name:   <none>
    Last mounted on:          <not available>
    Filesystem UUID:          4fce5b0b-5ef2-4e58-9aaf-28fa5575e67c
    Filesystem magic number:  0xEF53
    Filesystem revision #:    1 (dynamic)
    Filesystem features:      has_journal resize_inode dir_index filetype sparse_super large_file
    Filesystem flags:         signed directory hash 
    Default mount options:    (none)
    Filesystem state:         not clean
    Errors behavior:          Continue
    Filesystem OS type:       Linux
    Inode count:              9830400
    Block count:              19633430
    Reserved block count:     981671
    Free blocks:              17971203
    Free inodes:              9691494
    First block:              0
    Block size:               4096
    Fragment size:            4096
    Reserved GDT blocks:      1019
    Blocks per group:         32768
    Fragments per group:      32768
    Inodes per group:         16384
    Inode blocks per group:   512
    Filesystem created:       Tue Sep  4 15:12:06 2007
    Last mount time:          Sun Jul 20 11:10:26 2008
    Last write time:          Sun Jul 20 11:10:26 2008
    Mount count:              3
    Maximum mount count:      24
    Last checked:             Mon Jul 14 13:32:19 2008
    Check interval:           15552000 (6 months)
    Next check after:         Sat Jan 10 12:32:19 2009
    Reserved blocks uid:      0 (user root)
    Reserved blocks gid:      0 (group root)
    First inode:              11
    Inode size:               128
    Journal inode:            8
    Default directory hash:   tea
    Directory Hash Seed:      1d6aeaeb-061b-4c92-b4bb-3a5fdf4be8e1
    Journal backup:           inode blocks
    again it says that sdb1 has already has the journal! It is confusing me again.

  9. #19
    Join Date
    Sep 2007
    Beans
    183

    Question Re: problem mounting partition after data recovery

    Bump

  10. #20
    Join Date
    Mar 2008
    Beans
    4,714
    Distro
    Ubuntu 9.10 Karmic Koala

    Re: problem mounting partition after data recovery

    Note this line in the tune2fs output:

    Filesystem state: not clean
    To try to fix that, let's run fsck:

    Code:
    sudo umount /dev/sdb1         # you must unmount the partition before fsck'ing it
    fsck -p /dev/sdb1
    Report the output if fsck stops with an error. Otherwise,
    try mounting sdb1 again.

Page 2 of 3 FirstFirst 123 LastLast

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •