Reboote VM !
After that
Logon as root
shell command:
updatedb
next command:
sync
lsblk
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
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
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.
command:
dnf provides updatedb
return:
mlocate-0.26-30.el9.x86_64 : An utility for finding files by name
Repo : @System
. . .
dnf install mlocate
After that:
updatedb
Right at the top of the forum there are many useful things.
A very good starting point for anyone, including me! 
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
Thanks,
Math
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:
center-for-internet-security-inc:cis-rocky-linux-9-l1:cis-rocky-linux-9-l1-gen2:1.0.2
It looks like rocky 8 does NOT have the same issue:
center-for-internet-security-inc:cis-rocky-linux-8-l1:cis-rocky-linux-8-l1:1.0.2
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.
Thank you for the confirmation. We’re looking into this.
Hello Neil,
My post first post describes the issue.
In short, it looks like all Rocky Linux 9 images on the Azure Marketplace are having the issue where increasing the OS disk does not increase the root partition (probably because of the 2 partitions created after the root partition). This issue is not present with Rocky Linux 8 images on the marketplace
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
Thanks,
Math
Alright. I’ll check this out with the new images i am publishing. Thank you! this should be addressed in the Rocky Linux official images, but if you’re using the CIS ones, we do not maintain those. I can try and look to see where they’re coming from and try and correct them if they’re open source.
1 Like
The brute force approach seems to work:
parted /dev/sda rm 5
parted /dev/sda rm 4
parted /dev/sda resizepart 3 100%
Not very elegant, but the systems still boot it seems.
1 Like
Hello,
same issue here. Rocky 9.1 deployed from faulty image. I was prevented from expanding disk with fdisk ,cfdisk etc.
Is there a way to expand sda3 safety and without removing sda4 and sda5?
Are there any possible implications of removing sda4, sda5? I’d rather not break the OS/VM and deal with some additional problems in the future.
