LVM Howto
LVM Howto
AJ Lewis
<alewis(at)redhat.com>
Revision History
Revision 0.14 2004−10−06 Revised by: ajl
Added reference to lvm2_createinitrd in source tree; Adjusted lvcreate example slightly; Added 'vgchange
−ay' in 'Moving a volume group to another system' recipe
Revision 0.13 2004−08−16 Revised by: ajl
Clarify symlink farm description; Fix dm control device major number; Remove /boot from vg in small lvm
setup example; Add notes about /boot and / on LVM; Remove outdated link;
Revision 0.12 2004−06−07 Revised by: ajl
Updated LVM2 FAQ entries
Revision 0.11 2004−05−03 Revised by: ajl
Updated LVM2 FAQ entries
Revision 0.10 2004−04−22 Revised by: ajl
removed −print0 from find command after receiving reports that it doesn't work
Revision 0.9 2004−04−16 Revised by: ajl
Added −print0 to find command before piping it to cpio; Changed vgimport command line for LVM 2;
Added ext3 to the ext2 resize section; Updated FAQ; Updated Links section
Revision 0.8 2004−02−25 Revised by: ajl
Updated CVS locations and FTP links; Added section on extending a JFS filesystem; Fixed typos − Ran
aspell against document
Revision 0.7 2004−02−16 Revised by: ajl
Updated to include LVM 2 and device mapper information; Updated email addresses; Updated copyright;
Added FAQ section; Added document license; Updated to docbook 4.2
Revision 0.6 2003−12−09 Revised by: ajl
Updated for LVM 1.0.8; fixed broken link; Clarified redhat init script section;
Revision 0.5 2003−02−10 Revised by: ajl
Updated Redhat initscript information for 7.0 and above; Added information on removing a partition table
from a disk if pvcreate fails; Default PE size is 32MB now; Updated method for snapshotting under XFS.
Revision 0.4 2002−12−16 Revised by: ajl
Updated for LVM 1.0.6
Revision 0.3 2002−09−16 Revised by: ajl
removed example pvmove from Command Operations section − we now just point to the more detailed
recipe on pvmove that contains various warnings and such
Revision 0.2 2002−09−11 Revised by: ajl
Updated for LVM 1.0.5 and converted to DocBook XML 4.1.2.
Revision 0.1 2002−04−28 Revised by: gf
Initial conversion from Sistina's LaTeX source and import to tLDP in LinuxDoc format.
This document describes how to build, install, and configure LVM for Linux. A basic description of LVM is
also included. This version of the HowTo is for LVM 2 with device−mapper, as well as LVM 1.0.8.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free
Documentation License, Version 1.2 published by the Free Software Foundation; with no Invariant Sections,
no Front−Cover Texts and no Back−Cover Texts. A copy of the license is included in the section entitled
"GNU Free Documentation License".
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY, either
expressed or implied. While every effort has been taken to ensure the accuracy of the information documented
herein, the author(s)/editor(s)/maintainer(s)/contributor(s) assumes NO RESPONSIBILITY for any errors, or
for any damages, direct or consequential, as a result of the use of the information documented herein.
LVM HOWTO
Table of Contents
Introduction........................................................................................................................................................1
1. Latest Version......................................................................................................................................1
2. Disclaimer............................................................................................................................................1
3. Contributors.........................................................................................................................................1
i
LVM HOWTO
Table of Contents
Chapter 7. LVM 1 Boot time scripts
7.3. Mandrake........................................................................................................................................20
7.4. Redhat.............................................................................................................................................20
7.5. Slackware........................................................................................................................................21
7.6. SuSE................................................................................................................................................23
ii
LVM HOWTO
Table of Contents
Chapter 13. Recipes
13.3.1. Current situation..................................................................................................................42
13.3.2. Prepare the disk partitions...................................................................................................42
13.3.3. Add the new disks to the volume groups............................................................................43
13.3.4. Extend the file systems........................................................................................................44
13.3.5. Remount the extended volumes..........................................................................................45
13.4. Taking a Backup Using Snapshots...............................................................................................45
13.4.1. Create the snapshot volume.................................................................................................45
13.4.2. Mount the snapshot volume................................................................................................46
13.4.3. Do the backup......................................................................................................................46
13.4.4. Remove the snapshot...........................................................................................................46
13.5. Removing an Old Disk.................................................................................................................46
13.5.1. Distributing Old Extents to Existing Disks in Volume Group............................................47
13.5.2. Distributing Old Extents to a New Replacement Disk........................................................47
13.6. Moving a volume group to another system...................................................................................48
13.6.1. Unmount the file system......................................................................................................48
13.6.2. Mark the volume group inactive.........................................................................................49
13.6.3. Export the volume group.....................................................................................................49
13.6.4. Import the volume group.....................................................................................................49
13.6.5. Activate the volume group..................................................................................................49
13.6.6. Mount the file system..........................................................................................................50
13.7. Splitting a volume group...............................................................................................................50
13.7.1. Determine free space...........................................................................................................50
13.7.2. Move data off the disks to be used......................................................................................50
13.7.3. Create the new volume group..............................................................................................51
13.7.4. Remove remaining volume.................................................................................................51
13.7.5. Create new logical volume..................................................................................................51
13.7.6. Make a file system on the volume.......................................................................................51
13.7.7. Mount the new volume........................................................................................................52
13.8. Converting a root filesystem to LVM 1........................................................................................52
13.8.1. Boot single user...................................................................................................................53
13.8.2. Run Parted...........................................................................................................................53
13.8.3. Reboot.................................................................................................................................53
13.8.4. Verify kernel config options................................................................................................54
13.8.5. Adjust partition type............................................................................................................54
13.8.6. Set up LVM 1 for the new scheme......................................................................................54
13.8.7. Create the Filesystem..........................................................................................................54
13.8.8. Update /etc/fstab..................................................................................................................54
13.8.9. Create an LVM 1 initial RAM disk.....................................................................................55
13.8.10. Update /etc/lilo.conf..........................................................................................................55
13.8.11. Run LILO to write the new boot sector.............................................................................55
13.8.12. Reboot to lvm....................................................................................................................55
13.8.13. Add remainder of disk.......................................................................................................56
iii
LVM HOWTO
Table of Contents
Appendix B. Reporting Errors and Bugs.......................................................................................................59
iv
Introduction
This is an attempt to collect everything needed to know to get LVM up and running. The entire process of
getting, compiling, installing, and setting up LVM will be covered. Pointers to LVM configurations that have
been tested with will also be included. This version of the HowTo is for LVM 2 with device−mapper and
LVM 1.0.8.
All previous versions of LVM are considered obsolete and are only kept for historical reasons. This document
makes no attempt to explain or describe the workings or use of those versions.
1. Latest Version
We will keep the latest version of this HowTo in the CVS with the other LDP Howtos. You can get it by
checking out ``LDP/howto/docbook/LVM−HOWTO.xml'' from the tLDP CVS server. You should always be
able to get a human readable version of this HowTo from the
http://www.tldp.org/HOWTO/LVM−HOWTO.html
2. Disclaimer
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY, either
expressed or implied. While every effort has been taken to ensure the accuracy of the information documented
herein, the author(s)/editor(s)/maintainer(s)/contributor(s) assumes NO RESPONSIBILITY for any errors, or
for any damages, direct or consequential, as a result of the use of the information documented herein.
3. Contributors
List of everyone who has put words into this file.
• AJ Lewis
• Joe Thornber
• Patrick Caulfield
• Alasdair Kergon
• Jochen Radmacher − JFS extend information
Please notify the HowTo maintainer if you believe you should be listed above.
Introduction 1
Chapter 1. What is LVM?
LVM is a Logical Volume Manager for the Linux operating system. There are now two version of LVM for
Linux:
LVM 2 is almost completely backward compatible with volumes created with LVM 1. The exception
to this is snapshots (You must remove snapshot volumes before upgrading to LVM 2)
LVM 2 uses the device mapper kernel driver. Device mapper support is in the 2.6 kernel tree and
there are patches available for current 2.4 kernels.
• LVM 1 − The version that is in the 2.4 series kernel,
LVM 1 is a mature product that has been considered stable for a couple of years. The kernel driver for
LVM 1 is included in the 2.4 series kernels, but this does not mean that your 2.4.x kernel is up to date
with the latest version of LVM. Look at the README for the latest information about which kernels
have the current code in them.
Storage volumes created under the control of the logical volume manager can be resized and moved around
almost at will, although this may need some upgrading of file system tools.
The logical volume manager also allows management of storage volumes in user−defined groups, allowing
the system administrator to deal with sensibly named volume groups such as "development" and "sales" rather
than physical disk names such as "sda" and "sdb".
Once the user has guessed how much space is needed for /home /usr / (or has let the installation program do
it) then is quite common for one of these partitions to fill up even if there is plenty of disk space in one of the
other partitions.
With logical volume management, the whole disk would be allocated to a single volume group and logical
volumes created to hold the / /usr and /home file systems. If, for example the /home logical volume later filled
up but there was still space available on /usr then it would be possible to shrink /usr by a few megabytes and
reallocate that space to /home.
Another alternative would be to allocate minimal amounts of space for each logical volume and leave some of
the disk unallocated. Then, when the partitions start to fill up, they can be expanded as necessary.
As an example: Joe buys a PC with an 8.4 Gigabyte disk on it and installs Linux using the following
partitioning system:
This, he thinks, will maximize the amount of space available for all his MP3 files.
Jane buys a similar PC but uses LVM to divide up the disk in a similar manner:
boot is not included on the LV because bootloaders don't understand LVM volumes yet. It's possible
boot on LVM will work, but you run the risk of having an unbootable system.
When she hits a similar problem she can reduce the size of /home by a gigabyte and add that space to the root
partition.
Suppose that Joe and Jane then manage to fill up the /home partition as well and decide to add a new 20
Gigabyte disk to their systems.
Joe formats the whole disk as one partition (/dev/hdb1) and moves his existing /home data onto it and uses the
new disk as /home. But he has 6 gigabytes unused or has to use symlinks to make that disk appear as an
extension of /home, say /home/joe/old−mp3s.
Jane simply adds the new disk to her existing volume group and extends her /home logical volume to include
the new disk. Or, in fact, she could move the data from /home on the old disk to the new disk and then extend
the existing root volume to cover all of the old disk.
User groups can be allocated to volume groups and logical volumes and these can be grown as required. It is
possible for the system administrator to "hold back" disk storage until it is required. It can then be added to
the volume(user) group that has the most pressing need.
When new drives are added to the system, it is no longer necessary to move users files around to make the
best use of the new storage; simply add the new disk into an existing volume group or groups and extend the
logical volumes as necessary.
It is also easy to take old drives out of service by moving the data from them onto newer drives − this can be
done online, without disrupting user service.
Another way to look at is this (courtesy of Erik Bågfors on the linux−lvm mailing list):
Lets suppose we have a volume group called VG1, this volume group has a physical extent size of 4MB. Into
this volume group we introduce 2 hard disk partitions, /dev/hda1 and /dev/hdb1. These partitions will become
physical volumes PV1 and PV2 (more meaningful names can be given at the administrators discretion). The
PV's are divided up into 4MB chunks, since this is the extent size for the volume group. The disks are
different sizes and we get 99 extents in PV1 and 248 extents in PV2. We now can create ourselves a logical
volume, this can be any size between 1 and 347 (248 + 99) extents. When the logical volume is created a
mapping is defined between logical extents and physical extents, eg. logical extent 1 could map onto physical
extent 51 of PV1, data written to the first 4 MB of the logical volume in fact be written to the 51st extent of
PV1.
1. Linear mapping will assign a range of PE's to an area of an LV in order eg., LE 1 − 99 map to PV1
and LE 100 − 347 map onto PV2.
2. Striped mapping will interleave the chunks of the logical extents across a number of physical
volumes eg.,
1st chunk of LE[1] −> PV1[1],
and so on. In certain situations this strategy can improve the performance of the logical volume.
LVM 1 Caveat
LVs created using striping cannot be extended past the PVs they were originally created on in
LVM 1.
In LVM 2, striped LVs can be extended by concatenating another set of devices onto the end of the
first set. So you can get into a situation where your LV is a 2 stripe set concatenated with a linear set
3.8. Snapshots
A wonderful facility provided by LVM is 'snapshots'. This allows the administrator to create a new block
device which is an exact copy of a logical volume, frozen at some point in time. Typically this would be used
when some batch processing, a backup for instance, needs to be performed on the logical volume, but you
don't want to halt a live system that is changing the data. When the snapshot device has been finished with the
system administrator can just remove the device. This facility does require that the snapshot be made at a time
when the data on the logical volume is in a consistent state, later sections of this document give some
examples of this.
More information on snapshots can be found in Section 13.4 Taking a Backup Using Snapshots.
4.1.1. I have LVM 1 installed and running on my system. How do I start using LVM 2?
1. Start by removing any snapshot LVs on the system. These are not handled by LVM 2 and will prevent
the origin from being activated when LVM 2 comes up.
2. Make sure you have some way of booting the system other than from your standard boot partition.
Have the LVM 1 tools, standard system tools (mount) and an LVM 1 compatible kernel on it in case
you need to get back and fix some things.
3. Grab the LVM 2 tools source and the device mapper source and compile them. You need to install the
device mapper library using "make install" before compiling the LVM 2 tools. Also copy the
dm/scripts/devmap_mknod.sh script into /sbin. I recommend only installing the 'lvm' binary for now
so you have access to the LVM 1 tools if you need them. If you have access to packages for LVM 2
and device−mapper, you can install those instead, but beware of them overwriting your LVM 1 tool
set.
4. Get a device mapper compatible kernel, either built in or as a kernel module.
5. Figure out where LVM 1 was activated in your startup scripts. Make sure the device−mapper module
is loaded by that point (if you are using device mapper as a module) and add
'/sbin/devmap_mknod.sh; lvm vgscan; lvm vgchange −ay' afterward.
6. Install the kernel with device mapper support in it. Reboot. If all goes well, you should be running
with lvm2.
4.1.2. I get errors about /dev/mapper/control when I try to use the LVM 2 tools. What's going on?
The primary cause of this is not having run the devmap_mknod.sh script after rebooting into a dm capable
kernel. This script generates the control node for device mapper.
If you don't have the devmap_mknod.sh script, don't despair! It's pretty easy to create the
/dev/mapper/control file on your own:
1. Make sure you have the device−mapper module loaded (if you didn't build it into your kernel).
2. Run
# cat /proc/misc | grep device−mapper | awk '{print $1}'
and note the number printed. (If you don't get any output, refer to step 1.)
3. Run
# mkdir /dev/mapper
− if you get an error saying /dev/mapper already exists, make sure it's a directory and move on.
4. Run
# mknod /dev/mapper/control c 10 $number
where $number is the number printed in step 2.
4.1.3. Which commands and types of logical volumes are currently supported in LVM 2?
If you are using the stable 2.4 device mapper patch from the lvm2 tarball, all the major functionality you'd
expect using lvm1 is supported with the lvm2 tools. (You still need to remove snapshots before upgrading
from lvm1 to lvm2)
If you are using the version of device mapper in the 2.6 kernel.org kernel series the following commands and
LV types are not supported:
• pvmove
• snapshots
The beginnings of support for these features are in the unstable device mapper patches maintained by Joe
Thornber.
4.1.4. Does LVM 2 use a different format from LVM 1 for it's ondisk representation of Volume Groups and
Logical Volumes?
Yes. LVM 2 uses lvm 2 format metadata. This format is much more flexible than the LVM 1 format metadata,
removing or reducing most of the limitations LVM 1 had.
4.1.5. Does LVM 2 support VGs and LVs created with LVM 1?
Yes. LVM 2 will activate and operate on VG and LVs created with LVM 1. The exception to this is snapshots
created with LVM 1 − these should be removed before upgrading. Snapshots that remain after upgrading will
have to be removed before their origins can be activated by LVM 2.
4.1.6. Can I upgrade my LVM 1 based VGs and LVs to LVM 2 native format?
Yes. Use vgconvert to convert your VG and all LVs contained within it to the new lvm 2 format metadata. Be
warned that it's not always possible to revert back to lvm 1 format metadata.
4.1.7. I've upgraded to LVM 2, but the tools keep failing with out of memory errors. What gives?
One possible cause of this is that some versions of LVM 1 (The user that reported this bug originally was
using Mandrake 9.2, but it is not necessarily limited to that distribution) did not put a UUID into the PV and
VG structures as they were supposed to. The most current versions of the LVM 2 tools automatically fill
UUIDs in for the structures if they see they are missing, so you should grab a more current version and your
problem should be solved. If not, post to the linux−lvm mailing list
4.1.8. I have my root partition on an LV in LVM 1. How do I upgrade to LVM 2? And what happened to
lvmcreate_initrd?
Upgrading to LVM 2 is a bit trickier with root on LVM, but it's not impossible. You need to queue up a kernel
with device−mapper support and install the lvm2 tools (you might want to make a backup of the lvm 1 tools,
or find a rescue disk with the lvm tools built in, in case you need them before you're done). Then find a
mkinitrd script that has support for your distro and lvm 2.
Currently, this is the list of mkinitrd scripts that I know support lvm2, sorted by distro:
fedora
The latest fedora core 2 mkinitrd handles lvm2, but it relies on a statically built lvm binary from the
latest lvm 2 tarball.
Each disk (PV) is labeled with a UUID, which uniquely identifies it to the system. 'vgscan' identifies this after
a new disk is added that changes your drive numbering. Most distros run vgscan in the lvm startup scripts to
cope with this on reboot after a hardware addition. If you're doing a hot−add, you'll have to run this by hand I
think. On the other hand, if your vg is activated and being used, the renumbering should not affect it at all. It's
only the activation that needs the identifier, and the worst case scenario is that the activation will fail without a
vgscan with a complaint about a missing PV.
The failure or removal of a drive that LVM is currently using will cause problems with current use and
future activations of the VG that was using it.
4.1.10. I'm trying to fill my vg, and vgdisplay/vgs says that I have 1.87 GB free, but when I do an lvcreate vg
−L1.87G it says "insufficient free extends". What's going on?
The 1.87 GB figure is rounded to 2 decimal places, so it's probably 1.866 GB or something. This is a
human−readable output to give you a general idea of how big the VG is. If you want to specify an exact size,
you must use extents instead of some multiple of bytes.
In the case of vgdisplay, use the Free PE count instead of the human readable capacity.
In the case of vgs, you need to instruct it to tell you how many extents are available:
# vgs −o +vg_free_count,vg_extent_count
This tell vgs to add the free extents and the total number of extents to the end of the vgs listing. Use the free
extent number the same way you would in the above vgdisplay case.
The LVM 1 kernel patch must be generated using the LVM 1 source. More information regarding this
can be found in Section 6.2
To build LVM from the CVS sources, you must have several GNU tools:
diff −u −b −B
checkout −P
update −d −P
Also, if you are on a slow net link (like a dialup), you will want to add a line containing cvs −z5 in this file.
This turns on a useful compression level for all CVS commands.
The first time you download from cvs, you must login
The password is `cvs'. The command outputs nothing if successful and an error message if it fails.
Only an initial login is required. All subsequent CVS commands read the password stored in the file
$HOME/.cvspass for authentication.
This will create a new directory device−mapper in your current directory containing the latest,
up−to−the−minute device mapper code.
• LVM 2
The first time you download from cvs, you must login
The password is `cvs'. The command outputs nothing if successful and an error message if it fails.
Only an initial login is required. All subsequent CVS commands read the password stored in the file
$HOME/.cvspass for authentication.
This will create a new directory LVM2 in your current directory containing the latest,
up−to−the−minute LVM 2 code.
• LVM 1
The first time you download from cvs, you must login
The password is `cvs'. The command outputs nothing if successful and an error message if it fails.
Only an initial login is required. All subsequent CVS commands read the password stored in the file
$HOME/.cvspass for authentication.
This will create a new directory LVM in your current directory containing the latest,
up−to−the−minute LVM 1 code.
CVS commands work from anywhere inside the source tree, and recurse downward. So if you happen to issue
an update from inside the `tools' subdirectory it will work fine, but only update the tools directory and it's
subdirectories. In the following command examples it is assumed that you are at the top of the source tree.
You can update your copy of the sources to match the master repository with the update command. It is not
necessary to check out a new copy. Using update is significantly faster and simpler, as it will download only
patches instead of entire files and update only those files that have changed since your last update. It will
automatically merge any changes in the CVS repository with any local changes you have made as well. Just
cd to the directory you'd like to update and then type the following.
# cvs update
If you did not specify a tag when you checked out the source, this will update your sources to the latest
version on the main branch. If you specified a branch tag, it will update to the latest version on that branch. If
you specified a version tag, it will not do anything.
When you have your code in a working state and have tested as best you can with the hardware you have,
generate a patch against the current sources in the CVS repository.
# cvs update
# cvs diff > patchfile
Mail the patch to the linux−lvm or dm−devel list (Section C.1) with a description of what changes or additions
you implemented.
5.9. Conflicts
If someone else has been working on the same files as you have, you may find that there are conflicting
modifications. You'll discover this when you try to update your sources.
# cvs update
RCS file: LVM/tools/pvcreate.c,v
retrieving revision 1.5
retrieving revision 1.6
Merging differences between 1.5 and 1.6 into pvcreate.c
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in tools/pvcreate.c
C tools/pvcreate.c
Don't panic! Your working file, as it existed before the update, is saved under the filename
.#pvcreate.c.1.5. You can always recover it should things go horribly wrong. The file named
`pvcreate.c' now contains both the old (i.e. your) version and new version of lines that conflicted. You simply
edit the file and resolve each conflict by deleting the unwanted version of the lines involved.
<<<<<<< pvcreate.c
j++;
=======
j−−;
>>>>>>> 1.6
Don't forget to delete the lines with all the ``<'', ``='', and ``>'' symbols.
Your Linux system is probably based on one of the popular distributions (eg., Red Hat, SuSE, Debian) in
which case it is possible that you already have the LVM 1 module. Check the version of the tools you have on
your system. You can do this by running any of the LVM command line tools with the '−h' flag. Use pvscan
−h if you don't know any of the commands. If the version number listed at the top of the help listing is LVM
1.0.8, use your current setup and avoid the rest of this section.
3. Run configure
# ./configure
You will need to pass the option −−with−kernel_dir to configure if your linux kernel source is
not in /usr/src/linux. (Run ./configure −−help to see all the options available)
4. Enter the PATCHES directory
# cd PATCHES
5. Run 'make'
# make
Patches:
1. rawio patch
The relevant LVM 1 patch which should be built out of the PATCHES sub−directory of the LVM
distribution. More information can be found in Section 6.2.1, Building a patch for your kernel.
Once the patches have been correctly applied, you need to make sure that the module is actually built, LVM 1
lives under the block devices section of the kernel config, you should probably request that the LVM /proc
information is compiled as well.
If you want to use snapshots with ReiserFS, make sure you apply the linux−2.4.x−VFS−lock patch
(there are copies of this in the LVM/1.0.8/PATCHES directory.)
# modprobe lvm−mod
If /proc/lvm still does not exist then check your kernel configuration carefully.
When LVM is active you will see entries in /proc/lvm for all your physical volumes, volume groups and
logical volumes. In addition there is a "file" called /proc/lvm/global which gives a summary of the
LVM status and also shows just which version of the LVM kernel you are using.
# vgscan
# vgchange −ay
# vgchange −an
Follow the instructions below depending on the distribution of Linux you are running.
7.1. Caldera
It is necessary to edit the file /etc/rc.d/rc.boot. Look for the line that says "Mounting local
filesystems" and insert the vgscan and vgchange commands just before it.
You may also want to edit the the file /etc/rc.d/init.d/halt to deactivate the volume groups at
shutdown. Insert the
vgchange −an
command near the end of this file just after the filesystems are unmounted or mounted read−only, before the
comment that says "Now halt or reboot".
7.2. Debian
If you download the Debian lvm tool package, an initscript should be installed for you.
If you are installing LVM from source, you will still need to build your own initscript:
#!/bin/sh
case "$1" in
start)
/sbin/vgscan
/sbin/vgchange −ay
;;
stop)
/sbin/vgchange −an
;;
restart|force−reload)
exit 0
7.3. Mandrake
No initscript modifications should be necessary for current versions of Mandrake.
7.4. Redhat
For Redhat 7.0 and up, you should not need to modify any initscripts to enable LVM at boot time if LVM is
built into the kernel. If LVM is built as a module, it may be necessary to modify
/etc/rc.d/rc.sysinit to load the LVM module by adding "modprobe lvm−mod" before the section
that reads:
This init script fragment is from Red Hat 7.3 − other versions of Redhat may look slightly different.
For versions of Redhat older than 7.0, it is necessary to edit the file /etc/rc.d/rc.sysinit. Look for
the line that says "Mount all other filesystems" and insert the vgscan and vgchange commands just before it.
You should be sure that your root file system is mounted read/write before you run the LVM commands.
You may also want to edit the the file /etc/rc.d/init.d/halt to deactivate the volume groups at
shutdown. Insert the
vgchange −an
command near the end of this file just after the filesystems are mounted read−only, before the comment that
says "Now halt or reboot".
7.5. Slackware
Slackware 8.1 requires no updating of boot time scripts in order to make LVM work.
For versions previous to Slackware 8.1, you should apply the following patch to /etc/rc.d/rc.S
cd /etc/rc.d
cp −a rc.S rc.S.old
patch −p0 < rc.S.diff
PATH=/sbin:/usr/sbin:/bin:/usr/bin
@@ −28,19 +29,21 @@
READWRITE=yes
fi
+
# Check the integrity of all filesystems
if [ ! READWRITE = yes ]; then
− /sbin/fsck −A −a
+ /sbin/fsck −a /
+ # Check only the root fs first, but no others
# If there was a failure, drop into single−user mode.
if [ ? −gt 1 ] ; then
echo
echo
− echo "*******************************************************"
− echo "*** An error occurred during the file system check. ***"
− echo "*** You will now be given a chance to log into the ***"
− echo "*** system in single−user mode to fix the problem. ***"
− echo "*** Running 'e2fsck −v −y <partition>' might help. ***"
− echo "*******************************************************"
+ echo "************************************************************"
+ echo "*** An error occurred during the root file system check. ***"
+ echo "*** You will now be given a chance to log into the ***"
+ echo "*** system in single−user mode to fix the problem. ***"
+ echo "*** Running 'e2fsck −v −y <partition>' might help. ***"
+ echo "************************************************************"
echo
echo "Once you exit the single−user shell, the system will reboot."
echo
@@ −82,6 +85,44 @@
echo −n "get into your machine and start looking for the problem. "
read junk;
fi
+ # okay / fs is clean, and mounted as rw
+ # This was an addition, limits vgscan to /proc thus
+
# remove /etc/mtab* so that mount will create it with a root entry
/bin/rm −f /etc/mtab* /etc/nologin /etc/shutdownpid
7.6. SuSE
No changes should be necessary from 6.4 onward as LVM is included
If the need arises you can change some options with the configure script. Do a ./configure −−help to
determine which options are supported. Most of the time this will not be necessary.
There should be no errors from the build process. If there are, see Reporting Errors and Bugs on how to report
this.
You are welcome to fix them and send us the patches too. Patches are generally sent to the linux−lvm list.
Warning: New PVs initialized with LVM 1.0.8 are created with the PV version 1 on−disk structure. This
means that LVM 0.9.1 Beta8 and LVM 1.0 cannot read or use PVs created with 1.0.8.
Follow the steps outlined in Chapter 5 − Section 6.2 for instructions on how to get and build the
necessary kernel components of LVM.
2. Build the LVM user tools
Follow the steps in Chapter 9 to build and install the user tools for LVM.
3. Setup your init scripts
Make sure you have the proper init scripts setup as per Chapter 7.
4. Boot into the new kernel
Make sure your boot−loader is setup to load the new LVM−enhanced kernel and, if you are using
LVM modules, put an insmod lvm−mod into your startup script OR extend /etc/modules.conf
(formerly /etc/conf.modules) by adding
to enable modprobe to load the LVM module (don't forget to enable kmod).
The "normal" way of running an LVM root file system is to have a single non−LVM partition called /boot
which contains the kernel and initial RAM disk needed to start the system. The system I upgraded was as
follows:
# df
Filesystem 1k−blocks Used Available Use% Mounted on
/dev/rootvg/root 253871 93384 147380 39% /
/dev/hda1 17534 12944 3685 78% /boot
/dev/rootvg/home 4128448 4568 3914168 0% /home
/dev/rootvg/usr 1032088 332716 646944 34% /usr
/dev/rootvg/var 253871 31760 209004 13% /var
/boot contains the old kernel and an initial RAM disk as well as the LILO boot files and the following entry
in /etc/lilo.conf
# ls /boot
System.map lost+found vmlinux−2.2.16lvm
map module−info boot.0300
boot.b os2_d.b chain.b
initrd.gz
# tail /etc/lilo.conf
image=/boot/vmlinux−2.2.16lvm
label=lvm08
read−only
root=/dev/rootvg/root
initrd=/boot/initrd.gz
append="ramdisk_size=8192"
Follow the steps outlined in Chapter 5 − Section 6.2 for instructions on how to get and build the
necessary kernel components of LVM.
2. Build the LVM user tools
Follow the steps in Section 6.2 to build and install the user tools for LVM.
Install the new tools. Once you have done this you cannot do any LVM manipulation as they are not
compatible with the kernel you are currently running.
3. Rename the existing initrd.gz
# mv /boot/initrd.gz /boot/initrd08.gz
4. Edit /etc/lilo.conf
Make the existing boot entry point to the renamed file. You will need to reboot using this if something
goes wrong in the next reboot. The changed entry will look something like this:
image=/boot/vmlinux−2.2.16lvm
label=lvm08
read−only
Don't forget the put the new kernel version in there so that it picks up the correct modules.
6. Add a new entry into /etc/lilo.conf
This new entry is to boot the new kernel with its new initrd.
image=/boot/vmlinux−2.4.9lvm
label=lvm10
read−only
root=/dev/rootvg/root
initrd=/boot/initrd.gz
append="ramdisk_size=8192"
7. Re−run lilo
# /sbin/lilo
8. Reboot
When you get the LILO prompt select the new entry name (in this example lvm10) and your system
should boot into Linux using the new LVM version.
If the new kernel does not boot, then simply boot the old one and try to fix the problem. It may be that
the new kernel does not have all the correct device drivers built into it, or that they are not available in
the initrd. Remember that all device drivers (apart from LVM) needed to access the root device
should be compiled into the kernel and not as modules.
If you need to do any LVM manipulation when booted back into the old version, then simply
recompile the old tools and install them with
# make install
If you do this, don't forget to install the new tools when you reboot into the new LVM version.
When you are happy with the new system remember to change the ``default='' entry in your lilo.conf file so
that it is the default kernel.
DANGEROUS
The following commands will destroy the partition table on the disk being operated on. Be very
sure it is the correct disk.
For partitions:
• When using LVM 1 on PCs with DOS partitions, set the partition type to 0x8e using fdisk or some
other similar program. This step is unnecessary on PPC systems or when using LVM 2.
• Run pvcreate on the partition:
# pvcreate /dev/hdb1
This creates a volume group descriptor at the start of the /dev/hdb1 partition.
NOTE: If you are using LVM 1 with devfs it is essential to use the full devfs name of the device rather than
the symlinked name in /dev. So the above would be:
You can also specify the extent size with this command if the default of 32MB is not suitable for you with the
'−s' switch. In addition you can put some limits on the number of physical or logical volumes the volume can
have.
# vgchange −a y my_volume_group
# vgchange −a n my_volume_group
# vgremove my_volume_group
# pvdisplay /dev/hda1
−−− Physical volume −−−
PV Name /dev/hda1
VG Name myvg
PV Size 1.95 GB / NOT usable 4 MB [LVM: 122 KB]
PV# 1
PV Status available
Allocatable yes (but full)
Cur LV 1
PE Size (KByte) 4096
Total PE 499
Free PE 0
Allocated PE 499
If the physical volume is still used you will have to migrate the data to another physical volume using
pvmove.
To create a 100 LE large logical volume with 2 stripes and stripe size 4 KB.
If you want to create an LV that uses the entire VG, use vgdisplay to find the "Total PE" size, then use that
when running lvcreate.
If you want the logical volume to be allocated from a specific physical volume in the volume group, specify
the PV or PVs at the end of the lvcreate command line.
# umount /dev/myvg/homevol
# lvremove /dev/myvg/homevol
lvremove −− do you really want to remove "/dev/myvg/homevol"? [y/n]: y
lvremove −− doing automatic backup of volume group "myvg"
lvremove −− logical volume "/dev/myvg/homevol" successfully removed
After you have extended the logical volume it is necessary to increase the file system size to match. how you
do this depends on the file system you are using.
By default, most file system resizing tools will increase the size of the file system to be the size of the
underlying logical volume so you don't need to worry about specifying the same size for each of the two
commands.
1. ext2/ext3
Unless you have patched your kernel with the ext2online patch it is necessary to unmount the file
system before resizing it. (It seems that the online resizing patch is rather dangerous, so use at your
own risk)
# umount /dev/myvg/homevol/dev/myvg/homevol
# resize2fs /dev/myvg/homevol
# mount /dev/myvg/homevol /home
If you don't have e2fsprogs 1.19 or later, you can download the ext2resize command from
ext2resize.sourceforge.net and use that:
# umount /dev/myvg/homevol/dev/myvg/homevol
# resize2fs /dev/myvg/homevol
# mount /dev/myvg/homevol /home
For ext2 there is an easier way. LVM 1 ships with a utility called e2fsadm which does the lvextend
and resize2fs for you (it can also do file system shrinking, see the next section).
LVM 2 Caveat
There is currently no e2fsadm equivalent for LVM 2 and the e2fsadm that ships with LVM 1
does not work with LVM 2.
Note
You will still need to unmount the file system before running e2fsadm.
2. reiserfs
Reiserfs file systems can be resized when mounted or unmounted as you prefer:
♦ Online:
# resize_reiserfs −f /dev/myvg/homevol
♦ Offline:
# umount /dev/myvg/homevol
# resize_reiserfs /dev/myvg/homevol
# mount −treiserfs /dev/myvg/homevol /home
3. xfs
XFS file systems must be mounted to be resized and the mount−point is specified rather than the
device name.
# xfs_growfs /home
4. jfs
Just like XFS the JFS file system must be mounted to be resized and the mount−point is specified
rather than the device name. You need at least Version 1.0.21 of the jfs−utils to do this.
Example: If you were to resize a JFS file system to 4 gigabytes that has 4k blocks, you would
write:
1. ext2
If you are using LVM 1 with ext2 as the file system then you can use the e2fsadm command
mentioned earlier to take care of both the file system and volume resizing as follows:
# umount /home
# e2fsadm −L−1G /dev/myvg/homevol
# mount /home
LVM 2 Caveat
There is currently no e2fsadm equivalent for LVM 2 and the e2fsadm that ships with LVM 1
does not work with LVM 2.
If you prefer to do this manually you must know the new size of the volume in blocks and use the
following commands:
# umount /home
# resize2fs /dev/myvg/homevol 524288
# lvreduce −L−1G /dev/myvg/homevol
# mount /home
2. reiserfs
# umount /home
# resize_reiserfs −s−1G /dev/myvg/homevol
# lvreduce −L−1G /dev/myvg/homevol
# mount −treiserfs /dev/myvg/homevol /home
3. xfs
# pvcreate /dev/sda1
# pvcreate /dev/sdf
# pvcreate /dev/hda8
# pvcreate /dev/hda6
# pvcreate /dev/md1
In a "normal" production system it is recommended that only one PV exists on a single real disk, for the
following reasons:
• Administrative convenience
It's easier to keep track of the hardware in a system if each real disk only appears once. This becomes
particularly true if a disk fails.
• To avoid striping performance problems
LVM can't tell that two PVs are on the same physical disk, so if you create a striped LV then the
stripes could be on different partitions on the same disk resulting in a decrease in performance rather
than an increase.
On a system with few disks it may be necessary to move data around partitions to do the conversion
(see Section 13.8)
• Splitting one big disk between Volume Groups
If you have a very large disk and want to have more than one volume group for administrative
purposes then it is necessary to partition the drive into more than one area.
If you do have a disk with more than one partition and both of those partitions are in the same volume group,
take care to specify which partitions are to be included in a logical volume when creating striped volumes.
The recommended method of partitioning a disk is to create a single partition that covers the whole disk. This
avoids any nasty accidents with whole disk drive device nodes and prevents the kernel warning about
unknown partition types at boot−up.
If you want to use a disk with a Sun disk label with LVM, make sure that the partition you are going to use
starts at cylinder 1 or higher.
Warning!
The following will destroy any data on /dev/sda, /dev/sdb, and /dev/sdc
# pvcreate /dev/sda
# pvcreate /dev/sdb
# pvcreate /dev/sdc
This creates a volume group descriptor area (VGDA) at the start of the disks.
The most important things to verify are that the first three items are correct and that the VG Size item
is the proper size for the amount of space in all four of your disks.
You can make the logical volume any size you like. (It is similar to a partition on a non LVM setup.) For this
example we will create just a single logical volume of size 1GB on the volume group. We will not use striping
because it is not currently possible to add a disk to a stripe set after the logical volume is created.
# mke2fs /dev/my_volume_group/my_logical_volume
mke2fs 1.19, 13−Jul−2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131072 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
9 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
If everything worked properly, you should now have a logical volume with and ext2 file system mounted at
/mnt.
Note
It is not currently possible to add a disk to a striped logical volume in LVM 1. Use LVM 2 with the lvm
2 format metadata if you wish to be able to do so able to do so.
Warning!
The following will destroy any data on /dev/sda, /dev/sdb, and /dev/sdc
# pvcreate /dev/sda
# pvcreate /dev/sdb
# pvcreate /dev/sdc
This creates a volume group descriptor area (VGDA) at the start of the disks.
The most important things to verify are that the first three items are correct and that the VG Size item
is the proper size for the amount of space in all four of your disks.
You can make the logical volume any size you like (up to the size of the VG you are creating it on; it is
similar to a partition on a non LVM setup). For this example we will create just a single logical volume of size
1GB on the volume group. The logical volume will be a striped set using for the 4k stripe size. This should
increase the performance of the logical volume.
Note
If you create the logical volume with a '−i2' you will only use two of the disks in your volume group.
This is useful if you want to create two logical volumes out of the same physical volume, but we will not
touch that in this recipe.
# mke2fs /dev/my_volume_group/my_logical_volume
mke2fs 1.19, 13−Jul−2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
132192 inodes, 264192 blocks
13209 blocks (5.00%) reserved for the super user
First data block=0
9 block groups
32768 blocks per group, 32768 fragments per group
14688 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
# df
Filesystem 1k−blocks Used Available Use% Mounted on
/dev/hda1 1311552 628824 616104 51% /
/dev/my_volume_group/my_logical_volume
1040132 20 987276 0% /mnt
If everything worked properly, you should now have a logical volume mounted at /mnt.
# pvscan
pvscan −− ACTIVE PV "/dev/sda" of VG "dev" [1.95 GB / 0 free]
pvscan −− ACTIVE PV "/dev/sdb" of VG "sales" [1.95 GB / 0 free]
pvscan −− ACTIVE PV "/dev/sdc" of VG "ops" [1.95 GB / 44 MB free]
pvscan −− ACTIVE PV "/dev/sdd" of VG "dev" [1.95 GB / 0 free]
pvscan −− ACTIVE PV "/dev/sde1" of VG "ops" [996 MB / 52 MB free]
pvscan −− ACTIVE PV "/dev/sde2" of VG "sales" [996 MB / 944 MB free]
pvscan −− ACTIVE PV "/dev/sdf1" of VG "ops" [996 MB / 0 free]
pvscan −− ACTIVE PV "/dev/sdf2" of VG "dev" [996 MB / 72 MB free]
pvscan −− total: 8 [11.72 GB] / in use: 8 [11.72 GB] / in no VG: 0 [0]
# df
Filesystem 1k−blocks Used Available Use% Mounted on
/dev/dev/cvs 1342492 516468 757828 41% /mnt/dev/cvs
/dev/dev/users 2064208 2060036 4172 100% /mnt/dev/users
/dev/dev/build 1548144 1023041 525103 66% /mnt/dev/build
/dev/ops/databases 2890692 2302417 588275 79% /mnt/ops/databases
/dev/sales/users 2064208 871214 1192994 42% /mnt/sales/users
/dev/ops/batch 1032088 897122 134966 86% /mnt/ops/batch
As you can see the "dev" and "ops" groups are getting full so a new disk is purchased and added to the system.
It becomes /dev/sdg.
# fdisk /dev/sdg
Device contains neither a valid DOS partition table, nor Sun or SGI
disklabel Building a new DOS disklabel. Changes will remain in memory
only, until you decide to write them. After that, of course, the
previous content won't be recoverable.
# pvcreate /dev/sdg1
pvcreate −− physical volume "/dev/sdg1" successfully created
# pvcreate /dev/sdg2
pvcreate −− physical volume "/dev/sdg2" successfully created
There are tools to allow online−resizing of ext2 file systems but here we take the safe route and unmount the
two file systems before resizing them:
# umount /mnt/ops/batch
# umount /mnt/dev/users
We then use the e2fsadm command to resize the logical volume and the ext2 file system on one operation. We
are using ext2resize instead of resize2fs (which is the default command for e2fsadm) so we define the
environment variable E2FSADM_RESIZE_CMD to tell e2fsadm to use that command.
# export E2FSADM_RESIZE_CMD=ext2resize
# e2fsadm /dev/ops/batch −L+500M
e2fsck 1.18, 11−Nov−1999 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/ops/batch: 11/131072 files (0.0<!−− non−contiguous), 4127/262144 blocks
lvextend −− extending logical volume "/dev/ops/batch" to 1.49 GB
lvextend −− doing automatic backup of volume group "ops"
lvextend −− logical volume "/dev/ops/batch" successfully extended
# mount /dev/ops/batch
# mount /dev/dev/users
# df
Filesystem 1k−blocks Used Available Use% Mounted on
/dev/dev/cvs 1342492 516468 757828 41% /mnt/dev/cvs
/dev/dev/users 2969360 2060036 909324 69% /mnt/dev/users
/dev/dev/build 1548144 1023041 525103 66% /mnt/dev/build
/dev/ops/databases 2890692 2302417 588275 79% /mnt/ops/databases
/dev/sales/users 2064208 871214 1192994 42% /mnt/sales/users
/dev/ops/batch 1535856 897122 638734 58% /mnt/ops/batch
This type of volume is a read−only copy of another volume that contains all the data that was in the volume at
the time the snapshot was created. This means we can back up that volume without having to worry about data
being changed while the backup is going on, and we don't have to take the database volume offline while the
backup is taking place.
If the snapshot is of an XFS filesystem, the xfs_freeze command should be used to quiesce the filesystem before c
snapshot. (if the filesystem is mounted)
# mkdir /mnt/ops/dbbackup
# mount /dev/ops/dbbackup /mnt/ops/dbbackup
mount: block device /dev/ops/dbbackup is write−protected, mounting read−only
If you are using XFS as the filesystem you will need to add the nouuid option to the mount command:
Previously, the norecovery option was suggested to allow the mounting of XFS snapshots. It has been
recommended not to use this option, but to instead use xfs_freeze to quiesce the filesystem before
creating the snapshot.
# umount /mnt/ops/dbbackup
# lvremove /dev/ops/dbbackup
lvremove −− do you really want to remove "/dev/ops/dbbackup"? [y/n]: y
lvremove −− doing automatic backup of volume group "ops"
lvremove −− logical volume "/dev/ops/dbbackup" successfully removed
# pvmove /dev/hdb
pvmove −− moving physical extents in active volume group "dev"
pvmove −− WARNING: moving of active logical volumes may cause data loss!
pvmove −− do you want to continue? [y/n] y
pvmove −− 249 extents of physical volume "/dev/hdb" successfully moved
This will move the allocated physical extents from /dev/hdb onto the rest of the disks in the volume group.
pvmove is Slow
Be aware that pvmove is quite slow as it has to copy the contents of a disk block by block to one or more
disks. If you want more steady status reports from pvmove, use the −v flag.
We can now remove the old IDE disk from the volume group.
The drive can now be either physically removed when the machine is next powered down or reallocated to
other users.
First, you need to pvcreate the new disk to make it available to LVM. In this recipe we show that you don't
need to partition a disk to be able to use it.
# pvcreate /dev/sdf
pvcreate −− physical volume "/dev/sdf" successfully created
As developers use a lot of disk space this is a good volume group to add it into.
Next we move the data from the old disk onto the new one. Note that it is not necessary to unmount the file
system before doing this. Although it is *highly* recommended that you do a full backup before attempting
this operation in case of a power outage or some other problem that may interrupt it. The pvmove command
can take a considerable amount of time to complete and it also exacts a performance hit on the two volumes
so, although it isn't necessary, it is advisable to do this when the volumes are not too busy.
We can now remove the old IDE disk from the volume group.
The drive can now be either physically removed when the machine is next powered down or reallocated to
some other users.
vgexport/vgimport is not necessary to move drives from one system to another. It is an administrative
policy tool to prevent access to volumes in the time it takes to move them.
# unmount /mnt/design/users
# vgexport design
vgexport −− volume group "design" successfully exported
When the machine is next shut down, the disk can be unplugged and then connected to it's new machine
# pvscan
pvscan −− reading all physical volumes (this may take a while...)
pvscan −− inactive PV "/dev/sdb1" is in EXPORTED VG "design" [996 MB / 996 MB free]
pvscan −− inactive PV "/dev/sdb2" is in EXPORTED VG "design" [996 MB / 244 MB free]
pvscan −− total: 2 [1.95 GB] / in use: 2 [1.95 GB] / in no VG: 0 [0]
We can now import the volume group (which also activates it) and mount the file system.
# vgimport design
Volume group "vg" successfully imported
If you are importing on an LVM 1 system, add the PVs that need to be imported:
We decide to reallocate /dev/sdg1 and /dev/sdg2 to design so first we have to move the physical extents into
the free areas of the other volumes (in this case /dev/sdf for volume group dev and /dev/sde for volume group
ops).
Move all the used physical extents from /dev/sdg1 to /dev/sde and from /dev/sdg2 to /dev/sde
It's also a good idea to add an entry for this file system in your /etc/fstab file as follows:
/dev/design/user
/mnt/design/users ext2 defaults 1 2
Upgrade Complications
Having your root filesystem on LVM 1 can significantly complicate upgrade procedures (depending on
your distribution) so it should not be attempted lightly. Particularly, you must consider how you will
insure that the LVM 1 kernel module (if you do not have LVM 1 compiled into the kernel) as well as the
vgscan/vgchange tools are available before, during, and after the upgrade.
Recovery Complications
Having your root filesystem on LVM 1 can significantly complicate recovery of damaged filesystems. If
you lose your initrd, it will be very difficult to boot your system. You will need to have a recover disk
that contains the kernel, LVM 1 module, and LVM 1 tools, as well as any tools necessary to recover a
damaged filesystem. Be sure to make regular backups and have an up−to−date alternative boot method
that allows for recovery of LVM 1.
In this example the whole system was installed in a single root partition with the exception of /boot. The
system had a 2 gig disk partitioned as:
/dev/hda1 /boot
/dev/hda2 swap
/dev/hda3 /
The / partition covered all of the disk not used by /boot and swap. An important prerequisite of this procedure
is that the root partition is less that half full (so that a copy of it can be created in a logical volume). If this is
not the case then a second disk drive should be used. The procedure in that case is similar but there is no need
to shrink the existing root partition and /dev/hda4 should be replaced with (eg) /dev/hdb1 in the examples.
To do this it is easiest to use GNU parted. This software allows you to grow and shrink partitions that contain
filesystems. It is possible to use resize2fs and fdisk to do this but GNU parted makes it much less prone to
error. It may be included in your distribution, if not you can download it from
ftp://ftp.gnu.org/pub/gnu/parted.
Once you have parted on your system AND YOU HAVE BACKED THE SYSTEM UP:
# parted /dev/hda
(parted) p
.
.
.
The first number here the partition number (hda3), the second is the same starting position that hda3 currently
has. Do not change this. The last number should make the partition around half the size it currently is.
This makes a new partition to hold the initial LVM 1 data. It should start just beyond the newly shrunk hda3
and finish at the end of the disk.
Quit parted
(parted) q
13.8.3. Reboot
Reboot the system
# fdisk /dev/hda
Command (m for help): t
Partition number (1−4): 4
Hex code (type L to list codes): 8e
Changed system type of partition 4 to 8e (Unknown)
Command (m for help): w
# mke2fs /dev/vg/root
# mount /dev/vg/root /mnt/
# find / −xdev | cpio −pvmd /mnt
becomes:
Make sure you note the name that lvmcreate_initrd calls the initrd image. It should be in /boot.
image = /boot/KERNEL_IMAGE_NAME
label = lvm
root = /dev/vg/root
initrd = /boot/INITRD_IMAGE_NAME
ramdisk = 8192
Where KERNEL_IMAGE_NAME is the name of your LVM 1 enabled kernel, and INITRD_IMAGE_NAME
is the name of the initrd image created by lvmcreate_initrd. The ramdisk line may need to be increased if you
have a large LVM 1 configuration, but 8192 should suffice for most users. The default ramdisk size is 4096. If
in doubt check the output from the lvmcreate_initrd command, the line that says:
You should copy this new lilo.conf onto /etc in the new root fs as well.
# cp /etc/lilo.conf /mnt/etc/
If that worked then you should make lvm the default LILO boot destination by adding the line
default=lvm
If it did not work then reboot normally and try to diagnose the problem. It could be a typing error in lilo.conf
or LVM 1 not being available in the initial RAM disk or its kernel. Examine the message produced at boot
time carefully.
# fdisk /dev/hda
# pvcreate /dev/hda3
# vgextend vg /dev/hda3
• Download the UUID fixer program from the contributor directory at Sistina.
It is located at ftp://ftp.sistina.com/pub/LVM/contrib/uuid_fixer−0.3−IOP10.tar.gz"
• Extract uuid_fixer−0.3−IOP10.tar.gz
# tar zxf uuid_fixer−0.3−IOP10.tar.gz
• cd to uuid_fixer
# cd uuid_fixer
Make sure you list all the PVs in the VG you are restoring, and follow the prompts
Edit the Makefile with your favorite editor, and make sure LVMDIR points to your LVM
source.
# make
Now run uuid_fixer. Make sure you list all the PVs in the VG you are restoring, and follow
the prompts.
• Run vgscan
# vgscan
If you have a fibre−channel or shared−SCSI environment where more than one machine has physical access
to a set of disks then you can use LVM to divide these disks up into logical volumes. If you want to share data
you should really be looking at GFS or other cluster filesystems.
The key thing to remember when sharing volumes is that all the LVM administration must be done on one
node only and that all other nodes must have LVM shut down before changing anything on the admin node.
Then, when the changes have been made, it is necessary to run vgscan on the other nodes before reloading the
volume groups. Also, unless you are running a cluster−aware filesystem (such as GFS) or application on the
volume, only one node can mount each filesystem. It is up to you, as system administrator to enforce this,
LVM will not stop you corrupting your data.
The startup sequence of each node is the same as for a single−node setup with
vgscan
vgchange −ay
If you need to do any changes to the LVM metadata (regardless of whether it affects volumes mounted on
other nodes) you must go through the following sequence. In the steps below ``admin node'' is any arbitrarily
chosen node in the cluster.
1. Detail the specific version of LVM you have. If you extracted LVM from a tarball give the
name of the tar file and list any patches you applied. If you acquired LVM from the Public
CVS server, give the date and time you checked it out.
2. Provide the exact error message. Copy the lines of output before the actual error message as
well as the lines after. These lines occasionally give hints as to why the error occurred.
3. List the steps, in order, that produced the error. Is the error reproducible? If you start from a
clean state does the same sequence of steps reproduce the error?
• For LVM errors:
This can be a lot of information. If you end up with more than a couple of files, tar and gzip them into a single
archive. Submit a link to where this file can be found to the appropriate mailing list (see Section C.1) along
with a short description of the error. If you do not have a public web or ftp site that you can post the
information to, you can try to submit the file to the list.
linux−lvm
This list is aimed at user−related questions and comments. You may be able to get the answers you
need from other people who have the same issues. Open discussion is encouraged. Bug reports should
be sent to this list.
lvm2−commit
This list gets messages automatically whenever someone commits to the lvm2 cvs tree. Its main
purpose is to keep up with the cvs tree.
Discontinued Lists
lvm−devel
This list has been discontinued; please use linux−lvm for lvm development discussion.
C.2. Links
LVM Links:
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330,
Boston, MA 02111−1307 USA Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
D.1. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in
the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and
publisher a way to get credit for their work, while not being considered responsible for modifications made by
others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be
free in the same sense. It complements the GNU General Public License, which is a copyleft license designed
for free software.
We have designed this License in order to use it for manuals for free software, because free software needs
free documentation: a free program should come with manuals providing the same freedoms that the software
does. But this License is not limited to software manuals; it can be used for any textual work, regardless of
subject matter or whether it is published as a printed book. We recommend this License principally for works
whose purpose is instruction or reference.
A "Modified Version" of the Document means any work containing the Document or a portion of it, either
copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front−matter section of the Document that deals exclusively
with the relationship of the publishers or authors of the Document to the Document's overall subject (or to
related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the
Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The
relationship could be a matter of historical connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of
Invariant Sections, in the notice that says that the Document is released under this License. If a section does
not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document
The "Cover Texts" are certain short passages of text that are listed, as Front−Cover Texts or Back−Cover
Texts, in the notice that says that the Document is released under this License. A Front−Cover Text may be at
most 5 words, and a Back−Cover Text may be at most 25 words.
A "Transparent" copy of the Document means a machine−readable copy, represented in a format whose
specification is available to the general public, that is suitable for revising the document straightforwardly
with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some
widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to
a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format
whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by
readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A
copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input
format, LaTeX input format, SGML or XML using a publicly available DTD, and standard−conforming
simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats
include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally
available, and the machine−generated HTML, PostScript or PDF produced by some word processors for
output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to
hold, legibly, the material this License requires to appear in the title page. For works in formats which do not
have any title page as such, "Title Page" means the text near the most prominent appearance of the work's
title, preceding the beginning of the body of the text.
A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or
contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a
specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or
"History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a
section "Entitled XYZ" according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to
the Document. These Warranty Disclaimers are considered to be included by reference in this License, but
only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is
void and has no effect on the meaning of this License.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as
many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either
include a machine−readable Transparent copy along with each Opaque copy, or state in or with each Opaque
copy a computer−network location from which the general network−using public has access to download
using public−standard network protocols a complete Transparent copy of the Document, free of added
material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of
Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated
location until at least one year after the last time you distribute an Opaque copy (directly or through your
agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any
large number of copies, to give them a chance to provide you with an updated version of the Document.
D.5. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3
above, provided that you release the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution and modification of the Modified Version
to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from
those of previous versions (which should, if there were any, be listed in the History section of the
Document). You may use the same title as a previous version if the original publisher of that version
gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the
modifications in the Modified Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has fewer than five), unless they release you from this
requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use
the Modified Version under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the
Document's license notice.
If the Modified Version includes new front−matter sections or appendices that qualify as Secondary Sections
and contain no material copied from the Document, you may at your option designate some or all of these
sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's
license notice. These titles must be distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your
Modified Version by various parties−−for example, statements of peer review or that the text has been
approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front−Cover Text, and a passage of up to 25 words as a
Back−Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of
Front−Cover Text and one of Back−Cover Text may be added by (or through arrangements made by) any one
entity. If the Document already includes a cover text for the same cover, previously added by you or by
arrangement made by the same entity you are acting on behalf of, you may not add another; but you may
replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for
publicity for or to assert or imply endorsement of any Modified Version.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may
be replaced with a single copy. If there are multiple Invariant Sections with the same name but different
contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the
original author or publisher of that section if known, or else a unique number. Make the same adjustment to
the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled "History" in the various original documents,
forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any
sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".
You may extract a single document from such a collection, and distribute it individually under this License,
provided you insert a copy of this License into the extracted document, and follow this License in all other
respects regarding verbatim copying of that document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document
is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket
the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic
form. Otherwise they must appear on printed covers that bracket the whole aggregate.
D.9. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the
terms of section 4. Replacing Invariant Sections with translations requires special permission from their
copyright holders, but you may include translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a translation of this License, and all the license
notices in the Document, and any Warranty Disclaimers, provided that you also include the original English
version of this License and the original versions of those notices and disclaimers. In case of a disagreement
between the translation and the original version of this License or a notice or disclaimer, the original version
will prevail.
D.10. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this
License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However, parties who have received copies, or rights,
from you under this License will not have their licenses terminated so long as such parties remain in full
compliance.
Each version of the License is given a distinguishing version number. If the Document specifies that a
particular numbered version of this License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or of any later version that has been
published (not as a draft) by the Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not as a draft) by the Free Software
Foundation.
Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify
this document under the terms of the GNU Free Documentation License, Version 1.2 or any
later version published by the Free Software Foundation; with no Invariant Sections, no
Front−Cover Texts, and no Back−Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
If you have Invariant Sections, Front−Cover Texts and Back−Cover Texts, replace the "with...Texts." line
with this:
with the Invariant Sections being LIST THEIR TITLES, with the Front−Cover Texts being
LIST, and with the Back−Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two
alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in
parallel under your choice of free software license, such as the GNU General Public License, to permit their
use in free software.