OS and Software > All Things Unix > unknown-block?

unknown-block?

Maybe I'll go back to Windows 3.1. That's the last OS that didn't give me agita all the time...

The error message "Failed to open journal device" indicates that the filesystem on that partition was a journaling filesystem. Unlike traditional filesystems where all meta-data is stored in the same partition as all the files and directories, some journaling filesystems permit the journals to be located in a different partition (used properly this can increase performance).

Regardless whether or not the journals for your filesystem were on the same or a different partition, right now your system can't find them. That doesn't have to mean that they are really missing, it could be just a matter of a change in a symbolic reference.

First step: don't panic! It is unlikely that you lost any data unless you unplugged your second hard drive while it was up and running with mounted partitions. If the disk was cleanly shut down then there is no need for replaying any journaled transactions or to rollback incomplete transactions. In other words, even if the journal is irrecoverably lost, your filesystem isn't and all your files are fine.

Do you know the filesystem type that is used on that partition ? Journaling filesystem in Linux could be jfs, ext3/4, reiser, xfs if not more and that is too much to guess.
Do you have a copy (backup) of the fstab from the time before you removed the second hard drive ? Comparing old and new fstab might be the quickest way to spot the troublesome difference.
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire!

Thanks for your response, (what I understood of it... )

The filesystem is EXT3, and I DOUBT it was mounted when I unplugged it, but I really don't remember. In any case, what is my next step? From what I recall. (Don't really remember, I suffer from CRS... LOL) the only thing I REALLY need is my resume'. There's other kind of important stuff on that partition, but don't remember what until I actually try to access it.....
--
Mom and Crockett... I miss you both!

I think of all the journaling filesystems you picked the easiest one to recover from a lost journal.
The ext3 filesystem uses the ext2 filesystem data structures and adds journaling (which ext2 does not have).

It is therefore possible to mount an ext3 journaling filesystem as an ext2 traditional filesystem. As a safeguard to prevent any harm to the data on the partition (which may hurt subsequent recovery attempts if they turn out to be necessary) I strongly recommend to include the -r option to mount the partition in read-only mode. Assuming your 2nd partition on the 2nd drive is /dev/sdb2 and you have an unused empty directory called /mnt available on your root filesystem you would use a command like this (with root privileges):

mount -r -t ext2 /dev/sdb2 /mnt

This would allow you to get read-only access to the files on that partition.
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire!

HUH?

sudo mount -r -t ext2 /dev/sdb2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

sudo dmesg | tail
[ 55.826572] input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5
[ 55.826640] input: HDA Intel Front Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6
[ 55.826696] input: HDA Intel Rear Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input7
[ 55.826751] input: HDA Intel Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
[ 55.826805] input: HDA Intel Line-Out Side as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
[ 55.826859] input: HDA Intel Line-Out CLFE as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
[ 55.826913] input: HDA Intel Line-Out Surround as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
[ 55.826968] input: HDA Intel Line-Out Front as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
[ 66.536010] eth0: no IPv6 routers present
[ 1097.414319] EXT2-fs (sdb2): error: couldn't mount because of unsupported optional features (4)

--
Mom and Crockett... I miss you both!

Looks like there is an option used in your filesystem that the ext2 filesystem driver is not happy about (has_journal?). While the tunefs command can be used to change those options that falls in the category of things not to do until your data is safely restored.

Lets try the ext3 filesystem driver but tell it (for now) to ignore the journal (noload option):

mount -r -t ext3 -o noload,ro /dev/sdb2 /mnt

Unfortunately, while the ext3 filesystem driver will not load the journal it may still refuse to mount the filesystem with an error like "No journal on filesystem".
If that happens to you try using the ext4 filesystem driver. The driver is backward compatible with ext2 and ext3 filesystems, so this may work for you:

mount -r -t ext4 -o noload,ro /dev/sdb2 /mnt

If all that fails, please provide some more information about the trouble filesystem such as the output of the following command:

dumpe2fs -h /dev/sda2
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire!

Did I just lose everything on my second partition using the second command? It's not showing up in "computer"

EDIT,: OK, it's back after a reboot, but still the same errors. Can't access it....

EDIT 2:dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda2
Couldn't find valid filesystem superblock.

--
Mom and Crockett... I miss you both!

What do you mean not showing up in "computer" ?
If the mount command is successful your files will be under /mnt or whatever directory you mounted the filesystem to. Simply:

ls /mnt

should show you the files.

The dumpe2fs output is worrying. Either you didn't execute the command with the proper privileges or there is no 2nd partition. What is the output of:

cat /proc/partitions

This should list all partitions and their sizes.

Edit: I mistyped /dev/sda2 (2nd partition on the 1st drive) instead of /dev/sdb2 (2nd partition on the 2nd drive) in the dumpe2fs example. Based on the error message you executed my wrong example.
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire!

Ah, OK. I changed sda to sdb and this is what I got:

Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf686fc1b

Device Boot Start End Blocks Id System
/dev/sdb1 63 245216159 122608048+ 83 Linux
/dev/sdb2 245216160 488392064 121587952+ 83 Linux
lobo@lobo:~$ sudo dumpe2fs -h /dev/sda2
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda2
Couldn't find valid filesystem superblock.
lobo@lobo:~$ ^C
lobo@lobo:~$ sudo dumpe2fs -h /dev/sdb2
[sudo] password for lobo:
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: disk_3_pt_2
Last mounted on:
Filesystem UUID: 3882ad63-84e1-4021-8637-a0351f80cc77
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery 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: 7602176
Block count: 30396988
Reserved block count: 1519849
Free blocks: 11858326
Free inodes: 7570561
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1016
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 256
Filesystem created: Thu Sep 24 14:35:03 2009
Last mount time: Wed May 2 11:04:50 2012
Last write time: Tue Jun 5 22:43:32 2012
Mount count: 467
Maximum mount count: 150
Last checked: Thu Sep 24 14:35:03 2009
Check interval: 3628800 (1 month, 1 week, 5 days)
Next check after: Thu Nov 5 13:35:03 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: b71ca067-e63c-4cd2-b186-b1253c987b34
Journal backup: inode blocks

I see something that says "filesystem state: NOT CLEAN.

Is that the problem?

--
Mom and Crockett... I miss you both!

The reason it's called DISK 3 is because WAY back when I was on Winders (four or five years ago) that's what I called it, but it IS in fact, the second disk

First command:
sudo mount -r -t ext3 -o noload,ro /dev/sdb2 /mnt
[sudo] password for lobo:
mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

Second command, nothing happens and the drive disappears from "computer" until I reboot.
--
Mom and Crockett... I miss you both!

In the first case, did you actually try the dmesg command like the error message suggests ?

In the second case, if nothing happens (meaning you don't get any error message) then it probably succeeded. Have you checked whether your files are in /mnt ?
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire!

1, Yes, about a billion times...:

lobo@lobo:~$ sudo dmesg | tail
[sudo] password for lobo:
[ 2488.665565] Did not find alt setting 1 for intf 0, config 1
[ 2490.668565] Did not find alt setting 1 for intf 0, config 1
[ 2492.671557] Did not find alt setting 1 for intf 0, config 1
[ 2494.674558] Did not find alt setting 1 for intf 0, config 1
[44189.752242] [drm] nouveau 0000:04:00.0: Setting dpms mode 0 on vga encoder (output 0)
[44988.862955] kjournald starting. Commit interval 5 seconds
[44988.863061] EXT3-fs (sdb1): warning: maximal mount count reached, running e2fsck is recommended
[44988.863368] EXT3-fs (sdb1): using internal journal
[44988.863373] EXT3-fs (sdb1): mounted filesystem with ordered data mode
[44991.967978] error: failed to open journal device %s: %ldEXT3-fs (sdb2): unknown-block(0,0)

2, there's NOTHING in the mount folder
(let me try that again and then look in mnt.)
Yup, it's there THANKS. But that only circumvents the problem. ( I can access my resume. THANKS!)
Is there a way to permanently fix this?
--
Mom and Crockett... I miss you both!

Yes, it can be fixed. It may not even be difficult (depends on whether or not there is actual damage or merely the possibility of damage).

Unfortunately for you I'm a very old-school system administrator. This means absolutely no modifications to a damaged filesystem until all the data is backed up properly. My suggestion therefore is that you backup all the files in /mnt (while /dev/sdb2 is mounted) before we proceed to fix the filesystem.
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire!

I haven't backed up EVERYTHING, but I DID make sure to move a copy of my resume to my external drive for safe keeping, JUST IN CASE...lol.

(old school, or ANY school is fine for this dolt!)
--
Mom and Crockett... I miss you both!

Any school is fine ? You asked for it

The right way / best way is to see if we can locate the missing journal so that the journal entries can be used to recover any potentially missing filesystem metadata. This is by no means the only way your filesystem can be repaired but lets try the right way first.

The primary superblock in your filesystem indicates that the journal is at block 0 which is not valid. However since the superblock is vital for a filesystem it is normal for there to be multiple backup copies. The location of the first backup superblock is dependent on the block size. The dumpe2fs output you created earlier shows that the block size in this particular case is 4K (4096 bytes). This places the backup superblock at block 32768.

Don't forget to umount /mnt first (did you finish backing up your data?):

umount /dev/sdb2

Note the umount command will fail if the /mnt filesystem is in use. Don't run the following commands with /dev/sdb2 mounted.

We can get some more details about what the superblock says about the location of the missing journal with the tune2fs command. Don't try any other options except the -l (List) option for now. The tune2fs command can be used to repair as well as ruin a filesystem:

tune2fs -l /dev/sdb2

Still proceeding slow and cautiously, lets get another dumpe2fs output, but this time lets have a look at the contents of a backup superblock:

dumpe2fs -h -o blocksize=4096 -o superblock=32768 /dev/sdb2

To see what would happen if we were running the filesystem check (and repair) utility e2fsck, you can run it with the -n option. This perform all the checking but auto-answers any questions regarding suggested repairs with "no".

e2fsck -n -b 32768 -B 4096 /dev/sdb2

I'm assuming that the filesystem has/had an internal journal (the tune2fs output above may confirm that). If it was an external journal in a different partition we could specify that partition with the -j option. The example specifies the same backup superblock as in the preceding dumpe2fs command. Don't use that backup superblock if the dumpe2fs output does not look reasonable.

Assuming everything looks good you can try an automated repair. Replace the -n with -p and e2fsck will perform all safe repairs that it can determine as needed. If it detects any ambiguities or repairs that may result in the loss of data it will stop with an error message:

e2fsck -p -b 32768 -B 4096 /dev/sdb2

Edit: added tune2fs command for more detail about the location of the missing journal.
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire!

dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: disk_3_pt_2
Last mounted on:
Filesystem UUID: 3882ad63-84e1-4021-8637-a0351f80cc77
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr 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: 7602176
Block count: 30396988
Reserved block count: 1519849
Free blocks: 11858326
Free inodes: 7570561
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1016
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 256
Filesystem created: Thu Sep 24 14:35:03 2009
Last mount time: Wed May 2 11:04:50 2012
Last write time: Tue Jun 5 22:43:32 2012
Mount count: 467
Maximum mount count: 150
Last checked: Thu Sep 24 14:35:03 2009
Check interval: 3628800 (1 month, 1 week, 5 days)
Next check after: Thu Nov 5 13:35:03 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: b71ca067-e63c-4cd2-b186-b1253c987b34
Journal backup: inode blocks

lobo@lobo:~$ sudo e2fsck -n -b 32768 -B 4096 /dev/sdb2
e2fsck 1.42 (29-Nov-2011)
Superblock has an invalid journal (inode 0).
Clear? no

e2fsck: Illegal inode number while checking ext3 journal for disk_3_pt_2

disk_3_pt_2: ********** WARNING: Filesystem still has errors **********

I didn't do your fourth command (to repair/replace) because you said IF IT LOOKS GOOD, which to my eyes, it does not....

Sorry I'm so dense when it comes to this that you must hold my hand and walk me step by step, but thank you again for your patience
--
Mom and Crockett... I miss you both!

The good news is that both the primary superblock and the backup superblock agree on all the vital filesystem data. I consider it a particularly good sign that both superblocks agree on the number of free blocks and free inodes (if they were different it would be more likely that the OS was writing to the disk at the time when you removed it and that can leave the filesystem in an inconsistent state).
It may even have been unmounted at the time and the only reason for the DIRTY flag might be the expiration of the filesystem check interval.

The bad news is that both superblocks agree that the journal inode is invalid (0). It is not serious bad news as in "oh, no we can't recover this filesystem" but it probably means that we will not be able to use the journal. In other words we are going to change the filesystem from ext3 to ext2 and run a filesystem check without journal recovery. Once that is done we can create a new journal and turn it back into a ext3 filesystem.

Before we do that (just to satisfy my own curiosity) can you please run the command:

tune2fs -l /dev/sdb2

(that is lower case L, not upper case i as option letter). I'd like to see on which disk the filesystem thinks the journal should be located.
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire!

tune2fs 1.42 (29-Nov-2011)
Filesystem volume name: disk_3_pt_2
Last mounted on:
Filesystem UUID: 3882ad63-84e1-4021-8637-a0351f80cc77
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery 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: 7602176
Block count: 30396988
Reserved block count: 1519849
Free blocks: 11858326
Free inodes: 7570561
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1016
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 256
Filesystem created: Thu Sep 24 14:35:03 2009
Last mount time: Wed May 2 11:04:50 2012
Last write time: Tue Jun 5 22:43:32 2012
Mount count: 467
Maximum mount count: 150
Last checked: Thu Sep 24 14:35:03 2009
Check interval: 3628800 (1 month, 1 week, 5 days)
Next check after: Thu Nov 5 13:35:03 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: b71ca067-e63c-4cd2-b186-b1253c987b34
Journal backup: inode blocks

It's good that you think it can be saved.

--
Mom and Crockett... I miss you both!

So, the journal disappeared and nobody knows where it went.

With /dev/sdb2 still dismounted use tune2fs to turn the ext3 system into an ext2 filesystem. How ? Simple, all we have to do is to say that it doesn't have a journal (ironic, isn't it ?):

tune2fs -O '^has_journal' /dev/sdb2

This will remove "has_journal" from the list of filesystem features/options. Because the filesystem is marked dirty, tune2fs may complain. You can force it by specifying the -f flag:

tune2fs -f -O '^has_journal' /dev/sdb2

Freeing up any bocks that were reserved for the journal and repairing the filesystem itself is done with e2fsck:

e2fsck -p /dev/sdb2

This put e2fsck into a non-interactive mode where it performs all save recovery actions automatically. We don't need to specify a backup superblock since they agree with each other.
--
Got some spare cpu cycles ? Join Team Helix or Team Starfire!