apaitu::server::configuration

Installation • Kernel & Hardware • Networks • Portage • Software • System • X Server • Gaming • Non-x86 • Emulators • Misc

Please improve it in any way that you see fit, and remove this notice {{Cleanup}} from the article. For tips on cleaning and formatting see Cleanup process

Contents [hide] 1 Introduction 2 Available software 2.1 GNU Parted 2.2 *fdisk programs 2.3 GParted 2.4 resize_reiserfs 3 Available LiveCDs 3.1 GParted LiveCD 3.2 Parted Magic 4 Backup your data 5 Physically extending (resizing) a partition 5.1 Goal 5.2 Preparing the free space 5.3 Doing the dirty work 5.4 Conclusion 6 Logically extending a partition 6.1 Goal

[edit] Introduction

This page concentrates on the different possibilities to move, resize - shrink and enlarge - and otherwise manipulate your harddisk drive partitions. The article badly needs to be cleaned up, reviewed (preferably by experts) and completed. Any help welcome.

[edit] Available software

[edit] GNU Parted

If you are dealing with a ReiserFS partition, you probably do not want to use GNU Parted. From the Official Manual: “GNU Parted was designed to minimize the chance of data loss. [..] Also note that reiserfs support relies on libreiserfs, which does not fulfil the aforementioned requirement. The same holds for any external tools like ntfsresize.” Also note that libreiserfs is neither listed in Parted’s dependencies, nor present in Portage.

Otherwise, Parted should be OK (in any case, use it at your own risk). This is what the Gentoo Official Documentation - The Gentoo Linux alternative installation method HOWTO - says about it: “Parted is an utility supplied by the GNU foundation, an old and respectable huge project whose software you are using in this very moment. There is one tool, however, that is extremely useful for us at the moment. It’s called parted, partition editor and we can get it from http://www.gnu.org/software/parted/“. In this document, it was subsequently used to resize an Ext3 partition.

[edit] *fdisk programs

cfdisk, fdisk, sfdisk come all with sys-apps/util-linux. Usage example: Preparing the Disks (Gentoo Linux x86 Handbook).

From the fdisk man page: “There are several *fdisk programs around. Each has its problems and strengths. Try them in the order cfdisk, fdisk, sfdisk.

Indeed, cfdisk is a beautiful program that has strict requirements on the partition tables it accepts, and produces high quality partition tables. Use it if you can. fdisk is a buggy program that does fuzzy things - usually it happens to produce reasonable results. Its single advantage is that it has some support for BSD disk labels and other non-DOS partition tables. Avoid it if you can. sfdisk is for hackers only - the user interface is terrible, but it is more correct than fdisk and more powerful than both fdisk and cfdisk. Moreover, it can be used noninteractively.

These days there also is parted. The cfdisk interface is nicer, but parted does much more: it not only resizes partitions, but also the filesystems that live in them.”

[edit] GParted

Wikipedia has an article on:

GParted

The Gnome Partition Editor does rely on Parted, but not entirely (See: Features). For the ReiserFS manipulation, it depends on the Official ReiserFS utils reiserfsprogs. Hence, I imagine, it should be more reliable for this specific task (again, use it at your own risk). This program is a GUI. I have often read post from people blasting partitioning GUIs. Personally, I have yet to come up with a corruption.

[edit] resize_reiserfs

This is part of the official ReiserFS utils reiserfsprogs. From the man page: “The resize_reiserfs tool resizes an unmounted reiserfs file system.” This is a low level tool (hence, CLI), so that in order to use it, you need to know what you are doing. For an example, check this article: HOWTO Clone a Gentoo Server or Workstation

[edit] Available LiveCDs

[edit] GParted LiveCD

Consider using the GParted LiveCD, especially in case you plan to do anything with your / partition. At the moment, GParted is in danger of dropping out of maintenance (See: News).

[edit] Parted Magic

For a thouroughly up to date LiveCD, check Parted Magic, a continuation of the GParted LiveCD (check the respective pages for more details). The latter LiveCD provides extensive and interesting documentation. In my extremely subjective view, this seems a serious project and actively maintained (as of September 2007).

[edit] Backup your data

First of all, backup your data. You’re gonna type in the most frightening commands ever seen over your favorite media partition. So, copy or back them up somewhere else with cp, tar or your other favourite backup script. See the backup HOWTO.

# cp -ar / /to-somewhere-else/

or

# tar -cpjvf /somewhere-else/my-fs-backup.tar.bz2 /

[edit] Physically extending (resizing) a partition

[edit] Goal

To enlarge a partition on it’s end like this:

[   partition   | free space ]
[         partition          ]

Make sure the free space is indeed free.

[edit] Preparing the free space

For ext2/3 type partitions you can use ext2resize or resize2fs, which is a part of the standard e2fsprogs package, that is included in the system package class. You do not need to create a partition on the free space. Just make sure you have the necessary free space after the partition. If you use resize2fs, you do not need to emerge ext2resize.

Otherwise, create the same filesystem as the one used by the partition being extended. Try to use the same options as on the extended one. Avoid using modes like “quick formatting”. Then, using fdisk or cfdisk, remove the newly created free partition.

[edit] Doing the dirty work

Umount the partition (it’s best to do this in runlevel 1).

# umount /dev/<partition to resize>

Check if the filesystem is clean:

# fsck -n /dev/<partition to resize>

If it reports any errors, back up the data (if you have not done so), and repair the filesystem before attempting to resize it.

Ext3 journal should be stripped before resizing:

# tune2fs -O ^has_journal /dev/<partition to resize>

Here comes the scary part. Use fdisk to remove your partition. Don’t worry, the data is still there. Then recreate the partition with the new (larger) size. Make sure you create it with the same starting disk cylinder as the old partition and with an ending cylinder equal to the last cylinder of the free space. Check this data carefully, before making any changes! Otherwise, the resize operation will certainly not work, and you may lose filesystems in other partitions.

After ending fdisk it may complain that it cant reread the partition table and you need to reboot to make the kernel aware of the new size of the partition. For me i had to reboot to successfully extend the partition to the new size below.

You should now have a larger partition containing the old filesystem. However, the old filesystem still does not know about the extra space reserved for its use. We need to resize the (old) filesystem on the enlarged partition:

# resize2fs /dev/<resized partition> <new_size_in_blocks>

Use fsck (still umounted) to do fs checks and some glueing in case of a minor data leakage. If fsck goes mad, shouting about bad inodes, cracked journals and weird file sizes, you’re probably the winner :) - try a different method.

• • • If you use resize2fs as explained, no “glueing” is needed. In this case, fsck will report no errors, unless you started with a corrupted filesystem or have an otherwise messed-up box. If not, fsck will detect the inconsistency between the size reported by the filesystem and the partition table and will try to correct it assuming the worst happened (corrupted filesystem), possibily messing things up badly. If you used resize2fs, just do a read-only filesystem check afterwords, just to make sure everything is fine:

# fsck -n /dev/<resized partition>

Recreate the journal on the resized partition (if applicable):

# tune2fs -j /dev/<resized partition>

[edit] Conclusion

This approach worked perfectly fine with ext3. Try it and write your FS and comments here…

Worked for me. I used e2fsck -f rather than fsck -n, just to make sure the partition was in perfect order.

stinger_au: I tried it with reiserfs and it worked first shot ! no errors :)

How did you manage it? From the man page: “resize2fs - ext2/ext3 file system resizer”.

If you want to move a partition from 1 logical drive to another use dd if=/dev/xxx of=/dev/xxx. You should do so only on unmounted drives. –The Hunter 03:36, 17 November 2006 (UTC)

[edit] Logically extending a partition

[edit] Goal

To extend a partition logically without modifications to the partition table:

DAMAGED SUPERBLOCK

If a filesystem check fails and returns the error message “Damaged Superblock” you’re lost . . . . . . . or not ?

Well, not really, the damaged ¨superblock¨ can be restored from a backup. There are several backups stored on the harddisk. But let me first have a go at explaining what a “superblock”is.

A superblock is located at position 0 of every partition, contains vital information about the filesystem and is needed at a fielsystem check.

The information stored in the superblock are about what sort of fiesystem is used, the I-Node counts, block counts, free blocks and I-Nodes, the numer of times the filesystem was mounted, date of the last filesystem check and the first I-Node where / is located.

Thus, a damaged superblock means that the filesystem check will fail.

Our luck is that there are backups of the superblock located on several positions and we can restore them with a simple command.

The usual ( and only ) positions are: 8193, 32768, 98304, 163840, 229376 and 294912. ( 8193 in many cases only on older systems, 32768 is the most current position for the first backup )

You can check this out and have a lot more info about a particular partition you have on your HD by:

CODE

$ dumpe2fs /dev/hda5

( go on, try it right now ! )

You will see that the primary superblock is located at position 0, and the first backup on position 32768.

O.K. let´s get serious now, suppose you get a ¨Damaged Superblock¨ error message at filesystem check ( after a power failure ) and you get a root-prompt in a recovery console, then you give the command:

CODE

# e2fsck -b 32768 /dev/hda5

( don´t try this at home . . uh, I mean: don´t try this on a mounted filesystem )

It will then check the filesystem with the information stored in that backup superblock and if the check was successful it will restore the backup to position 0.
Now imagine the backup at position 32768 was damaged too . . . then you just try again with the backup stored at position 98304, and 163840, and 229376 etc. etc. until you find an undamaged backup  ( there are five backups so if at least one of those five is okay it´s bingo ! )

So next time don´t panic . . just get the paper where you printed out this Tip and give the magic command

CODE

# e2fsck -b 32768 /dev/hda5

Bruno

mdadm -C /dev/md0 -l1 -n2 /dev/sda1 missing
mkdir /mnt/sysimage
mount /dev/md0 /mnt/sysimage

chroot /mnt/sysimage

cd /dev
MAKEDEV sda

run this under linux rescue

device (hd0) /dev/sda
root (hd0,0)
setup (hd0,0)