Score:0

Resizing OS Disk/Partition

br flag

I have an Ubuntu 20.04.2 LTS Azure VM server running. The VM was originally setup with an OS disk of 32GB and the disk has become full:

df -h

/dev/root        29G   29G  258M 100% /
devtmpfs        7.9G     0  7.9G   0% /dev
tmpfs           7.9G   16K  7.9G   1% /dev/shm
tmpfs           1.6G 1016K  1.6G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/loop2       71M   71M     0 100% /snap/lxd/21029
/dev/loop0       56M   56M     0 100% /snap/core18/2074
/dev/loop1       56M   56M     0 100% /snap/core18/2128
/dev/loop3       33M   33M     0 100% /snap/snapd/12398
/dev/loop4       33M   33M     0 100% /snap/snapd/12704
/dev/sda15      105M  7.9M   97M   8% /boot/efi
/dev/sdb1        32G  2.1G   28G   7% /mnt
tmpfs           1.6G     0  1.6G   0% /run/user/1000

I have increased the disk size in Azure but i cant get Ubuntu to see the new capacity. I cant run bootables like gparted from Azure so am confined to the CLI.

Running:

sudo fdisk -l

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 55.45 MiB, 58130432 bytes, 113536 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


Disk /dev/loop2: 70.32 MiB, 73728000 bytes, 144000 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


Disk /dev/loop3: 32.29 MiB, 33853440 bytes, 66120 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


Disk /dev/loop4: 32.3 MiB, 33865728 bytes, 66144 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


GPT PMBR size mismatch (62916607 != 134217727) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
Disk /dev/sda: 64 GiB, 68719476736 bytes, 134217728 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B2A73065-2334-4FBF-8494-668056F3ABD9

Device      Start      End  Sectors  Size Type
/dev/sda1  227328 62916574 62689247 29.9G Linux filesystem
/dev/sda14   2048    10239     8192    4M BIOS boot
/dev/sda15  10240   227327   217088  106M EFI System

Partition table entries are not in disk order.


Disk /dev/sdb: 32 GiB, 34359738368 bytes, 67108864 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x42938be0

Device     Boot Start      End  Sectors Size Id Type
/dev/sdb1        2048 67106815 67104768  32G 83 Linux


Disk /dev/sdc: 64 GiB, 68719476736 bytes, 134217728 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

I have followed this guide - sudo fdisk /dev/sda - but it ends in disaster where the VM wont come back online after a reboot so I'm definitely breaking something.

(I am a Windows guy hence being clueless)

Can anyone provide an suggestions?

cn flag
That is not how cloud services work best: you should have TWO disks: 1 system disk, 1 user disk. If you want to change system settings, like the size, you create a NEW instance with a new system disk and attach the user disk to that system disk. 100% fallback option guaranteed. Any changes from within Ubuntu that could require a reboot should be avoided at any cost (that includes upgrades): a cloud instance that does not boot is essentially dead beyond fixing.
user3607172 avatar
br flag
Thanks - Where does that leave me in my current predicament?
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.