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.
You should be pretty safe to remove partitions 4 and 5, if they are indeed the BIOS boot or PREP boot partitions, like in your picture.
We only support “Generation 2” VMs in Azure, so these only use UEFI boot.
1 Like
Thank you Neil, that’s helpful knowledge!
No problems so far, but I’m just running a little simple cluster of 8 VMs.
Hi Neil,
Is there any chance that the Azure images are updated so that the root partition is the last partition? We constantly run into this issue, resizing isn’t easy this way (and still no LVM images on the Azure marketplace: Official Azure marketplace Rocky 9 image with LVM ).
It can seem like a minor thing but the root partition is really small now. Would be really great to be able to resize the root partition without any extra steps from our Ansible automation just for the Rocky images.
Thanks!
heya, i will check this out. they should be the last partition now, as of the 9.2 images.
Hi, I just deployed using the latest official and still had to partition issue. rm5/4 worked. So still not fixed. The issue also occur(ed) if pulling the marketplace image to use on a stack edge but that was deployment i did a few months ago.
Will the latest images of Rocky9 be provided only on compute gallery?
Currently, it seems that images in compute gallery can only be used in EAST US. Are there any plans to release it for other regions like Rocky8?
Heya - These images will be available in the marketplace as well as the community gallery, and we should be able to populate them in all regions. I’m working on this today, so I will respond with the links later.
Thank you for letting me know. This is the first thing I’m testing with our 9.3 and 8.9 images that I’m working on today.
[azureuser@r9-x86 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 10G 0 disk
├─sda1 8:1 0 99M 0 part /boot/efi
├─sda2 8:2 0 1000M 0 part /boot
├─sda3 8:3 0 4M 0 part
├─sda4 8:4 0 1M 0 part
└─sda5 8:5 0 8.9G 0 part /
[azureuser@r9-x86-lvm ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 10G 0 disk
├─sda1 8:1 0 99M 0 part /boot/efi
├─sda2 8:2 0 1000M 0 part /boot
├─sda3 8:3 0 4M 0 part
├─sda4 8:4 0 1M 0 part
└─sda5 8:5 0 8.9G 0 part
└─rocky-root 253:0 0 8.9G 0 lvm /
sdb 8:16 0 8G 0 disk
└─sdb1 8:17 0 8G 0 part /mnt
sr0 11:0 1 628K 0 rom
These images are live in the gallery and are going to the marketplace in due time (once approved by MSFT)
Neil, I can confirm deploying the images puts the drive at the end, but the problem is if you expand the disk in azure, it doesn’t expand it. It just adds a /dev/sdb device with the additional space. And then you have to use LVM to make a VG with both PVs. Is that the intent?
Ok, that’s… not intended, then. I was not aware that is how Azure is approaching that. I will have a look.
Use of term “expand” to mean “we give you additional volumes” is unexpected.
Does Azure show “you have 18G space” or does it show “you have 10G and 8G” after the expand?
What if you expand again – does that give you yet another volume?
Is there “shrink” too and how does that behave?
Personally, I prefer old school multiple partitions, where additional space is mounted where it is needed, but it is definitely “easier” to live with one big filesystem.
I haven’t tried another expansion. But it shows I have a 10GB and 8GB volume. Which is just a single disk attached to the VM of size 20GB. I don’t believe you can shrink a disk in Azure either. I’ve been able to use LVM to make one big volume but it’s just an annoyance since I would have thought Azure would have just expanded it to the full 20GB