Friday, October 21, 2011

Discussing a particular case of Superblock corruption in Linux

Linux offers you a multi-platform, secure environment suitable for the entire open enterprise and providing features to help you excel in every aspect of competition. It offers a centralized administration to help you manage and make the best possible use of the Linux technology. When it comes to security, Linux is the most widely-accepted operating system because of its top-of-the-line security features. Despite having a range of user-specific benefits, using Linux has a few drawbacks. The Linux file system is often subject to damage or corruption due to various reasons, such as virus infection, hardware malfunction, operating system bugs, etc. As a consequence, the valuable data present on the hard drive becomes inaccessible. To overcome this problem, you need to go for Linux recovery through a reliable third-party utility.     

For instance, you may come across the following error while working using your Linux-based system:

“suse:/# chown -v ryan:ryan /mnt/hdc1
failed to change ownership of `/mnt/hdc1' to ryan:ryan
chown: changing ownership of `/mnt/hdc1': Operation not permitted
suse:/# chmod -v 777 /mnt/hdc1
mode of `/mnt/hdc1' changed to 0777 (rwxrwxrwx)
suse:/# ls -l /mnt/
total 16
drwxr-xr-x 4 root root 16384 1969-12-31 17:00 hdc1
suse:/#”

Causes:
One of the following reasons might be responsible for the above error:
Due to incorrect directory or file attributes, you are unable to change the permissions.
The root directory is damaged, making the disk structure unreadable.
The superblock in the underlying file system is corrupt.

Resolution:

You need to try the following steps to resolve the issue: 

Use the below given command to edit your user ID from the terminal as follows:
 sudo gedit /etc/fstab
In the 'options' section,  provide the following values
umask= 0000
uid= your UID value
gid= your GID value
Now, save the file and exit.
Execute the following command from the terminal
 'sudo umount -a'
Run the command 'sudo mount -a' from the terminal.


If the problem still persists, you should take help of a proficient data recovery Linux utility. These third-party tools carry out an in-depth scan of your hard drive to retrieve all lost, deleted, or inaccessible data without affecting its integrity and other important characteristics. They have a simple, interactive interface design to make recovery easy and facile for the end users. Moreover, they support all mainstream Linux distributions, including Red Hat, SUSE, Debian, Caldera, Mandrake, etc.

Monday, October 17, 2011

Explaining a case of kernel panic in Linux 4 system

While trying to boot your Linux 4 system, you might have seen this on your screen:

ext2fs partition type 0x83. ....ext3-fs: journal inode is deleted....
mount: error 22 mounting ext3 error 2 mounting name switchroot:
mountfailed:22 umount/initrd/dev failed:2 kernel panic - not syncing.”

This error indicates that somehow the beginning of the hard disk has become corrupt. The inode table contains some bad blocks that also include an ext3 journal file’s inode. Although, it is not certain but seems as if the root file system is non-recoverable. If you have a map, you can easily find out other copies of the inode table on the disk. In case the data is present on other file systems, use a disaster recovery boot media or an installation media to boot the system and try to recover data on those file systems by first mounting them and then moving data to another file system or tape.

Data is a valuable asset and if your data is really confidential or critical, you can take help of a reliable data recovery services provider. It is worthwhile to avail good data recovery services, but still they do not guarantee a complete recovery as the disk may have been seriously damaged or crashed.

Another best alternative is to run consistency checks and then try to reformat the drive and reinstall the operating system. Now, after configuring your system, you need to create a bootable CD and backup the entire system on a reliable media. You can now easily use the bootable disc to boot and then restore the system. You should always perform full system backups and that too frequently. This will ensure that you do not lose too much data or if the data is really important, have incremental backups and save them to a different device.

Kernel panic is a serious problem and may occur on any platform that you use.      

Friday, October 7, 2011

Exploring the causes of Superblock corruption in Linux and the possible data loss



A Linux file system consists of blocks. Some blocks store user data or files, while the other blocks store the file system’s metadata. The blocks that contain metadata are called metadata structures. A superblock is the most fundamental metadata structure that includes information about the file system, such as file system type, size, status, information about other meta data structures, etc. This information is critical and sensitive. If a superblock gets damaged or corrupt, you may encounter serious data loss. To overcome this problem and recover all lost invaluable data, you need to go for Linux recovery through a reliable third-party utility.
Suppose you use a Linux-based PC. When you attempt to mount your file system, you may receive the following error message on your screen:
/dev/sda2: Input/output error
mount: /dev/sda2: can't read superblock
Cause:
The above error indicates that there is some corruption in the superblock. This corruption may be caused due to several reasons, such as virus infection, abnormal shutdown of the system, operating system bug, etc.
As a consequence, all your valuable data present on the hard drive would become inaccessible. At this stage, you may use an updated backup to restore all the lost or inaccessible data. However, if the backup is unavailable, you should follow the below mentioned resolution steps.
Resolution:
Linux maintains multiple copies of superblock in the file system. In case if a damage occurs to the primary superblock, you can use these backup copies to restore the corrupt superblock. To resolve the above problem, you need to mount the partition using different superblock:
  • First determine the location of the alternate superblock using the command:
# dumpe2fs /dev/sda2 | grep superblock
You will get the output as shown below:
Primary superblock at 0, Group descriptors at 1-6
Backup superblock at 32768, Group descriptors at 32769-32774
  • Now, try repairing the file system using the backup copy of the superblock as follows:
# fsck -b 32768 /dev/sda2
  • Use ‘Mount’ to mount your file system:
# mount /dev/sda2 /mnt
If the problem still persists, you should take help of a competent data recovery Linux tool. These third-party software help you safely recover every piece of lost, deleted, or inaccessible data from any Linux-based system. They provide a rich and interactive interface that needs no technical expertise for its proper implementation. Moreover, they support Ext4, Ext3, Ext2, FAT32, FAT16, and FAT12 file systems.