Friday, 24 December 2010

Red Hat Linux Boot Process

Boot Process, Init, and Shutdown

An important and powerful aspect of Red Hat Enterprise Linux is the open, user-configurable method it uses for starting the operating system. Users are free to configure many aspects of the boot process, including specifying the programs launched at boot-time. Similarly, system shutdown gracefully terminates processes in an organized and configurable way, although customization of this process is rarely required.
Understanding how the boot and shutdown processes work not only allows customization, but also makes it easier to troubleshoot problems related to starting or shutting down the system.

The Boot Process

Below are the basic stages of the boot process for an x86 system:

1.The system BIOS checks the system and launches the first stage boot loader on the MBR of the primary hard disk.
2.The first stage boot loader loads itself into memory and launches the second stage boot loader from the /boot/ partition.
3. The second stage boot loader loads the kernel into memory, which in turn loads any necessary modules and mounts the root partition read-only.
4. The kernel transfers control of the boot process to the /sbin/init program.
5. The /sbin/init program loads all services and user-space tools, and mounts all partitions listed in /etc/fstab.
6. The user is presented with a login screen for the freshly booted Linux system.


When an x86 computer is booted, the processor looks at the end of system memory for the Basic Input/Output System or BIOS program and runs it. The BIOS controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. For this reason it is written into read-only, permanent memory and is always available for use.

Other platforms use different programs to perform low-level tasks roughly equivalent to those of the BIOS on an x86 system.

Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any diskette drives and optical drives present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in the BIOS, and it looks on the master IDE device on the primary IDE bus. The BIOS then loads into memory whatever program is residing in the first sector of this device, called the Master Boot Record or MBR. The MBR is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it.

POST Screen

The first thing to occur in the boot process is the Power-On Self Test (POST) that is performed by the compter's Basic Input/Output System (BIOS), when it is powered on. This self test is just that -- an internal check of the system's internal components. Other architectures may use different ways to accomplish this, but the purpose is identical. This checking normally involves the system RAM, CPUs, video card, hard drives, and other motherboard components. Many other types of internal cards such as RAID cards and various other types of controller cards perform their own self-testing. If errors occur, some form of alert will be generated or sent to a panel or console; the POST uses a series of beeps to indicate the specific error encountered. If all goes well, the BIOS reads the master boot record on the hard disk and loads the program that is found there into memory.

Master Boot Record

MBR Image
The Master Boot Record (MBR) is the first 512 bytes of the boot drive that is read into memory by the BIOS. (This is assuming we are using an x86 architecture.) The first 446 bytes of that 512 will normally contain a low-level boot code that points to a boot loader somewhere else on the disk - it can even point to another hard disk. The next 64 bytes contain the partition table for the disk (four 16-byte entries known as the IBM Partition Table Scheme). Finally, the remaining 2 bytes are the "Magic Number" (used for error detection).

The Boot Loader

A boot loader for the x86 platform is broken into at least two stages. The first stage is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader and load the first part of it into memory.
GRUB has the advantage of being able to read ext2, ext3, and ext4 partitions and load its configuration file — /boot/grub/grub.conf — at boot time.

he purpose of a bootloader is to load the operating system. Many boot loaders are available; however, LILO and GRUB are the most common for Linux. Windows has its own, called the New Technology Loader (NTLDR). You may have at one time or another seen the message "NTLDR is missing"; this is a Windows bootloader error.
Regardless of the bootloader being used, it is important to keep in mind that bootloaders are very complex and easily rendered inoperative by inexperienced users with root access. In my opinion, the best practice is to explore their workings only on machines you are using as sandboxes or in virtual machines to sharpen your skills. One slight typographical error while working with, e.g., grub.conf, and you may be spending more time than you anticipated trying to fix your error; however, this too, can be a great learning experience, as long as it is on a sandbox and you can afford the time.


The most common bootloader program in use today for modern Linux systems is the GRand Unified Bootloader (GRUB). This is the bootloader we will be talking about, here. The GRUB bootloader is a program written to the master boot record and /boot partition of a hard drive that loads the operating system. The bootloader code used to fit in the first 446 bytes of the MBR, but, owing to progressively increasing complexity of operating systems and the need to boot almost any operating system, it has grown in size. Currently, a subset of the bootloader code is written to the MBRi, and the remainder is written to the /boot partition. In addition, the GRUB bootloader is modular in design and works in stages which I will only cover briefly.
The stages of GRUB
GRUB works in stages called Stage1, Stage1_5, and Stage 2. I will give a brief overview of what each stage does.
The stage1 code of GRUB is written within the 512 bytes of the master boot record. Because of the limited size of the master boot record area, GRUB stage1 will usually point to the next stage of GRUB, stage1_5 or stage2. GRUB may or may not need to load stage1_5 depending on the types of filesystems present.
[root@localhost grub]# file stage1
stage1: x86 boot sector, code offset 0x48
Stage1_5 is the intermediate stage between stage1 and stage2. If you look at your /boot/grub area, you should see various stage1_5 files with names of various types of filesystems. Stage1_5 deals with specific types of filesystems, and is named after them. This code will allow the filesystem to be interpreted appropriately.
These are the stage1_5 files located in my /boot/grub directory:
This is the main GRUB image, and will usually reside on the filesystem in the /boot partition at /boot/grub/stage2. It reads the /boot/grub/grub.conf file for configuration information that details how it will load the kernel. It also has an interactive interface that will allow you to troubleshoot, re-install, or modify how GRUB works. Stage2 will present the user with a graphical boot menu entry. If the appropriate key is not pressed in the time allotted to enter the hidden menu, or nothing is selected in the time frame allowed, GRUB will boot the default entry.
GRUB has a really helpful tab-completion feature that you can use to assist you in getting your system up and running if, for example, you have a non-bootable system due to a improperly specified line in your grub.conf file. I have used it in this way many times to get unbootable systems working again.
This file specifies the kernel to load and the initrd image file with all of the modules to load for your system.
Here is a typical grub.conf file for Red Hat Linux:
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/hdb9
#          initrd /initrd-version.img
title Red Hat Enterprise Linux Server   (2.6.18-53.el5)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.el5.img
This file is fairly easy to edit; because of this, it is a common location for errors.
GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else, TAB lists the possible
   completions of a device/filename.]

Nothing but a GRUB prompt - now what do we do? If you're making any changes to this file, remember to print it out first, and make a backup copy; it may save you if you make a typo. You can use the hardcopy to recall the options necessary to boot your machine and fix your mistake. There are various errors, and it pays to become familiar with some of the common ones such as an incorrectly specified kernel name, or a root partition that is improperly designated in this file. If you do see this GRUB prompt, ask yourself this question, "What do I do now to recover my system?" If you have no idea at this point, and you are managing Linux systems, it would probably be a good idea to get on a practice box and create some errors within the grub.conf, and get to know your bootloader. Here's what could be done in the above situation - notice where I hit the key to view my options.
Booting manually with GRUB tab completion
grub> root (hd0,0)                               
 Filesystem type is ext2fs, partition type 0x83

grub> kernel /               
 Possible files are: lost+found grub initrd-2.6.18-8.el5.img
8.el5 config-2.6.18-8.el5 symvers-2.6.18-8.el5.gz vmlinuz-2.6.18-8.el5

grub> kernel /vmlinuz-2.6.18-8.el5  ro root=LABEL=/                                                                                                                    
     [Linux-bzImage, setup=0x1e00, size=0x1ad054]

grub> initrd /                  
 Possible files are: lost+found grub initrd-2.6.18-8.el5.img
8.el5 config-2.6.18-8.el5 symvers-2.6.18-8.el5.gz vmlinuz-2.6.18-8.el5

grub> initrd /initrd-2.6.18-8.el5.img
   [Linux-initrd @ 0xfe8a000, 0x15547c bytes]

grub> boot               
The "root (hd0,0)" specifies the first drive, and the first partition on that drive. On the kernel line, you can type '/', hit , and view your options; after selecting one, type one or more letters (whatever's necessary for a unique name) and let GRUB complete it for you. The additional option of "ro root=LABEL=/" came from my experience of working with Red Hat systems; yours may be different - so you need to examine the options in your grub.conf file. The same thing happens on the initrd line: after the /, hit and let GRUB do the work by listing your possible choices. You may also have to further specify modules and additional options.


Kernel Booting
When GRUB transfers control to the kernel and the kernel is booting, you may see a lot of text output. On Red Hat-based systems, the line in grub.conf specifying the kernel may have an "rhgb quiet" appended to it that prevents this. It stands for "Red Hat graphical boot quiet" and will suppress kernel boot messages. When I need to see boot messages, I interrupt the GRUB cycle by hitting the escape key, hitting 'e' for edit (the procedure to modify the grub kernel arguments is at the bottom of the GRUB screen), and editing the kernel line. Removing the "rhgb quiet" allows me to see the kernel messages so I can determine if any of them are relevant to, e.g., a kernel panic or a similar problem.
What is actually going on at this time is that the kernel is probing your hardware and configuring itself for your hardware. The kernel is also loading modules in the initrd image that it needs to operate your hardware. Note that the information will scroll very quickly up your screen - so, if you believe your problem exists at the kernel level, be sure to watch closely, as this is sure to give you a clue about where your problem lies. Once the kernel is done with its initialization, it starts the system's first process, which is /sbin/init.
[ Much, but not all, of the boot information is available in the /var/log/dmesg file, once you've booted. -- Ben ]


INIT Starting
Init is the first process running on your system. It reads the /etc/inittab file, executes /etc/rc.d/rc.sysinit, then boots into the runlevel as defined in /etc/inittab.
Init starts out with a Process ID (PID) of 1. In the image above, there's a line saying "INIT: version 2.86 booting"; this is /sbin/init taking over at this point in the boot process. On the line right after that one, you see the messages being displayed by the /etc/rc.d/rc.sysinit shell script; as a matter of fact, the entire screen contains messages from that script, so you can get an idea of some of the functions it performs. Init will also normally start several instances of /sbin/getty or /sbin/mingetty, which are your virtual terminals. This is why you can hit + + < F1> through and come up with a virtual terminal.
Next, we will look at the /etc/inittab file, specifically, at the configuration file for Init:
# inittab       This file describes how the INIT process should set up
#               the system in a certain run-level.
# Author:       Miquel van Smoorenburg, 
#               Modified for RHS Linux by Marc Ewing and Donnie Barnes

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)

# System initialization.

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Trap CTRL-alt-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon
Depending on what Init is doing, you may see typical Init script verification messages getting printed to the screen, i.e., [ OK ] or [Failed] to aid in troubleshooting. You may see a message like "Press 'I' to enter interactive startup" (on Red Hat-based systems); this is an indication of rc.sysinit executing, and allows the operator a certain level of control over the still-booting system. rc.sysinit ends with your default runlevel (as defined in /etc/inittab) being started. This is another common place for errors, because servers will usually have the "id:5:initdefault:" line set to 3, so the machine boots to runlevel 3 instead of runlevel 5. Another common place for errors is the line pertaining to "ca::ctrlaltdel:/sbin/shutdown -t3 -r now" commented out to prevent the 3-finger salute ( + + ) from restarting the server. People are human and make mistakes; I have seen typographical errors in both places that can cause problems. Unlike the "mount -a" command, which will alert you if errors exist in your mount points in the /etc/fstab file, executing the command "init q" will reread your /etc/inittab, but will not check for errors in the runlevels themselves; the best way to know if errors exist is to learn this file and to be very, very careful if you decide to modify any of the /etc/rc*/* files.


Runlevel Initializing
When you enter your runlevel, you will see further Init messages being printed to the screen (depending if your machine is configured to do so), again ending with a [ OK ] or [Failed] depending on whether it started successfully or not. These are your startup services within your runlevels. When you look at your /etc/inittab file, you will see a line like "id:5:initdefault:"; this is your default runlevel. The default runlevel on most servers will be set to 3; on desktops, of course, it's set to 5, so we can have an X Window System session start as soon as the system boots up.
To get an overview of what processes get started or stopped for any particular runlevel, we should look within the /etc/rcX.d (where X is your runlevel) directory. Inside these directories, you will see symbolic links to the files in your /etc/init.d/ directory. The file names will be prefixed with either a 'K' or an 'S' (signifying kill or start) for the given daemon at that runlevel. The number immediately after the letter positions the script in the start order, because the processes are started alphabetically. With Red Hat-based systems, the "chkconfig" command will alter the symbolic links to start or stop the daemon in a desired runlevel; the 'S' or 'K' will change appropriately and the number will most likely change as well.


That sums up the outline of the boot process for a typical Linux machine. At this point, you should have a better understanding of what goes on up until the login prompt or dialog on your screen. Last of all, always pay close attention to the details: the machine will most likely tell you what is wrong if you're experiencing problems.




Monday, 15 November 2010

ulimit errors cannot modify limit

after changing the default ulimit values in /etc/profile by adding

ulimit -n 20000
ulimit -i 20000
ulimit -l 10000

if we try to login using another different normal user using ssh we get the following errors:

-bash: ulimit: open files: cannot modify limit: Operation not permitted
-bash: ulimit: pending signals: cannot modify limit: Operation not permitted
-bash: ulimit: max locked memory: cannot modify limit: Operation not permitted

In this case if we just restart the ssh service using:

/etc/init.d/sshd restart

then try to login again the error will be solved.

Friday, 22 October 2010

access windows shared from ubuntu/linux

  1. install smbfs
    1. $sudo apt-get install smbfs
  2. use ‘mount’ to mount the file share
    1. for mount you need to create a local folder that will be the mount point for example create a folder test under /media
    2. then mount the share using
      1. $sudo mount -t smbfs -o username=myusername // /media/test
      2. myusername – is a valid username on the windows machine
      3. the ip address is the ip of the windows machine
      4. sharename is the name given to the share on the windows machine
      5. This will prompt you for the passwor d- the password for myusername on the windows machine
      6. on successful password you will be able to see the contents of the sharedfolder under /media/test
      7. Note: if you this is the first time you are using sudo in this shell session or if sudo has timed out there will be two password prompts first for the sudo next for the share mount. you could avoid this by doing $sudo -v before doing the sudo mount
  3. to umount
    1. $sudo umount /media/test

Monday, 18 October 2010

creating a xen windows vm

Create the image of the windows server installation cd using:

#dd if=/dev/cdrom of=/tmp/windowssrv2k3.iso

0. In your workstation terminal type:
#ssh -X user@systemname

1. first create a partition for the disk using lvm command:

#lvcreate --size 50G --name winshared01_root XenVolGroup01

2. Create a configuration directory /xen/winshared01

3. virt-install --prompt

4. edit the configuration file by changing "boot" from 'c' to 'd'. Also change "sdl" value from 0 to 1 and also "vnc" value from 1 to 0 and adding cdrom as to point to windows image

5. then start the domU using
#xm create winshared01

6. Follow the instructions in windows installation screen

To delete volume group:

lvremove -f /dev/XenVolGroup01/winshared01_root

Monday, 11 October 2010

How to increase size of an LVM inside a xen VM.

First increase the lv in the xen host
lvextend -L +5G /dev/VolGroup/fred 
Log into the VM and use 'parted to create a new disk - This part is only for the new Redhat 5.x servers.
parted (parted) mkpart primary 5363 10.7GB (parted) quit 
Next - This part is only for the new Redhat 5.x servers.
lvm> lvmdiskscan   /
dev/ramdisk        [       16.00 MB]  
/dev/root          [        2.50 GB]
/dev/ram           [       16.00 MB]    
/dev/hda1          [      101.94 MB]    
[        2.38 GB] /dev/ram2            
[       16.00 MB]   /dev/hda2            
[        4.89 GB] LVM physical volume   /dev/ram3             
[       16.00 MB]   /dev/hda3             
[        5.00 GB]
lvm> pvcreate /dev/hda3   Physical volume "/dev/hda3" successfully created
lvm> vgextend VolGroup00 /dev/hda3
Volume group "VolGroup00" successfully extended
lvm> lvextend -L +5G /dev/VolGroup00/LogVol00
Extending logical volume LogVol00 to 7.50 GB
Logical volume LogVol00 successfully resized
lvm> exit 
[root@rednfs01 ~]# resize2fs /dev/VolGroup00/LogVol00 resize2fs 1.39
(29-May-2006) Filesystem at /dev/VolGroup00/LogVol00 is mounted on /;
on-line resizing required Performing an on-line resize of
/dev/VolGroup00/LogVol00 to 1966080 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 1966080 blocks long.  
When you run 'resize2fs' is may come up with a message 'Please run 'e2fsck -f /dev/VolGroup00/dev2_root' first.' then please run the command as requested then rerun the resize2fs command.

Expanding DomU Logical Volumes
Get the Logical Volume name and path:
So you gave your Xen virtual machine a 10GB Logical Volume and not it's not enough eh? This is easy to fix.
We start by using the lvdisplay command to get the path to the Logical Volume
[ root@vs /srv/xen ] lvdisplay
--- Logical volume ---
LV Name /dev/vgsys/lvvirt
VG Name vgsys
LV UUID XMWzWW-oZih-A5uH-91Sa-7l1y-8cqf-18KcNB
LV Write Access read/write
LV Status available
# open 1
LV Size 60.00 GB
Current LE 1920
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2

According to lvdisplay the path to our Logical Volume is /dev/vgsys/lvvirt.

Hot Resizing Logical Volume:

Resizing the Logical Volume is actually very easy, you'll be amazed.
lvresize --size +10G /dev/vgsys/lvvirt
This lvresize command specifies to add 10GB to /dev/vgsys/lvvirt. This will only take a second.
Hot Resizing the filesystem:
resize2fs /dev/mapper/vgsys-lvvirt
That's really it! You can only hot resize if the Filesystem is getting larger. If you need to shrink it then you'll have to take the Volume offline first. Isn't this easier than dealing with partitions that are too small?

Friday, 8 October 2010

Installing Windows on Xen

This article will address installing Windows 2003 server on Xen 3.x running on headless Centos server

The dom0 xen server is headless making it much difficult to transfer the graphical interface.

I thought installing windows was quite easy on xen by following various articles on the internet but it needed some troubleshooting and investigation to clearly install windows on xen as most of the articles show that the vnc or graphical display will automatically pop out. But the reality is that it is quite a task to figure out which options to configure for the display to come out and how to configure the configuration file properly as I struggled without proper errors in case the machine fails to boot as the disk in not bootable error. In that case we need to configure the options 'boot=d' instead of 'boot=c' and also change the cdrom option to the iso file properly in the domU config file. Then also have to do
1) xhost
2) ssh -X
3) virt-install --prompt
and follow the instructions
4) xm destroy
5) edit the configuration file according to the example given below
6) see that sdl = 1 and vnc = 0 is configured in case we need host access directly instead of vnc
7) xm create

At this point if everything is good the graphical installation should pop out on to the workstation. if not check /var/log/xen/qemu*, /var/log/xen/xend.log

Still I can't get VNC to work with the current setup will work on it afterwards if I have time but mainly I've managed to install the windows on xen using sdl.

Preparation Windows image
To create windows installation image is optional, and just describes a way that I’ve set things up that makes it easier to commission more than one VM. You can also use /dev/cdrom instead with the help of virt-manager.
Create a folder for the ISO image. the folder could be named like this /tmp/windows, we’ll use this directory to store a windows dump image from CDROM.
Put your windows installation disc in the CDROM drive.When it’s mounted, issue a command as follows:
dd if=/dev/cdrom of=/tmp/windows/windows-xp.iso
If the CDROM cannot mounted automatically, you might need to mount it yourself. It would take a long time to dump a full windows images depending on the disc’s size.
Create DISK file for Virtual Server
After that, we need to create a disk image file for the virtualized WinXP. Here we store this file in a new sub directory /srv/xen. You might need to create this directory yourself if you are using CentOS. The hard drive of the virtual machine can be created like this:
nice dd if=/dev/zero of=/srv/xen/winxp.img bs=1024k seek=4096 count=0

Dont forget that raw disk is also supported by Xen

If we want to use logical volumes we can create a logical volume as follows:

lvcreate --size 30G --name windowstest_root XenVolGroup01

nstall Windows in Xen Container
Then we can start the installation process with help of virt-install command:
virt-install -n winxp -r 256 -f /srv/xen/winxp.img -b xenbr0 --sdl -v -c /tmp/windows/windows-xp.iso
or we can use the following for interactive install: virt-install --prompt
This command will create a configuration file /etc/xen/winxp, start the new virtual machine, and try to connect to it. Here’s a bit problematic. As you may wonder how we gain the access to windows graphic desktop during the installation.
Generally there are two ways: 1, Using the physic server’s graphic instead. When you have grphic access to physic server, you can use virt-manager’s grphic interface to control the process. 2, You can use VNC client to connect virtual windows XP directly. By default when the installation started, there’s a VNC server running at localhost. It’s configurable in /etc/xen/winxp, you can set which socket it should bind to, and what password can be used to connect this running windows.
Some other adjustings to /etc/xen/winxp are highly recommended. We need to make note that when any error happened, the winxp should be shut down soon not hanging or doing some other crappy things that only god knows.
* ‘on_crash‘ should be changed to ‘destroy‘. * Change the line on_reboot = ‘restart’ to on_reboot = ‘destroy’. This will ensure that Windows doesn’t restart during setup without our permission, which will be required for ACPI support in the guest to be set up properly. * Add file:/var/lib/xen/images/winxp-install.iso,hdb:cdrom,r’, to the list in the line disk = [ ... ] * Add new line boot = ‘d’ (preferably after the line disk = [ ... ].).
name = "winxp" uuid = "821cc805-ecc3-cc1a-20de-79d4bc99c134" maxmem = 256 memory = 256 vcpus = 1 builder = "hvm" kernel = "/usr/lib/xen/boot/hvmloader" boot = "d" pae = 1 acpi = 1 apic = 1 localtime = 0 on_poweroff = "destroy" on_reboot = "destroy" on_crash = "restart" device_model = "/usr/lib64/xen/bin/qemu-dm" sdl = 0 vnc = 1 vncunused = 1 vnclisten = "" vncpasswd = "virtual-chen" keymap = "en-us" disk = [ "file:/srv/xen/winxp.img,hda,w", "file:/tmp/windows/windows-xp.iso,hdc:cdrom,r" ] vif = [ "mac=00:13:34:ae:70:3b,bridge=xenbr0" ] serial = "pty"
Then re-launch the virtual machine with “xm create winxp“,and use VNC to connect the virtual OS, and direct the installation process. When finished, setup tries to reboot, it will instead be shut down. Don’t panic, this is intentional and was created by the line on_reboot = ‘destroy’ that we modified in the config file.
Things to do when installation finished
Now we need to recover the settings that we’ve made to /etc/xen/winxp:
* Change the line boot = ‘d’ to boot = ‘c’
* Change the line on_reboot = ‘destroy’ to on_reboot = ‘restart’
Continue the setup process by restarting the virtual machine with “xm create winxp“. Run through the rest of the normal Windows setup process, for example add the machine to the domain.
Install TightVNC in the guest so that you can access the guest remotely, so that the virtual machine is accessble while we are not logged into the physical machine. Boot the virtual machine with xm create winxp. If successful, the virtual machine will not show a display, but will show up in the results of xm list and you can connect to it with vncviewer,TightVNC, etc.
Trouble shooting
If something goes wrong and you can’t connect via VNC or rdesktop, you can use virt-manager (aka Applications → System Tools → Virtual Machine Manager) to connect directly to the virtual machine’s console and see what it’s doing. Please keep note that using virt-manager depends on graphic destop at the physical server, which always eats lots of system resournces
Following is the forum entry which helped me figure out my error:
Upon further investigation the 'exception looking up...' is a harmless warning.
I changed the configuration file to
on_poweroff = 'preserve' on_reboot = 'preserve' on_crash = 'preserve'
This then allowed me to connect with VNC since the domain is not destroyed on a failed boot or crash. This showed the error message
CDROM boot failure : 0002
I then reverted to the original cdrom access syntax
disk = [ 'file:/etc/xen/win2000.img,ioemu:hda,w', ',hdc:cdrom,r' ]
This then shows the following console output
ata0 master : QEMU ... ata0 slave : Unknown device ata1 master: QEMU CD-ROM ... ata0 slave: Unknown device
CDROM boot failure code : 0003 Boot from CD-Rom failed FATAL: Could not read the boot disk
I know the boot disk is readable, and a bootable Windows 2000 CD. >>>> Anyone any ideas?
I then created a copy of the CD ROM as a disk file, and changed the disk line to read
disk = [ 'file:/etc/xen/win2000.img,ioemu:hda,w', 'file:/etc/xen/win2000.iso,hdc:cdrom,r' ]
And wow! windows boots. Now to get a clean Windows install working fully.
PS. pardon the poor file locations - this is a scratch install until I get everything working.
appologize for taking so long on this, it has taken a bit of infrastructure to be able to set up for testing. As a result, responses shoudl come more quickly now. As I understand it now, your remaining problem is using the CDROM itself vs an iso image file? For this you would need to specify the disk line as:
disk = [ 'file:/etc/xen/win2000.img,ioemu:hda,w', 'phy:/dev/hdc,ioemu:hdc:cdrom,r' ]
Assuming your CDROM drive is /dev/hdc. If it is not you can replace the /dev/hdc piece with the physical location of your cdrom drive on the dom0
YEAH ! Now I can get the console. VNC has a really slow rendering. But "ssh -X" looks nice.

Thursday, 16 September 2010

Complete backup solution implementation

The following is the complete backup solution implemented using combination of amanda and rsync scripts. This is the documentation for the backup process.

Backups are being handled with primary backup server running amanda server package version 3.1.2-1.rhel5.i386 and clients running amanda client packages. Rsync backup script is used for synchronizing amanda configuration files and amanda vtapes (files containing amanda backups) to the remote backup server.

The two backup servers are redbck01 and redbck02. Both are hp proliant DL360 running centos 5.5 with 1.8 Tb of storage and 6 GB memory. redbck01 is primary backup server and redbck02 is the secondary offisite backup server.

Amanda server configuration:
redbck01 is configured as amanda server which runs the configuration 'DailySet1' everynight for backing up the Disk List entries or clients as specified in the disk list file. Amanda configuration files for 'DailySet1' are located in /etc/amanda/DailySet1/ . amanda uses amanda.conf and disklist files located in config directory while running the backup configuration.
The following are some of the lines in /etc/amanda/DailySet1/amanda.conf which define details of backup configuration:
mailto "root" # emails the amanda report after the amanda backup runs_
tpchanger "chg-disk" # tape changer for virtual tapes
tapedev "file://space/vtapes/DailySet1/slots" # the tape device (where the virtual tapes are defined and data is stored)_
tapetype "HARDDISK" # use hard disk instead of tapes (vtape config)
dumpcycle "4 weeks" # the number of days in dump cycle before starting to reuse the tapes
runspercycle 20 # the number of amdump runs in dumpcycle days
tapecycle 25 tapes # the number of tapes in rotation
logdir "/etc/amanda/DailySet1/log" # log directory
define tapetype HARDDISK {
lenght 50000 mbytes # the maximum capacity of each slot is 50 GB * 25 slots = 1.25 TB max
auth "bsdtcp" # use bsdtcp for authentication between amanda server and clients
define dumptype comp-user-tar {
user-tar # we're using comp-user-tar in our disk list entries as the dump type as it uses fast compression
compress client fast } Amanda determines the backup levels by its own algorithm which guarantees full backups of all disklist entries in a dumpcycle and incremental backups according to the necessity.
The following are the disklist entries from the /etc/amanda/DailySet1/disklist file which defines the clients and directories being backup up along with dumptype:
xenora02 / comp-user-tar
clxbld01 /etc comp-user-tar
clxbld01 /root comp-user-tar
clxbld01 /home comp-user-tar
clxbld01 /usr/svn comp-user-tar
clxbld01/usr/local comp-user-tar

Amanda server uses /var/lib/amanda/.amandahosts file to allow the backup clients to connect back to the server when doing restores. Specify fully qualified domain names of all clients as follows:

xenora02 root amindexd amidxtaped

To check and verify the amanda configuration is working without any errors: On redbkc01, run the amcheck tool as amandabackup user:
-sh-3.2$ amcheck DailySet1
To run the backup manually on redbck01, as amandabackup, run amdump to start the DailySet1 backup.
-sh-3.2$ amdump DailySet1
after amdump finishes it will email the report to the specified addresses in the config file.
To find out what has been backed up we can use amadmin tool with find argument for a quich summary of entire backups.
-sh-3.2$ amadmin DailySet1 find
amdump will run automatically every night. Crontab entries for the amandabackup user are:
0 16 * * 1-5 /usr/sbin/amcheck -m DailySet1 # every week day at 4 pm run amcheck to verify the configuration is working
5 21 * * 1-6 /usr/sbin/amdump DailySet1 # every mon-sat at 5 past mid night run the amdump on DailySet1 config
amdump maximum runtime at the current configuration is approximately: 4 hours
Synchronizing redbck01 and redbck02:
Our main approach for backups is that in case of client failure we must be able to recover the data as early as possible without any single point of failure. So for example a client is dead and data has to be restored to the newly created client we can get the data from either redbck01 or redbck02. But as the redbck01 is the primary backup server and is located inside the network it is quicker to recover from it. If in case of a disaster, redbck01 is lost then we can get the data from offsite backup server redbck02 by configuring amanda client accordingly.
Therefore synchronising the data between redbck01 and redbck02 is done by using rsync. Amanda server package is installed in redbck02, the data needed from redbck01 is '/etc/amanda/' which holds amanda configuration files and '/space/vtapes' which holds the backups from clients (Disk list entries). A rsync backup script '' is being used for syncing the data from redbck01 to redbck02 every night.
Crontab entries for user root on redbck01 which runs the rsync script every night are:
#0 0 * * 1-6 /root/ -s /etc/amanda -d redbck02:/etc#0 1 * * 1-6 /root/ -s /space/vtapes -d redbck02:/space
Amanda Client Configuration:
Amanda clients use /var/lib/amanda/.amandahosts file for allowing backup server to connect to the amanda client. So the file must have the following entry of backup server:
Amanda client configuration file is /etc/amanda/amanda-client.conf which is used for connecting to the server for restoring data. It contains details of configuration name, index server (either redbck01 or redbck02 depending on situation), tape_server and authentication protocol information. The following are some of the lines of /etc/amanda/amanda-client.conf which defines the client configuration file.
conf "DailySet1" # your config name
index_server "redbck01." # your amindexd server
tape_server "redbck01." # your amidxtaped serverauth "bsdtcp"
To recover data to the client in the event of data loss or system failure, we can either use primary backup server redbck01 or offsite backup server redbck02. we must specify the configuration, index_server and tape_server details in /etc/amanda/amanda-client.conf file.
after the configuration, as root run amrecover to initiate the data recovery process.
[root@dlxmkt01 ~]# amrecover
AMRECOVER Version 3.1.2. Contacting server on redbck01.
...220 redbck01 AMANDA index server (3.1.2) ready.Setting restore date to today (2010-09-16)200
Working date set to 2010-09-16.200 Config set to DailySet1.501
Host dlxmkt01 is not in your disklist.Trying host dlxmkt01 ...
501 Host dlxmkt01 is not in your disklist.Trying host dlxmkt01 ...501 Host dlxmkt01 is not in your disklist.
Use the sethost command to choose a host to recover
The list of commands below will demonstrate a recovery of a set of different files and directories to the "/tmp/amanda/phooper/" directory. amrecover may not ask for sethost command if the system hostname is fully qualified domain name.
amrecover> listhost
200- List hosts for config DailySet1
201- xenora02.
201- clxbld01.
201- isobck01.
200 List hosts for config DailySet1
amrecover> sethost dlxmkt01.
200 Dump host set to dlxmkt01.
amrecover> listdisk
200- List of disk for host dlxmkt01.
201- /
200 List of disk for host dlxmkt01.
amrecover> setdisk /
200 Disk set to /.
amrecover> cd /
amrecover> ls
2010-09-16-00-05-03 var/
2010-09-16-00-05-03 usr/
2010-09-16-00-05-03 tmp/
2010-09-16-00-05-03 tdev15/
2010-09-16-00-05-03 sys/
2010-09-16-00-05-03 srv/
2010-09-16-00-05-03 selinux/
2010-09-16-00-05-03 sbin/
2010-09-16-00-05-03 root/
2010-09-16-00-05-03 proc/
2010-09-16-00-05-03 opt/
2010-09-16-00-05-03 mnt/
2010-09-16-00-05-03 media/
2010-09-16-00-05-03 lib64/
2010-09-16-00-05-03 lib/
2010-09-16-00-05-03 initrd/
2010-09-16-00-05-03 home/
2010-09-16-00-05-03 etc/
2010-09-16-00-05-03 dev/
2010-09-16-00-05-03 data/
2010-09-16-00-05-03 boot/
2010-09-16-00-05-03 bin/
2010-09-16-00-05-03 .
2010-09-14-00-05-03 init
2010-09-14-00-05-03 .autofsck
amrecover> lcd /
amrecover> add /tmp/amanda/phooper
Added dir /tmp/amanda/phooper/ at date 2010-09-16-00-05-03
amrecover> extract
Extracting files using tape drive changer on host redbck01.
The following tapes are needed: DailySet1-15
Extracting files using tape drive changer on host redbck01.
Load tape DailySet1-15 nowContinue [?/Y/n/s/d]? y
amrecover> quit
200 Good bye.
If redbck01 fails we can recover the data from redbck02 by running the rsync script '' which is located in /root/ directory from redbck02

Wednesday, 15 September 2010

Rsync Backup Script

Backup script for synchronising directories among two or more systems. The most obvious one, at least when anything that is being sent to the system scheduler, was logging. The next two are sort of ad-hoc judgment calls. A usage message (which is quite lengthy) was added simply because, well this script has been running for two months and if the user would have to rerun it by hand - frankly they wouldn't have a clue. The last item was an override for the flags and protocol in the form of additional arguments. The rsync flags are sent in via a quoted string which makes it easier to parse in the script. The reader should feel free to change the script as they see fit.

Adding the ability to do different multiple sources and/or destinations was dropped due to the amount of heads and arms the script would have to grow to facilitate the capability. Additionally, logging is simplified by invoking the script by itself for each session. Remember the golden Unix utility rule:

Do one thing and do it well

Bearing that that in mind, a multiple src/dst script would be better served with a completely different script, lest the current one morph into some sort of evil hydra.

Adding Logging

It is a shell script and as such it makes perfect sense to use the shell utility logger to access syslog directly.

PROTO=ssh RSYNC=rsync RSYNC_FLAGS="-az --delete -e $PROTO" LOGCMD=logger

# The name of our /var/log/messages entries
LOG_FLAGS="-t $LOGID" # Flags for the logger interface

Note that UTIL was changed to RSYNC - it is pretty much a given that rsync is being used, so for sanity it was changed. The additions here are the logger command and one flag, what the entry format will look like. Here is a sample from /var/log/messages:

Mar 16 00:32:12 pyxis syncondemand[3410]: Test

The rest

There are only three entries, however, anyone could feel free to change them. They are as follows:


do if ! type ${i} >/dev/null; then
$LOGCMD $LOGID "${i} not found"
bomb "${i} not found" fi done

A message in the utilities checker loop. If, for instance, the utility were installed blindly on a new machine and tossed into crontab, this rather informative message would let the administrator know that they need to install a utility or application.


$LOGID "Starting $RSYNC operation from $SRC to $DST"
$RSYNC $RSYNC_FLAGS $SRC $DST $LOGCMD $LOGID "Finished $RSYNC operation from
$SRC to $DST"

A start and stop messages for recording the amount of time. What happens if they start to take extraordinary long amounts of time? These particular messages let the admin know ahead of time and can easily be added to log analysis tools.

Additional Flags & Proto

Note the top of the script with the following global definitions:

PROTO=ssh RSYNC_FLAGS="-az --delete -e $PROTO"

In this version only those two are altered. Changing the protocol requires that the actual final rsync invocation be changed as well.

First, make the call and global different:


Note that the protocol now must be defined either by the ssh default or using the modification.

Next, all that has to be done is to add a method to change the default rsync flags and protocol. It can all be done in the switch/case loop:

while getopts s:d: ch; do   

case ${ch} in
esac done
shift $((${OPTIND} - 1))

The only downside is that the -f has to use double quotes to replace all of the strings - regrettable - yes; but there is a usage message after all.

The Easy Part - Usage

Usage messages in shell scripts, frankly, rock. Simply because there is an all ending one simple way to do them even though they look kind of freaky relative to the indentation of the rest of the script, as usual, only the code can explain it:

usage() {     cat <<_usage_>

Basically it is just redirection and yes, it does make a well formed script look really ugly,

however, using that particular method over typing echo... echo... echo... and avoiding echo

calls makes it well worth the apparent ugliness.

Example Crontab entries for the script are:

$crontab -e

0 1 * * 1-6 /root/ -s /etc/amanda -d redbck02:/etc

0 5 * * 1-6 /root/ -s /space/vtapes -d redbck02:/space

This simple script should be a good start to organizing and managing rsync style backups. It is small,

concise and easy to use or modify. Some food for thought might be adding ssh options

(such as forced versions) and extended operations like cloning.

passwordless ssh and rsync script

Method1 using RSA authentication

he SSH protocol is recommended for remote login and remote file transfer which provides confidentiality and security for data exchanged between two computer systems, through the use of public key cryptography. The OpenSSH server provides this kind of setup under Linux. It is installed by default. This how-to covers generating and using ssh keys for automated usage such as:

  1. Automated Login using the shell scripts.
  2. Making backups.
  3. Run commands from the shell prompt etc.

Task: Generating SSH Keys

First, log on to your workstation ( for example log on to workstation called as vivek user). Please refer the following sample setup - You will be log in, on your local system, AS THE USER you wish to make passwordless ssh connections.

Fig.01 ssh key based authentication

ssh key based authentication

Create the cryptographic Key on FreeBSD / Linux / UNIX workstation, enter:
ssh-keygen -t rsa

Assign the pass phrase (press [enter] key twice if you don't want a passphrase). It will create 2 files in ~/.ssh directory as follows:

  • ~/.ssh/id_rsa : identification (private) key
  • ~/.ssh/ : public key

Use scp to copy the (public key) to server as authorized_keys2 file, this is know as Installing the public key to server.

scp .ssh/

From FreeBSD workstation login to server:


Changing the pass-phrase on workstation (if needed):

ssh-keygen -p

Use of ssh-agent to avoid continues pass-phrase typing
At freebsd workstation type:

ssh-agent $BASH

Type your pass-phrase

Now ssh server will not use prompt for the password. Above two commands can be added to your ~/.bash_profile file so that as soon as you login into workstation you can set the agent.

Deleting the keys hold by ssh-agent

To list keys, enter:
ssh-add -l
To delete all keys, enter:
ssh-add -D
To delete specific key, enter:
ssh-add -d key

Method2 using DSA authentication

Here is a list of the steps that I had to do to get automatic replication of /home/folder1 (or any other folder) on one server to /home/folder2 on another server:

Passwordless SSH

To get replication working securly you firstly need to be able to connect via SSH without using passwords:

First server setup

ssh-keygen -t dsa

(press enter twice to give a blank password)

cd vi .ssh/.config

Press "i" to enter insert mode and copy this into the file:

Host remotehost
User remoteuser
Compression yes
Protocol 2
RSAAuthentication yes
StrictHostKeyChecking no
ForwardAgent yes
ForwardX11 yes
IdentityFile /home/localuser/.ssh/id_remotehost_dsa

Do NOT change the last line - it is supposed to say remotehost (not an actual host name). Now,


(save and exit vi)

chmod 700 .ssh vi .ssh/

It should look like this:

ssh-dss AAAA..............v root@HOSTNAMEOFSRV01

where there is lots of random letters/numbers where the dots are. Select it all and copy it. Make sure that it is all on one line with no spaces at the start or finish (which will happen if you copy it using putty on windows; test it by pasting it into notepad)
Tip: To copy from putty on windows select the text from within vi and pres Ctrl + Shift. To paste text enter insert mode and press the right mouse button.

Second Server Setup

cd vi .ssh/authorized_keys

Enter insert mode (press i) and paste the key, again ensuring that there are no spare newlines or spaces. Save the file and exit vi (press :wq then return, as above). Now you just need to set some permissions otherwise SSH will ignore the files you just created:

chmod 700 .ssh chmod 644 .ssh/authorized_keys

Testing passwordless SSH

On the first server, type

ssh srv02

where srv02 = the hostname of the second server. It could be an IP address too.

If it just logs you in (no passwords), then you are done. If not double check the above and start google searching your errors


You have two options for replication: Unison and Rsync.

  • Rsync is one-way (will overwrite changes on the second server).

  • Unison is two-way (will allow changes on both servers (though clearly not at the same time!)

Setting up RSYNC

Skip to the unison section if you want two-way replication

Rsync is normally installed so I will not go through installing it. To make the rsync connection run the following command on srv01:

rsync -e ssh -avz --delete /home/folder1/ srv02hostname:/home/folder2
rsync -e ssh -avz --delete /etc/amanda/ redbck02:/etc/
rsync -e ssh -avz --delete /space/vtapes/ redbck02:/space/

again, where srv02 is the hostname or IP of srv02. This will make /home/folder2 on srv02 (the second server) identical to /home/folder1 (be aware that this will delete all files in /home/folder2 on srv02 that are not in /home/folder1 on srv01!)

You can put as many of these as you line in the crontab (crontab -e). You now have rsync set up: congratulations.

Setting up UNISON

cd /bin wget
latest/unison.linux-textui mv unison.linux-textui unison chmod +x unison

Then run this example at the first cluster to sync /var/www/html/ directories on both:

unison /var/www/html ssh://srv02hostname//var/www/html -batch

again, where srv02 is the hostname or IP of srv02

This will take a very long time to run for the first time but is very quick after that.

You can put as many of these as you line in the crontab (crontab -e). You now have unison set up: congratulations.


Tuesday, 14 September 2010

Extend LVM Disk Space With New Hard Disk

This is a step-by-step guide used to extend logical volume group disk space, that’s configured under LVM version 1.x of Redhat Enterprise Linux AS 3. Although, this guide has also been used to extend LVM disk space with a new SCSI hard disk, that’s configured with LVM version 2.x in Debian Sarge 3.1.

So, it’s good enough to serve as a reference for Linux users, who plan to extend LVM disk space in Linux distributions other than Redhat and Debian Linux.

Although it’s not necessary, it’s advised to perform full file system backup before carry out this exercise!

The most risky step is to resize file system that resides in a LVM logical volume. Make sure the right file system resizer tool is used. If you’re using resize2fs to resize a Reiserfs file system, I guess you’ll know how bad will be the consequences.

Apparently, you’ll need resize_reiserfs to resize a Reiserfs file system, which is part of the reiserfsprogs package.

Steps to extend /home file system that mounts on logical volume /dev/vg0/lvol1 of volume group vg0, by using a new 36GB SCSI hard disk added to RAID 0 of HP Smart Array 5i Controller.

1) Log in as root user and type init 0 to shutdown Redhat Enterprise AS 3 Linux.

2) Add in the new 36GB SCSI hard disk. Since HP Smart Array 5i is configure for RAID 0, it’s fine to mix hard disks of different capacity, except that hard disk speed must be the same! A mix of 10K and 15K RPM hard disks might cause Redhat Enterprise Linux fails to boot up properly.

Normally, HP Smart Array 5i Controller will automatically configure new hard disk as a logical drive for RAID 0. If not, press F8 on boot up to get in HP Smart Array 5i Controller setup screen and manually create logical drive as part of RAID 0.

How to tell if new hard disk is not configured as logical drive for RAID 0?

Physically, the hard disk green light should be on or blinking to indicate that it’s online to RAID system.

From OS level, 3rd hard disk in RAID 0 of HP Smart Array 5i Controller is denoted as /dev/cciss/c0d2. So, type

fdisk /dev/cciss/c0d2

at root command prompt. If an error message Unable to open /dev/cciss/c0d2 or alike is returned, it means that new hard disk is not online to RAID system or Redhat Linux.

3) Boot up Redhat Enterprise Linux into multi-user mode and confirm it’s working properly. This step is not necessary, but it’s a good practice to prove that the server is working fine after each change has been made, be it a major or minor change.

4) Type init 1 at root command prompt to boot into single user mode. Whenever possible, boot into single user mode for system maintenance as to avoid inconsistency or corruption.

5) At the root command prompt, type

fdisk /dev/cciss/c0d2

to create partition for the 3rd SCSI hard disk added to RAID 0. Each hard disk needs at least one partition (maximum 4 primary partitions per hard disk) in order to use the new hard disk in a Linux system.

6) While at the fdisk command prompt, type m to view fdisk command options.

7) Type n to add a new partition, followed by p to go for primary partition type.

8) Type 1 to create the first partition. Press ENTER to accept first cylinder default as 1, and press ENTER again to accept the default value for last cylinder, which is essentially create single partition that use up all hard disk space.

9) Type t to change the partition system id, or partition type. As there is only one partition, partition 1 is automatically selected for action. Type L to list all supported partition type. As shown in partition type listing, type 8e to set partition 1 as Linux LVM partition type.

10) Type p to confirm partition /dev/cciss/c0d2p1 has been created in partition table. Type w to write the unsaved partition table of changes to hard disk and exit from fdisk command line.

11) Type df -hTa to confirm /home file system type, that’s mounts on logical volume /dev/vg0/lvol1. For this case, it’s an ext3 file system type.

12) Type umount /home to un-mount /home file system from Redhat Enterprise Linux.

13) Next, type LVM command

pvcreate /dev/cciss/c0d2p1

to create a new LVM physical volume on the new partition /dev/cciss/c0d2p1.

14) Now, type another LVM command

vgextend vg0 /dev/cciss/c0d2p1

to extend LVM volume group vg0, with that new LVM physical volume created on partition /dev/cciss/c0d2p1.

15) Type pvscan to display physical volumes created in Linux LVM system, which is useful to answer questions such as “How many physical volume created in volume group vg0?”, “How much of free disk space left on each physical volume?”, “How do I know which physical volume should be used for a logical volume?” “Which physical volume has free disk space for used with a logical volume?”, etc.

Sample output of pvscan command:

ACTIVE PV “/dev/cciss/c0d0p4″ of VG “vg0″ [274.27GB / 0 free]
ACTIVE PV “/dev/cciss/c0d1p1″ of VG “vg0″ [33.89GB / 0 free]
ACTIVE PV “/dev/cciss/c0d2p1″ of VG “vg0″ [33.89 GB / 33.89 GB free]
total: 3 [342.05 GB] / in use: 3 [342.05 GB] / in no VG: 0 [0]

Alternative, type vgdisplay vg0 | grep PE to confirm that new physical volume has been added to volume group vg0. Take note of Free PE / Size, 35GB in this case, that’s free disk space added by new physical volume in volume group vg0.

16) Execute LVM command

lvextend -L +33G /dev/vg0/lvol1 /dev/cciss/c0d2p1

to extend the size of logical volume /dev/vg0/lvol1 of volume group vg0 by 33GB on physical volume /dev/cciss/c0d2p1.

17) Now, the most risky steps to start. Type this command

e2fsck -f /dev/vg0/lvol1

to force ext3 file system check on /dev/vg0/lvol1. It’s a must to confirm file system is in good state, before implement any changes on it.

CAUTION – Utility e2fsck is only used to check EXT file system such as ext2 and ext3, and not other file system such Reiserfs file system!

Once the ext file system check completes without errors or warnings, type command

resize2fs /dev/vg0/lvol1

to resize EXT3 file system of /home, that mounts on logical volume /dev/vg0/lvol1, until it takes up all free disk space added to /dev/vg0/lvol1.

CAUTION – Utility resize2fs is only used to resize EXT file system such as ext2 and ext3, and not other file systems such as Reiserfs file system!

Both e2fsck and resize2fs utilities are part of e2fsprogs package. And both utilities takes some minutes to complete, depends on the size of target file system.

If everything alright, type mount /home to re-mount /home file system. Next, type df -h to confirm that /home file system has been extended successfully.