Simple partition resizing operations, such as those described in Part 1 of this series, usually conclude successfully.
Sometimes, though, you need to do something different or troubleshoot problems. This article covers some of these situations.
The first topic is LVM configuration and how it interacts with partition resizing. The second topic is troubleshooting
techniques. Although a complete description of all the problems that can occur when resizing partitions might fill a
book, a few basic principles can help you work through many common problems. Finally, this article describes some alternatives
to partition resizing, should the problems you encounter prove insurmountable.
Resizing LVMs
LVM is a disk allocation technique that supplements or replaces traditional partitions. In an LVM configuration,
one or more partitions, or occasionally entire disks, are assigned as physical volumes in a volume group,
which in turn is broken down into logical volumes. File systems are then created on logical volumes, which are
treated much like partitions in a conventional configuration. This approach to disk allocation adds complexity, but
the benefit is flexibility. An LVM configuration makes it possible to combine disk space from several small disks into
one big logical volume. More important for the topic of partition resizing, logical volumes can be created, deleted,
and resized much like files on a file system; you needn't be concerned with partition start points, only with their
absolute size.
Note: I don't attempt to describe how to set up an LVM in this article. If you don't already use an LVM configuration,
you can convert your system to use one, but you should consult other documentation, such as the Linux LVM HOWTO (see
Resources), to learn how to do so.
Resizing physical volumes
If you've resized non-LVM partitions, as described in Part 1 of this series, and want to add the space to your LVM
configuration, you have two choices:
- You can create a new partition in the empty space and add the new partition to your LVM.
- You can resize an existing LVM partition, if it's contiguous with the new space.
Unfortunately, the GParted (also known as Gnome Partition Editor) tool described in Part 1 of this series does not
support resizing LVM partitions. Therefore, the easiest way to add space to your volume group is to create a new partition
in the free space and add it as a new physical volume to your existing volume group.
Although GParted can't directly create an LVM partition, you can do so with one of the following tools:
- parted (text-mode GNU Parted)
- fdisk for Master Boot Record (MBR) disks
- gdisk for globally unique identifier (GUID) Partition Table (GPT) disks
If you use parted, you can use the set command to turn on the lvm flag, as in set
1 lvm on to flag partition 1 as an LVM partition. Using fdisk, you should use the t command to
set the partition's type code to 8e. You do the same with gdisk, except that its type code for LVM partitions
is 8e00.
In any of these cases, you must use the pvcreate command to set up the basic LVM data structures on the
partition and then vgextend to add the partition to the volume group. For instance, to add /dev/sda1 to the
existing MyGroup volume group, you type the following commands:
pvcreate /dev/sda1
vgextend MyGroup /dev/sda1
With these changes finished, you should be able to extend the logical volumes in your volume group, as described shortly.
Resizing logical volumes
For file systems, resizing logical volumes can be simpler than resizing partitions because LVM obviates the need
to set aside contiguous sets of numbered sectors in the form of partitions. Resizing the logical volume itself is accomplished
by means of the lvresize command. This command takes a number of options (consult its man page for
details), but the most important is -L, which takes a new size or a change in size, a change being denoted
by a leading plus (+) or minus (-) sign. You must also offer a path to the logical volume. For instance, suppose you
want to add 5 gibibytes (GiB) to the size of the usr logical volume in the MyGroup group. You could
do so as follows:
lvresize -L +5G /dev/mapper/MyGroup-usr
This command adjusts the size of the specified logical volume. Keep in mind, however, that this change is much like
a change to a partition alone. That is, the size of the file system contained in the logical volume is not altered.
To adjust the file system, you must use a file system-specific tool, such as resize2fs, resizereiserfs,
xfs_growfs, or the resize mount option when mounting Journaled File System (JFS). When used without
size options, these tools all resize the file system to fill the new logical volume size, which is convenient when growing
a logical volume.If you want to shrink a logical volume, the task is a bit more complex. You must first resize the
file system (using resize2fs or similar tools) and then shrink the logical volume to match the new size. Because
of the potential for a damaging error should you accidentally set the logical volume size too small, I recommend first
shrinking the file system to something significantly smaller than your target size, then resizing the logical volume
to the correct new size, and then resizing the file system again to increase its size, relying on the auto-sizing feature
to have the file system exactly fill the new logical volume size.
Remember also that, although you can shrink most Linux-native file systems, you can't shrink XFS or JFS. If you need
to shrink a logical volume containing one of these file systems, you may have to create a new smaller logical volume,
copy the first one's contents to the new volume, juggle your mount points, and then delete the original. If you lack
sufficient free space to do this, you may be forced to use a backup as an intermediate step.
Using GUI LVM tools
Although the text-mode tools just described get the job done, they can be intimidating. If you prefer to work with
graphical user interface (GUI) tools, at least two are available for LVM operations:
- kvpm-This is a tool that integrates with the K Desktop Environment (KDE) and provides access to common
LVM operations, including logical volume resizing options.
- system-config-lvm-This program originated with Red Hat, but is available in some other distributions.
It's similar to kvpm in that it provides point-and-click access to LVM management, including resizing operations.
Of the two, system-config-lvm provides a somewhat simpler and friendlier user interface; however, either will get
the job done. Figure 1 shows system-config-lvm in action. To resize a logical volume, you click
its name in the left panel, then click the Edit Properties button that appears in the middle panel. You can then
use a slider to adjust the volume's size.
Troubleshooting problemsUnfortunately, partition resizing operations sometimes
don't work as expected. Most commonly, the resizing software reports an error, frequently with a cryptic message. Although
there are numerous possible causes of such problems, you can overcome a great many of them by applying a few simple
workarounds, such as fixing file system problems and breaking a complex resizing operation down into several parts.
Fixing file system problems
One common cause of resizing failures is a damaged file system. All production file systems include file system recovery
tools that enable you to fix such problems, so running them on a file system prior to resizing it can often make for
a smoother resizing operation.
In Linux, the file system check tool is called fsck, and you call it by passing it the device filename associated
with the file system you want to check, as in fsck /dev/sda1 to check /dev/sda1. The fsck
utility, however, is mainly a front-end to file system-specific tools, such as e2fsck (for ext2fs, ext3fs,
and ext4fs). You can often gain access to more advanced options by calling the file system-specific tool directly. The
-f option to e2fsck, for instance, forces it to check the device even if the file system appears to
be clean. This option may be necessary to uncover corruption that's not obvious in a cursory examination. Check the
documentation for your file system-specific fsck helper program to learn about its options.
In most cases, it's necessary to run fsck or its helper program on an unmounted file system. Thus, you may
need to do this from an emergency boot disc, as described in Part 1 of this series.
If you run into problems with a non-Linux file system, you may be able to use fsck to check it; however,
you may also need to boot into the file system's native operating system to do the job properly. In particular, Microsoft®
Windows® New Technology File System (NTFS) has only rudimentary maintenance tools in Linux. You must use the Windows
CHKDSK utility to do a proper job of checking NTFS. You may need to run this utility several times, until it
reports no more problems with the disk. The Linux ntfsfix utility performs what few checks are possible in
Linux and then flags the file system for automatic checking the next time Windows boots.
Although not a file system integrity issue per se, disk fragmentation is another issue that might need attention.
You can sometimes eliminate problems by performing a disk defragmenting operation prior to a resizing operation. This
task is seldom necessary (and is usually not possible) with Linux native file systems; however, it may help with File
Allocation Table (FAT) or NTFS partitions.
Breaking the operation into parts
If you enter a number of resizing and moving operations into GParted and the operation fails, you can try entering
just one operation at a time and then immediately clicking the Apply button. You might still run into problems,
but you may at least be able to perform other operations that aren't dependent on the one that causes problems. Depending
on the details, you may be able to achieve at least some of your overall goals or find some other way to work around
the problem.
In some cases, you may be able to split the resizing operation across multiple utilities. For instance, you may be
able to use a Windows or Mac OS X utility to resize FAT, NTFS, or Hierarchical File System Plus (HFS+) partitions. Although
GParted is the most user-friendly way to resize partitions in Linux, if just one operation is causing problems, using
an underlying text-mode utility, such as resize2fs, may provide you with better diagnostic output or even succeed
where GParted fails. Keep in mind, however, that most text-mode tools resize either partitions or file systems, but
not both; you must combine both types of tools to resize a partition and its file system. The GNU Parted utility
is an exception to this rule; like its GUI cousin, GParted, Parted resizes partitions and their contained file systems
simultaneously.
Going to plan B
Sometimes an attempt to resize your partitions just doesn't work. Perhaps a file system has errors that can't be
easily resolved, or maybe you need to shrink a file system (such as XFS or JFS) that can't be shrunk. In these cases,
you must move on to an alternative, such as relocating directories in your existing partition structure, performing
a backup-repartition-restore operation, or adding more disk space.
Relocating directories without repartitioning
Sometimes you can relocate directories without actually repartitioning the disk. The trick is to use symbolic links
to point from one location to another, even across partitions. For instance, suppose you're using a Gentoo system, which
can consume vast quantities of disk space in the /usr/portage and /var/tmp/portage directories. If you didn't consider
these needs when setting up your system, you might run out of space. You might, however, have space available on a separate
/home partition. To use this space for Portage, you can create one or more directories in /home, copy the contents of
/usr/portage or /var/tmp/portage to the new directories, delete the original directories, and create symbolic links
in place of the originals that point to the new subdirectories of /home.
This approach can be effective and is convenient on a small scale; however, it does create a somewhat non-standard
system, and it removes many of the advantages of using separate partitions. Thus, I recommend using this approach sparingly
and preferably only on a short-term basis-for instance, as a stop-gap measure while you wait for a new hard disk to
arrive or on a system you plan to retire in a month or two.
Backing up, repartitioning, and restoring
Prior to the development of file system resizing tools, the only practical way to repartition a disk was to back
up its contents, repartition (creating new empty file systems), and restore the backup to the repartitioned disk. This
approach continues to work, but of course it's less convenient than using GParted to repartition nondestructively. On
the other hand, for safety it's best to create a backup before resizing partitions. So to be safe, you have to do half
of this job anyway.
In today's world, an external hard drive is often used as a backup medium. You can buy terabyte external disks for
under $100, and after your partition juggling you can use them to back up your important files, to transfer large files
between systems, or in other ways. Alternatively, you can use recordable DVDs, tape units, or network servers as backup
systems.
Backup software can include old standbys such as tar or newer tools such as Clonezilla. Operational details
vary depending on the software and the backup medium, so you should consult the backup software's documentation for
details.
If you need to modify your Linux boot partition or any partition that's required for basic root (superuser) access,
you need to perform these operations from an emergency boot system. Part 1 of this series described such systems.
Adding disk space
Adding a disk can be a viable alternative to repartitioning, and in some cases, adding disk space may be preferable.
Disk capacities continue to increase, and a newer disk is likely to be more reliable than one that's several years old.
If you choose to replace an existing disk with a newer one, you should be able to transfer your existing system to
the newsk and tar. You may need to reinstall your boot loader, and, for this task, a boot using a tool such
as the Super Grub Disk may be helpful. You can boot your system using this CD-based boot loader, then use grub-install
or a similar tool to reinstall the GRand Unified Bootloader (GRUB) to your new hard disk.
If you buy a new disk to supplement, rather than replace, your existing disk, you need to decide what, if any, data
to transfer to the new disk. You should partition the new disk using fdisk, GParted, or some other tool, transfer
files to the new partitions, and then permanently mount the new disk's partitions in your existing directory tree by
editing /etc/fstab appropriately. Remember to delete any files you transfer to the new disk from the old disk. If you
don't, they'll continue to consume disk space on the old disk, even if you mount the new disk to take over the original
files' directories.
Summary
However you do it, altering a working system's disk allocation can be an anxiety-inducing task, and for good reason:
Many things can go wrong. If such changes are necessary, though, you'll find that your system is more usable after you
make your changes. With a reduced risk of disk-full errors, you can get on with actually using your system for its intended
task. The process of resizing your partitions can also help familiarize you with GParted and other disk utilities, as
well as with the optimum sizes for various partitions. All of this can be useful knowledge the next time you install
a new Linux system.
Manage volumes
To manage volumes, you need to know how to reduce LVs and how to remove PVs.
Reducing logical volumes
You can reduce an LV in the same way you extend one, using the lvreduce command. From the LVM side, this operation
can always be done with the volume online. One caveat: the majority of filesystems don't support online filesystem shrinking.
Listing 10 demonstrates a sample procedure:
Listing 10. Reducing an LV#unmount LV
umount /path/to/mounted-volume
#shrink filesystem to 4G
resize_reiserfs -s 4G /dev/test-volume/data
#reduce LV
lvreduce -L 4G /dev/vg00/test
Be careful with sizes and units: the filesystem should not be longer than the LV!
Removing physical volumes
Imagine the following situation: You have a volume group with two 80GB disks, and you want to upgrade those to 160GB
disks. With LVM, you can remove a PV from a VG in the same way they are added (that means online!). Notice, though,
that you can't remove PVs that are being used in an LV. For those situations, there is a great utility called pvmove
that can free PVs online so you can replace them easily. In a hot-swap environment, you can even swap all disks with
no downtime at all!
pvmove's only requirement is a contiguous number of free extents in the VG equivalent to the number of extents
to be moved out of a PV. There's no easy way to directly determine the largest free set of contiguous PEs, but you can
use pvdisplay -m to display the PV allocation map:
Listing 11. Displaying the PV allocation map
#shows the allocation map
pvdisplay -m
--- Physical volume ---
PV Name /dev/hda6
VG Name test-volume
PV Size 4.91 GB / not usable 1.34 MB
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 1200
Free PE 0
Allocated PE 1200
PV UUID BA99ay-tOcn-Atmd-LTCZ-2KQr-b4Z0-CJ0FjO
--- Physical Segments ---
Physical extent 0 to 2367:
Logical volume /dev/test-volume/data
Logical extents 5692 to 8059
Physical extent 2368 to 2499:
Logical volume /dev/test-volume/data
Logical extents 5560 to 5691
--- Physical volume ---
PV Name /dev/hda7
VG Name test-volume
PV Size 9.77 GB / not usable 1.37 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 2500
Free PE 1220
Allocated PE 1280
PV UUID Es9jwb-IjiL-jtd5-TgBx-XSxK-Xshj-Wxnjni
--- Physical Segments ---
Physical extent 0 to 1279:
Logical volume /dev/test-volume/LV0
Logical extents 0 to 1279
Physical extent 1280 to 2499:
FREE
In Listing 11, note that there are 2,499-1,280 = 1,219 free contiguous extents available, meaning that we can move
up to 1,219 extents from another PV to /dev/hda7.
If you want to free a PV for replacement purposes, it's a good idea to disable its allocation so that you can be
sure it remains free until you remove it from the volume group. Issue this before moving out the data:
Listing 12. Before freeing, disable a PV's allocation
#Disable /dev/hda6 allocation
pvchange -xn /dev/hda6
Once free, see that the PV /dev/hda6 is 1,200 extents large and there are no free extents. To move the data from
this PV, issue the following:
Listing 13. Moving data from the freed PV
#Move allocated extents out of /dev/hda6
pvmove -i 10 /dev/hda6
The -i 10 parameter in Listing 13 tells pvmove to report back status once every 10 seconds. Depending
on how large the data to be moved is, this operation can take several minutes (or hours). This can also be done in the
background with the -b parameter. In this case, status would be reported to the syslog.
In case you just don't have enough free contiguous extents to use in a pvmove operation, remember that you
can always add one or more disks/partitions to a VG, thus adding a contiguous space, free for pvmove
use.
Other useful LVM operations
Consult the man pages for more details on these other useful LVM operations:
- pvresize extends PVs if the underlying partition has also been extended; it shrinks PV if the allocation
map permits it.
- pvremove destroys PVs (wipes its metadata clean). Use only after the PV had been removed from
a VG with vgreduce.
- vgreduce removes unallocated PVs from a volume group, reducing the VG.
- vgmerge merges two different VGs into one. The target VG can be online!
- vgsplit splits a volume group.
- vgchange changes attributes and permissions of a VG.
- lvchange changes attributes and permissions of a LV.
- lvconvert converts between a linear volume and a mirror or snapshot and vice versa.
Extend volumes
This is the easy part. If you have enough free space in the volume group, you just have to use lvextend
in order to extend the volume. There's no need to unmount it. Afterwards, also extend the filesystem inside the logical
volume (they are two separate things, remember). Depending on the filesystem you're using, it also can be extended online
(that's it, while mounted!).
If you don't have enough space in your VG, you'll need to add additional physical disks first. To do that:
- Use a free partition to create a physical disk. It is recommended that you change the partition type to 0x8e
(Linux LVM) for easy identification of LVM partitions/disks. Use pvcreate to initialize the Physical Disk:
pvcreate /dev/hda3.
- Then, use vgextend to add it to an existing VG: vgextend test-volume /dev/hda2.
You can also create or add several physical disks at once with:
pvcreate /dev/hda2 /dev/hda3 /dev/hda5
vgextend test-volume /dev/hda2 /dev/hda3 /dev/hda5
Once you're ready with adding PVs and have sufficient space to grow your logical volume, use lvextend to
extend the logical volume(s): lvextend -L 8G /dev/test-volume/data. This command extends the /dev/test-volume/data
LV to the size of 8GB.
There are several useful parameters for lvextend:
- You can use -L +5G if you extend your LV in 5GB chunks (relative size).
- You can specify where you want this new extension to be placed (in terms of PVs); just append the PV you want
to use to the command.
- You can also specify the absolute/relative extension size in terms of PEs.
Take a look at lvextend(8) for more details.
After extending the LV, don't forget to also extend the filesystem (so you can actually use the extra space). This
can be done online (with the filesystem mounted), depending on the filesystem.
Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Last edited 12/31/2006
This article is about resizing ext3 partitions without losing data. It shows
how to shrink and enlarge existing ext3 partitions and how to merge two ext3 partitions.
This can be quite useful if you do not use LVM and you realize that your existing
partitioning does not meet your actual needs anymore.
There are many ways of achieving this goal but this is the way I take. I do not
issue any guarantee that this will work for you!
1 Preliminary Note(I run all the commands in this tutorial as the root user, so make sure you're
logged in as root. If you are on a Ubuntu system, you can become root like this:
sudo su
)
I have tested this on a Ubuntu Edgy Eft desktop system that has all files in
one large partition (around 10 GB, device /dev/sda1).
The partitioning looks like this:
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.5G 4.1G 4.9G 46% /
varrun 94M 132K 94M 1% /var/run
varlock 94M 0 94M 0% /var/lock
udev 10M 52K 10M 1% /dev
devshm 94M 0 94M 0% /dev/shm
lrm 94M 18M 77M 19% /lib/modules/2.6.17-10-generic/volatile
The partition that is to be resized must be unmounted when we do the resizing;
obviously this is not possible if this is the partition that holds all important
system files like in this example. Therefore we download a Live Linux-CD such as
Knoppix from which we boot later on (if you have physical access to the system).
If it is a remote system that you don't have physical access to, you need a rescue
system on that system (a lot of hosting companies offer dedicated servers with rescue
systems nowadays) that you can boot into (instead of Knoppix), and this rescue system
must have the following tools: fdisk,
umount, fsck,
tune2fs, e2fsck,
resize2fs.
If the partition that you want to resize doesn't hold any system files (such
as /home partitions, partitions for backups, etc.),
you don't need a Knoppix Live-CD or a rescue system, because all steps can be run
from the original system.
If you want to resize partitions on production systems, please back up your data
before, because it is possible you lose all your data if you don't calculate the
size of your new partition correctly (especially when shrinking a partition)! You
have been warned! Tutorials about backups can be found here:
http://www.howtoforge.com/taxonomy_menu/1/34
I'm going to resize /dev/sda1 in this tutorial. If
your partition is named differently, please replace /dev/sda1
with your own device (e.g. /dev/hda5,
/dev/sdb3, etc.).
2 Shrinking An ext3 PartitionThis chapter is about shrinking an ext3 partition. I want to shrink
/dev/sda1 in this example. First we gather some details on our original system:
df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 9859036 4234908 5123304 46% /
varrun 95480 132 95348 1% /var/run
varlock 95480 0 95480 0% /var/lock
udev 10240 52 10188 1% /dev
devshm 95480 0 95480 0% /dev/shm
lrm 95480 17580 77900 19% /lib/modules/2.6.17-10-generic/volatile
df -B 4k
Filesystem 4K-blocks Used Available Use% Mounted on
/dev/sda1 2464759 1058727 1280826 46% /
varrun 23870 33 23837 1% /var/run
varlock 23870 0 23870 0% /var/lock
udev 2560 13 2547 1% /dev
devshm 23870 0 23870 0% /dev/shm
lrm 23870 4395 19475 19% /lib/modules/2.6.17-10-generic/volatile
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.5G 4.1G 4.9G 46% /
varrun 94M 132K 94M 1% /var/run
varlock 94M 0 94M 0% /var/lock
udev 10M 52K 10M 1% /dev
devshm 94M 0 94M 0% /dev/shm
lrm 94M 18M 77M 19% /lib/modules/2.6.17-10-generic/volatile
fdisk -l
Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 1247 10016496 83 Linux
/dev/sda2 1248 1305 465885 5 Extended
/dev/sda5 1248 1305 465853+ 82 Linux swap / Solaris
fdisk -s /dev/sda1
10016496
Then we shut down the system and boot into our Knoppix Live-CD (or your rescue
system) (if the partition you want to resize doesn't hold any system files, you
can do everything from the original system; the steps are the same, just omit booting
into Knoppix/your rescue system).
shutdown -r now
After Knoppix has booted, open a terminal and become root by running
su
/dev/sda1 should be unmounted by default, but you
can run
umount /dev/sda1
to go sure.
Then run
fsck -n /dev/sda1
The output looks like this:
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
/dev/sda1: clean, 159037/1254176 files, 1095299/2504124 blocks
Next we remove the journal from /dev/sda1, thus turning
it into an ext2 partition:
tune2fs -O ^has_journal /dev/sda1
The output looks like this:
tune2fs 1.38 (30-Jun-2005)
Then run
e2fsck -f /dev/sda1
e2fsck 1.38 (30-Jun-2005)
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/sda1: 164178/1254176 files (0.6% non-contiguous), 1051617/2504124 blocks
Now we resize our file system with resize2fs.
resize2fs can resize ext2 file systems, but not ext3
file systems, that's why we had to turn /dev/sda1 to
ext2. Currently, 4.1GB are used on /dev/sda1 (see the
df -h output above), So it's safe to shrink it from
10GB to about 6GB (if you make it smaller than 4.1GB, you will lose data!). Therefore
we run
resize2fs /dev/sda1 6000M
The output is as follows:
resize2fs 1.38 (30-Jun-2005)
Resizing the filesystem on /dev/sda1 to 1536000 (4k) blocks.
The filesystem on /dev/sda1 is now 1536000 blocks long.
Please take note of the amount of blocks (1536000)
and their size (4k). We need that soon.
Now we delete our /dev/sda1 partition (don't be afraid,
no data will be lost) and create a new, smaller one (but still big enough to hold
our resized file system!). We can do this with fdisk:
fdisk /dev/sda
(Yes, it's /dev/sda, not /dev/sda1.)
The number of cylinders for this disk is set to 1305.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Type m to get a list of all commands:
Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
Now we delete partition no. 1 (/dev/sda1):
Command (m for help): d
Partition number (1-5): 1
Next we create a new /dev/sda1 partition. It was
a primary partition before, so we choose p again, and
again it is our partition no. 1:
Command (m for help): n
Command action
l logical (5 or over)
p primary partition (1-4)
p
Partition number (1-4): 1
Now comes the crucial part - we are asked about the size of the new partition.
The first cylinder is no problem, it is the one from the fdisk
-l output at the beginning of this chapter (1).
First cylinder (1-1305, default 1): 1
But we don't have a value for the last cylinder of our new partition. Fortunately,
we can specify the size in kilobytes (K), so we calculate
the size like this:
We multiply the amount of blocks from the resize2fs
output (1536000) by the size of a block (4k),
and to go sure the partition is big enough, we add 3 to 5% to it (3% was enough
for me, but if you want to go sure take 5%):
1536000 * 4k * 1.03 = 6328320k
So we prepend that value with a + sign and replace
the small k with a capital one (K)
and enter it:
Last cylinder or +size or +sizeM or +sizeK (1-1247, default 1247):
+6328320K
Our original /dev/sda1 had the bootable flag (see
the fdisk -l output from the beginning of this chapter),
so we must add it to our new /dev/sda1 again:
Command (m for help): a
Partition number (1-5): 1
Now let's write our new partition table and exit fdisk:
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 16:
Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
Now we reboot the system, and again we boot into our Knoppix system (rescue system;
original system if resized partition doesn't hold system files):
shutdown -r now
Become root again (on Knoppix run
su
)
and then run this:
fsck -n /dev/sda1
The output should look like this:
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
/dev/sda1: clean, 159036/765536 files, 1047239/1536000 blocks
Then we create the journal on our new /dev/sda1,
thus turning it into an ext3 partition again:
tune2fs -j /dev/sda1
tune2fs 1.38 (30-Jun-2005)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
Now we are done. Shut down the system and boot into the
original system:
shutdown -r now
If everything goes well, the original system will boot up, and no data has been
lost. Now we can gather some details about our new partitioning and compare them
with the information we collected at the beginning of this chapter:
df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 6047868 4224140 1639408 73% /
varrun 95480 132 95348 1% /var/run
varlock 95480 0 95480 0% /var/lock
udev 10240 52 10188 1% /dev
devshm 95480 0 95480 0% /dev/shm
lrm 95480 17580 77900 19% /lib/modules/2.6.17-10-generic/volatile
df -B 4k
Filesystem 4K-blocks Used Available Use% Mounted on
/dev/sda1 1511967 1056035 409852 73% /
varrun 23870 33 23837 1% /var/run
varlock 23870 0 23870 0% /var/lock
udev 2560 13 2547 1% /dev
devshm 23870 0 23870 0% /dev/shm
lrm 23870 4395 19475 19% /lib/modules/2.6.17-10-generic/volatile
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 5.8G 4.1G 1.6G 73% /
varrun 94M 132K 94M 1% /var/run
varlock 94M 0 94M 0% /var/lock
udev 10M 52K 10M 1% /dev
devshm 94M 0 94M 0% /dev/shm
lrm 94M 18M 77M 19% /lib/modules/2.6.17-10-generic/volatile
fdisk -l
Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 789 6337611 83 Linux
/dev/sda2 1248 1305 465885 5 Extended
/dev/sda5 1248 1305 465853+ 82 Linux swap / Solaris
fdisk -s /dev/sda1
6337611
