Change Partition Table with GParted

Question

I have an Ubuntu 12.04 LTS server that has 6x600GB SAS drives in a RAID 5 configuration (Perc 6/i).

The partition scheme looks like this:

Partition    File System   Mount Point    Size
/dev/sda1    ext2          /boot          243.00 MiB
/dev/sda2    extended                     1.09 TiB
  /dev/sda5  lvm2                         1.09 TiB
unallocated  unallocated                  1.64 TiB

I want to extend the /dev/sda5 partition to include the unallocated space, and create one large partition. However, when I attempt to extend the partition, I get an error:

partition length of 5854484482 sectors exceeds the msdos-partition-table-imposed maximum of 4294967295

I believe that I need to create a new partition table. However, I have also read that doing so can cause problems.

My basic question is this: if I boot from the GParted Live CD, apply a new partition table, extend the /dev/sda2 partition, and increase the size of the LVM, is the system going to boot up afterwards, and will the LVM still be intact? I understand that there is always the possibility of data corruption, and I've backed everything up. The real question is whether this is the correct way to go about modifying the disk configuration.

Alternatively, is there a better way to incorporate the unallocated space into the LVM?

Solution 1

jordanm had the best suggestion. Although the msdos partition table cannot accomodate a single partition that is larger than 2TB, because I have a logical volume, I can create a new partition from the unallocated space (which is smaller than 2TB) and add it to the logical volume.

First I create a new, unformatted partition named /dev/sda3 in GParted from the unallocated space.

Now that a new partition exists, I need to create an LVM physical volume:

nalice@gerty:~$ sudo pvcreate /dev/sda3
  Physical volume "/dev/sda3" successfully created

Next I need to extend the Logical Volume to include the new physical volume:

nalice@gerty:~$ sudo lvextend -L2731.75G /dev/mapper/GERTY-root
  Extending logical volume root to 2.67 TiB
  Logical volume root successfully resized

Note that the -L paramter of lvextend indicates the total size of the Logical Volume, not the amount that the Logical Volume is extended.

Lastly, I extended the filesystem to include all of the available space in the Logical Volume:

nalice@gerty:~$ sudo resize2fs /dev/mapper/GERTY-root 
  resize2fs 1.42 (29-Nov-2011)
  Filesystem at /dev/mapper/GERTY-root is mounted on /; on-line resizing required
  old_desc_blocks = 67, new_desc_blocks = 171
  Performing an on-line resize of /dev/mapper/GERTY-root to 716111872 (4k) blocks.
  The filesystem on /dev/mapper/GERTY-root is now 716111872 blocks long.

And there you have it, a 2.9TB Logical Volume without having to change the partition table.

Source: http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/

Solution 2

partition length of 5854484482 sectors exceeds the msdos-partition-table-imposed maximum of 4294967295

This signals clearly that the (logical) disk is over the 2 TB limit.

To work around it - you have to use the GPT partition tabel. To change it do:

#parted /dev/sda mklabel gpt

If you change the partition table from msdos to gpt, you will lose all your data! Ensure that you have a backup to restore the data.

If you decide to reorganize your disk, consider to use the whole raid array as lvm physical volume. It is no problem with a current ubuntu to put the /boot partition inside the lvm. This has also the benefit that you can easily resize this partition.

Comments

[jordanm]

You can just create a new partition and add it your volume group.

[Alex]

I like this idea. I'm somewhat new to the LVM concept. If I understand correctly, I would format the unallocated space and somehow add the new partition to the volume group?

[Stéphane Chazelas]

No, he will not loose all his data if he creates the gpt partition exactly the same way the msdos partitions were which can be easily done with gdisk provided there's enough space before the first partition to store the GPT header. He'll also need to rerun grub-install.

[Mårten]

@StephaneChazelas I wouldn't recommend to try it without a data backup.

[Alex]

@H.-DirkSchmitt Actually, I believe that it signals that the physical partition that will be created (if I extend /dev/sda2 into the unallocated space) will be too large, not the logical volume.

[Mårten]

@Alex - I agree. I decided to use logical above to distinct the raid device from the physical disks. I don't mean a logical volume.

[Alex]

@H.-DirkSchmitt - Oh, that makes sense. Thanks for the clarification.