embiggen-disk
embiggen-disk copied to clipboard
bradfitz
not able to resize a root volume on CentOS 7 (stop depending on sfdisk)
$ mount|grep ' / '
/dev/sda1 on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
$ ./embiggen-disk -dry-run /
error preparing to enlarge /: unsupported filesystem type "rootfs"
$ mount|grep rootfs
$ uname -mrs
Linux 3.10.0-862.9.1.el7.x86_64 x86_64
there is rootfs there indeed:
rootfs / rootfs rw 0 0
...
/dev/sda1 / xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
Okay, fix seems straightforward: ignore lines where rootfs is in that first field.
Want to send a PR or want me to?
I made a hack to ignore rootfs and tested it. next I get: error: unsupported partition table type "" on /dev/sda
# sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size=536868864, Id=83, bootable
/dev/sda2 : start= 0, size= 0, Id= 0
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0
This a disk, partitioned by Azure. I believe, it uses MBR:
# udevadm info -q property -n sda
DEVLINKS=/dev/disk/azure/root /dev/disk/by-id/scsi-3600224805ea20c1a2c0b9fc09f967f2f /dev/disk/by-id/wwn-0x600224805ea20c1a2c0b9fc09f967f2f /dev/disk/by-path/acpi-VMBUS:01-scsi-0:0:0:0
DEVNAME=/dev/sda
DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0A03:00/device:08/VMBUS:01/00000000-0000-8899-0000-000000000000/host2/target2:0:0/2:0:0:0/block/sda
DEVTYPE=disk
ID_BUS=scsi
ID_MODEL=Virtual_Disk
ID_MODEL_ENC=Virtual\x20Disk\x20\x20\x20\x20
ID_PART_TABLE_TYPE=dos
ID_PATH=acpi-VMBUS:01-scsi-0:0:0:0
ID_PATH_TAG=acpi-VMBUS_01-scsi-0_0_0_0
ID_REVISION=1.0
ID_SCSI=1
ID_SERIAL=3600224805ea20c1a2c0b9fc09f967f2f
ID_SERIAL_SHORT=600224805ea20c1a2c0b9fc09f967f2f
ID_TYPE=disk
ID_VENDOR=Msft
ID_VENDOR_ENC=Msft\x20\x20\x20\x20
ID_WWN=0x600224805ea20c1a
ID_WWN_VENDOR_EXTENSION=0x2c0b9fc09f967f2f
ID_WWN_WITH_EXTENSION=0x600224805ea20c1a2c0b9fc09f967f2f
MAJOR=8
MINOR=0
SUBSYSTEM=block
TAGS=:systemd:
USEC_INITIALIZED=32748
fabric_name=root
what's the proper way to work around it?
@chillum, interesting, it appears that your version of sfdisk doesn't spit out a "label: dos" or "label: gpt" line.
What version do you have?
I have:
# sfdisk -v
sfdisk from util-linux 2.29.2
I suppose I can detect the partition type by hand rather than asking sfdisk.
I just pushed a fix, but I didn't test it. But it shouldn't be worse than today.
Could you verify it works now, or reopen this with details of how it now fails?
error message now changed: error: unknown MBR partition type "" for /dev/sda4
Can you tell me the high-level steps for how to reproduce your environment on Azure and how to resize a disk on Azure?
you should be able to reproduce this on Azure like this:
- create a server from "CentOS-based 7.5" image from Rogue Wave
- any size would fit. basic a1 is okay, I had troubles with running basic a0 due to lack of RAM.
- I'm able to confirm this problem is the same whether you enable "managed disks" or not for your VM. I'm also able to confirm this happens on both SSD and HDD drives.
- launch
sudo ./embiggen-disk -dry-run /and it will yell:error: unknown MBR partition type "" for /dev/sda4
I actually omitted the steps for resizing the disk, as this problem is there just out of the box. To re-size the disk:
- stop the VM
- select "Disks" in VM settings
- select your OS disk, set the size, click "save"
- start the VM
if there's something else I can help with, let me know. thanks
Thanks!
(unrelated side note: Azure doesn't let you resize a disk live? That's what embiggen-disk was really designed for, even though embiggen-disk is useful the reboot way)
does not. to resize an Azure disk, you must have the VM powered off and deallocated. then you power it on, resize your sda and run growfs.
it may however support live-resizing of non-system disks, frankly, don't know it. IIRC, AWS also did not allow to resize the system disk without powering it off.
So what's happening is that embiggen-disk had assumed that the partition being resized must be the final one.
What this CentOS-on-Azure instance reports is:
# sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 1024000, Id=83, bootable
/dev/sda2 : start= 1026048, size= 61888512, Id=83
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0
It has 4 partitions but only 2 are non-empty.
I'll make it ignore any trailing 0-sized partitions of Id=0.
yeah, I see the same on my instances.
the second partition is empty as well on some instances (they don't use a managed disk or I don't know). like:
sudo sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 62912512, Id=83, bootable
/dev/sda2 : start= 0, size= 0, Id= 0
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0
And next I hit problems with the old version of sfdisk not supporting --no-tell-kernel.
# /home/bradfitz/embiggen-disk /mnt/resource
2018/10/11 18:23:06 sfdisk: exit status 1: /sbin/sfdisk: unrecognized option '--no-tell-kernel'
I was wary of using sfdisk and my fears were founded.
I'll switch to just doing this all in Go (https://godoc.org/github.com/deitch/diskfs and https://godoc.org/github.com/deitch/diskfs/partition/mbr etc look good) and then stop using sfdisk.
But I can't get to this immediately. If you want to work on this I'm happy to review.
okay, modified the title to reflect that this is probably an Azure-specific issue (or at least personally I don't know if it's Azure-specific).
will try to do a PR in some time, thanks.
There are two issues here: Azure creating trailing zero partitions, and sfdisk being old on CentOS.
I just pushed 75cd5ed771b57c4b48e8a83f8f178fcb43d15afa for the Azure thing, so now this bug is about sfdisk problems (that we should stop depending on sfdisk, really). I'll re-title.