5

I have a VM with a virtual disk (visible as /dev/sdb) with a size of 10G

The admin increased the size of the virtualdisk to 60G.

I rebooted the machine and see now, that the disk is bigger.

root@DMZMHLX3:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
...
sdb      8:16   0   60G  0 disk 
└─sdb1   8:17   0   10G  0 part /app
...

Now I'd like to add another partition:

gdisk tells me that the disk as a size of 60G, but that the last usable sector is a sector corresponding to the old 10G disk image size:

root@DMZMHLX3:~# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 125829120 sectors, 60.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): FCE659D1-3690-4C3C-93EC-79B51EE8556D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 20971486
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        20969471   10.0 GiB    8300

last usable sector should be something like 125829120 and not 20971486.

So though the disk image size has increased and the VM sees the change I don't know how to use the newly available space.

fdisk shows me:

root@DMZMHLX3:~# fdisk -l /dev/sdb
GPT PMBR size mismatch (20971519 != 125829119) will be corrected by w(rite).
Disk /dev/sdb: 60 GiB, 64424509440 bytes, 125829120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FCE659D1-3690-4C3C-93EC-79B51EE8556D

Device     Start      End  Sectors Size Type
/dev/sdb1   2048 20969471 20967424  10G Linux filesystem

It recognizes a mismatch:

GPT PMBR size mismatch (20971519 != 125829119) will be corrected by w(rite). But when trying to write fdisk fails:

Command (m for help): w
GPT PMBR size mismatch (20971519 != 125829119) will be corrected by w(rite).
fdisk: failed to write disklabel: Invalid argument
root@xxx:~#

How can I fix this issue?

The ultimate goal is to increase the size of the existing partition, but even if I can just add new partitions I would already be happy

gelonida
  • 455

3 Answers3

5

According to the Resizing partition fdisk fails with invalid argument post, it appears that you use parted (e.g. sudo parted -l) and let it "fix" the issue with the partition table not covering the entire disk or whatever.

Once that fix applies with that tool to get by that issue, you then simply move forward with the sudo fdisk /dev/sdb1 command, and apparently run sudo resize2fs /dev/sdb1 afterwards to have the changes applied.

Important: Don't forget to have full system backups before making any disk partition changes.

I managed to solve this rather simply. I installed parted and when I ran that it informed me that the partition table didn't cover the full disk (duh), so it asked me Fix/Cancel to which I responded with Fix.

Apparently, that did the trick as I was able to modify the partition to the full size using sudo fdisk /dev/vda, but afterwards I did need to run sudo resize2fs /dev/vda3 to have the changes applied.

Source

Additionally there is advice from others on the Resizing partition fdisk fails with invalid argument post in the form of answers and comments which you might find useful and beneficial as well.

Supporting Resources

Vomit IT - Chunky Mess Style
  • 42,624
2

The post Extending a partition on a VMware disk in Linux has this procedure:

  • Repair the GPT table with parted: sudo parted -l

  • Stop any services which access these disks and unmount the disk, for example:

    sudo systemctl stop jenkins.service
sudo systemctl stop apache2.service
sudo umount /dev/sdb1

    This step can be avoided by booting from the GParted disk, as described below.

  • Extend the partition from fdisk: sudo fdisk /dev/sdb

As enlarging the disk from within the VM requires stopping any service that might be using the disk, this can be avoided by booting the VM with GParted.

The article Use GParted to increase disk size of a Linux native partition describes the entire procedure in detail.

harrymc
  • 498,455
1

The reason is that GPT has a backup copy of the partition table placed at the end of the disk, so even when the disk has a "new end", the backup doesn't automatically go to it and limits the usable blocks to the old "area".

You can simply "zap" (wipe) the GPT (x and then z in gdisk), then create a new one with the same partition entry/ies (by entering the same start and optionally, the same end).

If you are doing UEFI booting, it should be fine to zap the protective MBR as well, as there should be no boot code that needs to be kept.

EDIT: Actually it seems that you can simply x and then e in gdisk.

JW0914
  • 9,096
Tom Yan
  • 10,996