How to extend OS disk on Azure

When you create a Rocky Linux VM on Azure the OS disk defaults to 8GB and you can’t change it during the creation. I am able to expand the volume to 30GB after creating the VM from the portal, but I’m having a hard time expanding it within Rocky terminal. (obviously I’m a linux noob)

Here is what I see with lsblk command:
sda 8:0 0 30G 0 disk
├─sda1 8:1 0 100M 0 part /boot/efi
├─sda2 8:2 0 1000M 0 part /boot
├─sda3 8:3 0 7.8G 0 part /
├─sda4 8:4 0 4M 0 part
└─sda5 8:5 0 1M 0 part
sdb 8:16 0 8G 0 disk
└─sdb1 8:17 0 8G 0 part /mnt

Here is df -hT
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs tmpfs 1.8G 0 1.8G 0% /dev/shm
tmpfs tmpfs 731M 17M 715M 3% /run
/dev/sda3 xfs 7.9G 1.2G 6.7G 16% /
/dev/sda2 xfs 994M 251M 743M 26% /boot
/dev/sda1 vfat 100M 7.0M 93M 7% /boot/efi
/dev/sdb1 ext4 7.8G 28K 7.4G 1% /mnt
tmpfs tmpfs 366M 0 366M 0% /run/user/1000

Can someone direct me to the correct commands to expand /dev/sda3?

xfs_growfs /dev/sda3

Thanks for replying the documentation. When I ran xfs_growfs /dev/sda3 I get the following output:

meta-data=/dev/sda3              isize=512    agcount=4, agsize=512000 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=2048000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

When I run df -hT I don’t see a change. How do I commit these changes? (if it made any changes at all?)

Reboot VM or remount all mounted drive/partitions

Hate to be a noob, but can you direct me to the docs on how to update and sync?

Reboote VM !

After that
Logon as root

shell command:

next command:

post result

df -hT
post result

Heya - thanks for pointing this out… there is a bit of an issue with this partition layout that I need to address. I’ll get a new image pushed out this week.

Xino - The command updatedb comes back as not recognized. I am able to run sync.

Neil - thanks for the info. How will this affect expanding the disk?

The current disk layout has two partitions after the / partition, which makes it difficult/impossible to grow the disk. We’ve had this happen with our LVM images, but not with these until now. We ‘fix’ this by manually creating the partitions rather than let Anaconda create them via Kickstart, because the ordering of the partitions by Anaconda is not guaranteed. See: add %pre to base images · 46fabf40b7 - kickstarts - Rocky Enterprise Software Foundation Git Service

Hello cwhitmore
I’m sorry to break it to you, but you stepped on the hoe!
I appreciate your behavior, that you modestly and sincerely say that you do not have the knowledge and experience.
No one is born learned and everyone learns while living! This forum and the Linux community prove it.
You are not happy about that, but the fact that “neil” intervene is indicative that the scribbles on the forum are read by “Infrastructure Team Lead” and it was you who helped to fix a malfunction!
Take an example of me. If “neil” hadn’t intervened (thanks for that!) you don’t think I would have paid attention to the partition numbering and looked right there after you even showed it!?
For me, / is the last partition and the expand is correct and works. But that doesn’t mean I missed that detail. I missed her! My mistake. And I didn’t know that partition concatenation creates a problem when expand a filesystem. My situation is this:

fdisk -l
Disk /dev/vda: 20 GiB, 21474836480 bytes, 41943040 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

Device Start End Sectors Size Type
/dev/vda1 2048 206847 204800 100M EFI System
/dev/vda2 206848 2254847 2048000 1000M Linux filesystem
/dev/vda3 2254848 2263039 8192 4M PowerPC PReP boot
/dev/vda4 2263040 2265087 2048 1M BIOS boot
/dev/vda5 2265088 41943006 39677919 18.9G Linux filesystem

vda 252:0 0 20G 0 disk
├─vda1 252:1 0 100M 0 part /boot/efi
├─vda2 252:2 0 1000M 0 part /boot
├─vda3 252:3 0 4M 0 part
├─vda4 252:4 0 1M 0 part
└─vda5 252:5 0 18.9G 0 part /

df -hT
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs tmpfs 801M 97M 704M 13% /run
/dev/vda5 xfs 19G 2.4G 17G 13% /
/dev/vda2 xfs 994M 287M 708M 29% /boot
/dev/vda1 vfat 100M 7.0M 93M 7% /boot/efi
tmpfs tmpfs 401M 4.0K 401M 1% /run/user/0

So it’s all good!
Life goes on.
And you helped! Thanks for you and “neil”.
And I learned something I didn’t know despite my failure.

Missing command updatedb - install it.
dnf provides updatedb

mlocate-0.26-30.el9.x86_64 : An utility for finding files by name
Repo : @System
. . .

dnf install mlocate

After that:


Right at the top of the forum there are many useful things.

A very good starting point for anyone, including me! :wink:

Xino - Thank you for your patience. I’m finally able to make time to learn what I can about Linux and especially Rocky Linux. I like doing things on my own and hate asking for help so thank you for providing the steps and links to online docs.

Does this mean new Azure deployments should no longer have the 2 additional partitions after the / partition?

Hello Neil,

Has this issue been fixed? We are experiencing the same issue, we can not easily expand the root partition which is most likely due to the extra 2 partition created after root partition #3

Device        Start      End  Sectors  Size Type
/dev/sda1      2048   206847   204800  100M EFI System
/dev/sda2    206848  2254847  2048000 1000M Linux filesystem
/dev/sda3   2254848 18638847 16384000  7.8G Linux filesystem
/dev/sda4  18638848 18647039     8192    4M PowerPC PReP boot
/dev/sda5  18647040 18649087     2048    1M BIOS boot


The version that is published to our Azure region (EastUS2) is not fixed. We have to redeploy quite a number of VMs now because we just recently discovered the issue when we went to expand a partition.

I think we now have to download what is in their community gallery and upload those images to our region…I believe those images do not have the issue so you might check there. I hope they do decide to publish working images to our Azure region in the future.

1 Like

Small precision: We’re using the following Azure marketplace image:

It looks like rocky 8 does NOT have the same issue:

That is affirmative. We’ve changed the kickstarts to force a partition layout

I will make sure the marketplace is updated. Thank you for your patience. The marketplace processes are kinda… annoying, and it would be great for us to have more people with the ability to help move things along. I am actively working on how we can facilitate that.

1 Like

Unfortunately we do not maintain these images. What problems are you having? I can split your issue into a new topic.

I did have the partition issues with the official image from the market place.