Linux Superblock: Basic Concept and Troubleshooting

When you create file system on hard drive it will sub divided into multiple file system blocks. Blocks are used for:
* To store user data
* Some blocks used for to store file system's metadata.

The content of files is stored in contiguous blocks of 1024 bytes on a Red Hat Linux System by default (the actual size depends on command line parameters passed to mke2fs when the file system was first created and can be 1024, 2048 or 4096 bytes).

Each file system is different and they have type like ext2, ext3 etc. Further each file system has size like 5 GB, 10 GB and status such as mount status. In short each file system has a superblock, which contains information about file system such as:
* File system type
* Size
* Status
* Information about other metadata structures

The Superblock contains a description of the basic size and shape of this file system. The information within it allows the file system manager to use and maintain the file system. Usually only the Superblock is read when the file system is mounted but each Block Group contains a duplicate copy in case of file system corruption. Amongst other information it holds the:

Magic Number: This allows the mounting software to check that this is indeed the Superblock for an EXT2 file system. For the current version of EXT2 this is 0xEF53.
Revision Level: The major and minor revision levels allow the mounting code to determine whether or not this file system supports features that are only available in particular revisions of the file system. There are also feature compatibility fields which help the mounting code to determine which new features can safely be used on this file system, Mount Count and Maximum Mount Count Together these allow the system to determine if the file system should be fully checked. The mount count is incremented each time the file system is mounted and when it equals the maximum mount count the warning message ``maximal mount count reached, running e2fsck is recommended'' is displayed.
Block Group Number: The Block Group number that holds this copy of the Superblock,
Block Size: The size of the block for this file system in bytes, for example 1024 bytes.
Blocks per Group: The number of blocks in a group. Like the block size this is fixed when the file system is created,
Free Blocks: The number of free blocks in the file system,
Free Inodes: The number of free Inodes in the file system,
First Inode: This is the inode number of the first inode in the file system. The first inode in an EXT2 root file system would be the directory entry for the '/' directory.

The dumpe2fs command displays information from the superblock:

#dumpe2fs -h /dev/sda1
Filesystem volume name: /boot
Last mounted on: "not available"
Filesystem UUID: b8c5462a-76a6-481a-826c-b56e525451bc
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
[ output truncated ]

If for some reason the superblock gets corrupted or becomes unreadable, the entire filesystem becomes unusable. In order to avoid this problem a backup copy of the information contained into the superblock gets stored on the filesystem at regular intervals, depending on the blockize, creating what are actually called the backup superblocks. If the main superblock is not recoverable, there is a chance we can use the information provided by the backup superblocks in order to restore the filesystem to a usable state.

To use a backup superblock, we must first locate them. To locate them, it helps us to know the blocksize used during the filesystem creation.

We can use of the utility mke2fs with the non-destructive option -n in order to see what backup superblocks would be created on the filesystemgiven a certain blocksize:

#mke2fs -b 1024 -n /dev/sda1
Superblock backups stored on blocks:
8194 24578 40962 [ output truncated ]

This will not actually make a filesystem, but will pretend to, displaying the output as if it had made a filesystem using a block-size of 1K.

We can now test the validity of the superblock backup by trying to mount the partition using the information using information provided by the superblock, avoiding the default superblockwhich is presumable corrupted.

#mount -o sb=8194 /dev/sda1 /path-to-mountpoint

If mounts successfuly, then it is likely that only the first superblock is curroupted; the backup superblocks are sane. You can restore the main superblock by running a filesystem consistency check on filesystem:

#e2fsck -b 8194 -B 1024 /dev/sda1

The e2fsck command will ensure that primary superblock is properly updated upon completion of the check.

In the most unlikely case where the most backup superblocks are corrupted you can manually force the rebuild of all superblocks, issuing something like this:

#mke2fs -S -b 1024 /dev/sda1

WARNING: This will force the recreation of all the superblocks and block descriptors only. This means that it will not touch the actual data. For this reason you must apply the right block size to the command. However there is no certainity this will restore the filesystem to an operating state. Use it at your own risk as the very last resort.

How to boot a Red Hat Linux System if either MBR is corrupt or Rescue mode is unavailable:

Sometimes we face a problem when our system fails to boot because of Corrupt MBR and sometimes our luck is so bad that there is no rescue environment available.

In such a case how should we move things such that we are in a position to either repair MBR or recover our Data?

Well, faced with such a situation you should log on to another machine and find a file named stage2_eltorito.

This file is a special stage-2 for grub designed to run CD-ROM instead of a Hard-Drive.

#find / -name stage2_eltorito

You can also locate the "stage2_eltorito" file using the rpm command:

#rpm -ql grub | grep eltorito

Now create a directory and copy the "stage2_eltorito" file into that directory.

#mkdir -p /tmp/iso/boot/grub

Copy the "stage2_eltorito" file into the newly created directory (/tmp/iso/boot/grub):

#cp /usr/share/grub/i386-redhat/stage2_eltorito /tmp/iso/boot/grub

Now create the ISO Image of the "stage2_eltorito" file:

#cd /tmp/iso
#mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o /tmp/grub.iso

You can now burn the /tmp/grub.iso file onto a CD and boot it. From there you can use the full GRUB command-line and restore the MBR if it is curroupted, oe you can just load the config file on the system to get to the normal boot menu and boot your machine.

When you boot your system now using the GRUB iso CD, you will get the grub> prompt as shown below. Set the GRUB Root:

grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83

Find the "grub.conf" file:

grub> find /grub/grub.conf
(hd0,0)

grub> configfile (hd0,0)/grub/grub.conf

This will load the normal grub menu which you can use to boot your machine or do further GRUB maintenance.

Catch: What if the configuration file "grub.conf" is missing?
If the configuration file does not exist, you will need to locate the partitions that contain the kernel and initial RAM-Disk (initrd). Now first set the GRUB Root:

grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83

And then use the tab completion to get the list of all the files in this directory.

grub> cat /TAB

This will cause the GRUB to display a list of all the files contained in that directory. You should see the full names of both the kernel and the initial RAN-Disk. With this information, it should now be possible to construct the kernel and initrd lines, thus booting the system without configuration file:

grub> kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/ rhgb quiet
grub> initrd /initrd-2.6.18-53.el5.img
grub> boot

This will boot the system.

SUID Concept with Demonstration in Red Hat Linux

SUID stands for Set User ID. This means that if the SUID bit is set for any application then your user ID would be set as that of the owner of application/file rather than the current user, while running that application.

That means in case you have an application whose owner is ' root ' and it has its SUID bit set, then when you run this application as a normal user (a user who is not root, and does not have any root credentials), that application would still run as root. Since the SUID bit tells Linux that the the User ID root is set for thisapplication and whenever this application executes it must execute as if root was executing it (since root owns this file).

Let me demonstrate SUID with an example:

If you try to execute a command "useradd" as a normal user, you will get an error as shown below:

$/usr/sbin/useradd user1
-bash: /usr/sbin/useradd: Permission Denied

Now in this case, check the permissions on "useradd" command itself:

$ll /usr/sbin/useradd
-rwxr--r-- 1 root root 74512 Jan 17 2007 /usr/sbin/useradd

The permission set shows that a normal user who is not the owner of the file and belongs to Others category does not have an

execute permission to the "useradd" command.

Now as a root user perform the following operations:

#chmod o+x /usr/sbin/useradd
#ll /usr/sbin/useradd
-rwxr--r-x 1 root root 74512 Jan 17 2007 /usr/sbin/useradd

Now, as a normal user, execute the useradd command again:

$/usr/sbin/useradd user1
useradd: unable to lock password file

Even if others have an execute permission to the "useradd" command, you still get an error "unable to lock password file".

Infact giving write access to others on "/etc/passwd" file will not help and you will get the same error when you try to

execute theuseradd command as ordinary user.

Now what to do????????????

The solution is to set the SUID bit on the "useradd" command as a root user as shown below:

#chmod u+s /usr/sbin/useradd
#ll /usr/sbin/useradd
-rwsr--r-x 1 root root 74512 Jan 17 2007 /usr/sbin/useradd

You will now see a "s" (alphabetically small "s") in place of the execute permission for the owner (i.e. root). This would signify a presence of SUID permission on that command.

Had there been a "S" (alphabetically capital "S") in place of small "s", it would mean that the execute permission is missing from owner's permission for the file.

Now since the SUID bit is set on the "useradd" command, you can now go on to create a user from a normal user's login as shown below:

$/usr/sbin/useradd user1
/usr/sbin/nscd: Only root is allowed to use this option

$grep user1 /etc/passwd
user1:x:508:508::/hime/user1:/bin/bash

Here you might get a warning "/usr/sbin/nscd: Only root is allowed to use this option" after executing the "useradd" command as a normal user, but you need not worry because your user is already created in the system which is shown by the output of grep command on "/etc/passwd" file.

The benefit of setting SUID bit on "useradd" command is that now when you try to execute "useradd" command, the command runs with root's permission and can edit files owned by root.

Note: You need not put Write permission or SUID permission on the files "useradd" command accesses. Only putting SUID on "useradd" command will do the trick.

Catch: Is it possible to include the "useradd" command in a script and then put the SUID for owner and Execute permission for owner and others on the script instead of putting the same permissions on the "useradd" command as we did in the above mentioned steps?

Let's Try:
Remove the SUID bit from the "useradd" command preserving the Execute permission:

#chmod u-s /usr/sbin/useradd
#ll /usr/sbin/useradd
-rwxr--r-x 1 root root 74512 Jan 17 2007 /usr/sbin/useradd

Also write the following script:

#vi /tmp/test
/usr/sbin/useradd user2
grep user2 /etc/passwd

Save the script and put SUID and Execute Permission for User and Others respectively on the script "test" as shown below:

#chmod u+sx,o+x /tmp/test
#ll /tmp/test
-rwsr--r-x 1 root root 46 Jan 17 2007 /tmp/test

Now when you execute the script "/tmp/test" as a normal user, will the "useradd" command inside the script execute?

The answer is "No", as when you try to execute the script, it is "bash shell" which runs the script, and not the normal user.

So the below mentioned command will again give an error as shown below:

$/tmp/test
useradd: unable to lock password file


Warning: The above mentioned example is only to provide information about the working of SUID. Please do not try this on your Production/Support Servers or any other Linux Machines in your Office because it will open a potential Security Loophole using which your Linux Systems could be compromised in many ways.

How to Format a USB Pen-Drive or a USB Flash-Drive in Red Hat Linux

Connect your pen drive to the system running Linux and let it get detected and mounted. Now open a Terminal, and type a command:

#dmesg | tail

Make sure that you have Root priviledges or you login as root to run the above mentioned command or the commands mentioned below:

The command (#dmesg | tail) lets you know what form of drive letters have Linux assingned to your pendrive. Remember pendrive is detected as a sata device so it starts with letter “sd” in Linux. Consider the output of following command at terminal:

sdb: assuming drive cache: write through
SCSI device sdb: 1994752 512-byte hdwr sectors (1021 MB)
sdb: Write Protect is off
sdb: Mode Sense: 23 00 00 00
sdb: assuming drive cache: write through
sdb:sdb1
sd 2:0:0:0: Attached scsi removable disk sdb
sd 2:0:0:0: Attached scsi generic sg1 type 0
usb-storage: devices scan complete

Note the output that have been shown in bold. The 'sdb' is the extension that Linux has assingned to your pen drive. “b” is the unique character that Linux has assingned to sata drive. The above term 'sdb' may differ in your system so make sure you replace the command below with the appropriate term as occur in your system.

Unmount your pendrive using the following command:

# umount /dev/sdb1 (Replace sdb as appropriate)

mkfs i.e make filesystem is the command used to format the pendrive here. so use mkfs.vfat to make a fat file system for your pendrive or mkfs.ext3 to make a Linux filesystem. Use the following command:

#mkfs.vfat -n ‘Label’ -I /dev/sdb1 (Replace sdb as appropriate)

Here Label is the word you want to assign to your pendrive so choose as suites you.

Once processing is done you are done and your pen drive is formatted.

If the Linux Kernel finds Wrong Memory size at the boot time:

The Linux kernel will detect various settings from your computer configuration. This includes the size of memory you have.

In some cases, it will find the wrong size. For example, it could find only 256 MB of memory when in fact you have 512 MB.

The trick here is to specify the amount of RAM memory you have with the "mem=" parameter.

Here is what you would type when your system boots if you have 512 MB of memory:

•use the arrows to select the boot entry you want to modify on the GRUB splash screen at boot time.
•press e to edit the entry. You will find the following entries as shown below:

root (hd0,0)
kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.18-53.el5.img

•use the arrows to go to kernel line
•press e to edit this entry
•Type the entry as shown below at the end of Kernel line:

root (hd0,0)
kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/ rhgb quiet linux mem=512M
initrd /initrd-2.6.18-53.el5.img

•press ESC to go back to the parent menu
•press b to boot this kernel

This will tell GRUB to load the linux kernel with 512 MB of memory.

The above steps will be persistent only for the first boot time. Incase you want to make it permanent i.e. at every time the computer boots then make the same change in the "/etc/grub.conf" file in the kernel line below the Linux Operating System Title.

How to add more Swap Space on Red Hat Linux System if you are left with no free Hard Disk space to create a new partition for Swap

You installed a new Linux system, but forgot to set enough swap space for your needs. Do you need to repartition and reinstall? No, the swap utilities on Linux allow you to make a real file and use it as swap space even if you have no free space to make another swap partition.

The trick is to make a file and then tell the swapon program to use it. Here's how to create, for example, a 512 MB swap file on your root partition (of course make sure you have at least 512 MB free on the filesystem on which you are going to create it):

#dd if=/dev/zero of=/swapfile bs=1024 count=524288

This will make a 512 MB file on your hard drive. You now need to initialize it:

#mkswap /swapfile 524288
#sync

And you can then add it to your swap pool:

#swapon /swapfile

With that you have 512 MB of swap added. Don't forget to add the swapon command to your startup files so the command will be repeated at each reboot.