GRUB Image Files

GRUB consists of several images: a variety of bootstrap images for starting GRUB in various ways, a kernel image, and a set of modules which are combined with the kernel image to form a core image. Here is a short overview of them:

boot.img

On PC BIOS systems, this image is the first part of GRUB to start. It is written to a master boot record (MBR) or to the boot sector of a partition. Because a PC boot sector is 512 bytes, the size of this image is exactly 512 bytes.

The sole function of boot.img is to read the first sector of the core image from a local disk and jump to it. Because of the size restriction, boot.img cannot understand any file system structure, so grub-setuphardcodes the location of the first sector of the core image into boot.img when installing GRUB. 

diskboot.img

This image is used as the first sector of the core image when booting from a hard disk. It reads the rest of the core image into memory and starts the kernel. Since file system handling is not yet available, it encodes the location of the core image using a block list format. 

cdboot.img

This image is used as the first sector of the core image when booting from a CD-ROM drive. It performs a similar function to diskboot.img. 

pxeboot.img

This image is used as the start of the core image when booting from the network using PXE. See Network. 

lnxboot.img

This image may be placed at the start of the core image in order to make GRUB look enough like a Linux kernel that it can be booted by LILO using an ‘image=’ section. 

kernel.img

This image contains GRUB's basic run-time facilities: frameworks for device and file handling, environment variables, the rescue mode command-line parser, and so on. It is rarely used directly, but is built into all core images. 

core.img

This is the core image of GRUB. It is built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program. Usually, it contains enough modules to access /boot/grub, and loads everything else (including menu handling, the ability to load target operating systems, and so on) from the file system at run-time. The modular design allows the core image to be kept small, since the areas of disk where it must be installed are often as small as 32KB.

Initrd.img

initrd (initial ramdisk) is a scheme for loading a temporary file system into memory in the boot process of the Linux kernel. initrd and initramfs refer to slightly different methods of achieving this. Both are commonly used to make preparations before the real root file system can be mounted.

How to password protect GRUB?

There are only 3 steps to password protect users to edit grub properties while system booting:

1) Run following command to generate MD5 encrypted password:


root@localhost# grub-md5-crypt
Password:
Retype password:
$1$yAr5c0$ZYlcLULaS2rwOvry1B4gX/


2) Copy MD5 encrypted password of above command

3) Paste copied MD5 encrypted password in menu.list/grub.conf file :

default = 0
timeout=5
password --md5 $1$yAr5c0$ZYlcLULaS2rwOvry1B4gX/

Thats it!!!

Now whenever user's try to run GRUB commands or try to change booting parameters at the time of BOOT, above entered text password will be required!!

Linux : How To Recover From Bad SuperBlock Corrupted Ext3 File System??

I was getting following error:

/dev/cciss/c0d0p1: Input/output error

mount: /dev/cciss/c0d0p1: can't read superblock

In case you are also facing the same error with superblocks, you can follow below given steps to recover superblock:

#### dumpe2fs  /dev/cciss/c0d0p1|grep -i superblock

dumpe2fs 1.39 (29-May-2006)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super
  Primary superblock at 1, Group descriptors at 2-2
  Backup superblock at 8193, Group descriptors at 8194-8194
  Backup superblock at 24577, Group descriptors at 24578-24578
  Backup superblock at 40961, Group descriptors at 40962-40962
  Backup superblock at 57345, Group descriptors at 57346-57346
  Backup superblock at 73729, Group descriptors at 73730-73730


Above command output showing back'd up superblock. Now we need to restore from these superblocks

#### fsck -b 8193 /dev/cciss/c0d0p1

If still showing any error continue to restore with next Backup superblock i.e;  24577, 40961 etc....

After successful completion of above command i.e; output will be like this

Free blocks count wrong for group #362 (32254, counted=32248).
Fix? yes
Free blocks count wrong for group #368 (32254, counted=27774).
Fix? yes
..........

/dev/cciss/c0d0p1: ***** FILE SYSTEM WAS MODIFIED *****

 /dev/cciss/c0d0p1: 59586/30539776 files (0.6% non-contiguous), 3604682/61059048 blocks

Now mount your file system

##### mount  /dev/cciss/c0d0p1 /mnt

Thats it!!!

How To Access GNU Screen Session Over SSH??

We can attach a GNU SCREEN session remotely over SSH; in this example we'll open a GNU screen session on host1, and connect to it from host2.

First open and then detach a screen session on host1, named testscreen:

host1 ~ $ screen -S testscreen

Then detach from your screen session with the keyboard combination Ctrl+a+d:

[detached from 3829.testscreen]

Do not "exit" from shell only use Ctrl+a+d to detach from that session. One of the main feature I like about screen is that we can trace whatever user was doing last time (in case of script command a typescript file is created which show the complete working of user)


You can verify that it's still there with this command:

host1 ~ $ screen -ls

There is a screen on:
        3941.testscreen (03/18/2012 12:43:42 PM) (Detached)
1 Socket in /var/run/screen/S-host1.

Then re-attach to your screen session from host2 (because we just detached our session last time not exited, so this will start from the last point were we were detached from session):

host2 ~ $ ssh -t user@host1 screen -r testscreen

You don't have to name the screen session if there is only one :)

Ref: http://www.itworld.com/it-managementstrategy/261500/16-ultimate-openssh-hacks