6

yesterday I've resized a VM Virtual disk from about 15 GB to about 26 GB.

If I run fdisk I can check that disk is resized:

Disk /dev/sda: 26.2 GB, 26214400000 bytes
255 testine, 63 settori/tracce, 3187 cilindri, totale 51200000 settori
Unità = settori di 1 * 512 = 512 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificativo disco: 0x0005c952

It is not 15 GB anymore, but it is 26,6 GB.

So I ran

fdisk /dev/sda

to partition it.

Comando (m per richiamare la guida): n
Partition type:
p   primary (1 primary, 1 extended, 2 free)
l   logical (numbered from 5)
    Select (default p): p
    Numero della partizione (1-4, predefinito 3): 3
    Primo settore (499712-51199999, predefinito 499712): 
    Utilizzo del valore predefinito 499712
    Last settore, +settori or +size{K,M,G} (499712-501757, predefinito 501757): 
    w

I can already see that sectors interval is too short.

I leave the partition with ID 83 (Linux partition) and then I ran:

partprobe -s
/dev/sda: msdos partitions 1 3 2 <5>
/dev/mapper/ubuntu--vg-swap_1: loop partitions 1
/dev/mapper/ubuntu--vg-root: loop partitions 1

but to be sure I ran

partprobe

too.

Ok, my partition is /dev/sda3.

Then I ran:

mkfs.ext4 /dev/sda3

Output:

mke2fs 1.42.9 (4-Feb-2014)

Filesystem troppo piccolo per un journal
Etichetta del filesystem=
OS type: Linux
Dimensione blocco=1024 (log=0)
Dimensione frammento=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
128 inodes, 1020 blocks
51 blocks (5.00%) reserved for the super user
Primo blocco dati=1
Maximum filesystem blocks=1048576
1 block group
8192 blocchi per gruppo, 8192 frammenti per gruppo
128 inode per gruppo

Allocating group tables: fatto                           
Scrittura delle tavole degli inode: fatto                           
Scrittura delle informazioni dei superblocchi e dell'accounting del      filesystem: fatto

Then I mount it:

mount -t ext4 /dev/sda3 /priiiii

and I saw my partition is pretty small!!

df -h

File system                  Dim. Usati Dispon. Uso% Montato su
/dev/mapper/ubuntu--vg-root   15G  3,5G     11G  26% /
none                         4,0K     0    4,0K   0% /sys/fs/cgroup
udev                         492M  4,0K    492M   1% /dev
tmpfs                        101M  904K    100M   1% /run
none                         5,0M     0    5,0M   0% /run/lock
none                         501M   80K    501M   1% /run/shm
none                         100M   32K    100M   1% /run/user
/dev/sda1                    236M   36M    189M  16% /boot
**/dev/sda3                    999K   17K    911K   2% /priiiii**

Why the partition can't use all unallocated space of the resized disk?

fdisk uotput:

Dispositivo Boot      Start         End      Blocks    Id      System
/dev/sda1   *        2048      499711      248832   83     Linux
/dev/sda2          501758    33552383    16525313    5  Esteso
/dev/sda3          499712      501757        1023   83      Linux
/dev/sda5          501760    33552383    16525312   8e  Linux LVM

Thanks

  • Somehow /sda2 appears to be missing... – Takkat Jul 13 '15 at 11:12
  • @Takkat I updated this post with fdisk output for you – Alessio Jul 13 '15 at 12:09
  • Did you reboot after creation of partition? – Daniel Aug 2 '15 at 0:32
0

If you're doing all this in a vm, then you're needlessly making work for yourself. Let me answer this in 3 parts.
Firstly following the approach you've taken, something very strange is going on with your partition table. In my experience when you 'grow' a physical disk (normally by block copying from one small real disk to a larger one), the partition table needs recreating, as even with the same disk parameters, you'll have alignment issues. That said, I don't see why fdisk can't recreate a new partition table, if the disk has actually grown (as would happen in a real disk).
Secondly, LVM was created to abstract between the physical drives and partitions, and the volumes contained on them. Hence when using a virtual machine, without the problem of physical space (normally when upgrading a real disk, you do get rid of the old one), you can just create a new 11Gb virtual disk, and join it to your volume, without having to go through the grief of messing with your old vmfs file.

If you're intent on the approach you're taking, something has clearly gone wrong. As @daniel suggested, try rebooting, but personally, I'd consider creating a new image, with a new set of partitions and volumes, and copying everything across. What time you spend in copying, you'll save from trying to figure out how you managed to get your partition table out of order.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.