cloud-init-dev team mailing list archive
Mailing list archive
Re: Resizing of a GPT partition
> > Scott,
> >>> Hi all,
> >>> I've fiddled around with cc_resizefs.py trying to resize a GPT root
> >>> partition (2nd partition) but I can't get it to work. Any ideas how
> >>> do that? Is it possible at all?
> >> Its not configurable at the moment. Thats not to say that it couldn't
> >> but the code as it is right now just attempt to resize the device that
> >> '/'
> >> is on.
> >> It just does:
> >> st_dev = os.stat("/").st_dev
> >> dev = os.makedev(os.major(st_dev), os.minor(st_dev))
> >> os.mknod(devpth, 0400 | stat.S_IFBLK, dev)
> >> cmd = ['blkid', '-c', '/dev/null', '-sTYPE', '-ovalue', devpth]
> >> So whatever dev major and minor / is on it should attempt to resize.
> > I understand what the code is doing. I launched a precise-*-disk1.img
> cloud image in Nova and noticed that cloud-init correctly resized the
> root partition to 10GB. What puzzles me is that I don't see a resizing of
> the root partition before the filesystem is resized. Isn't that a
> ah. sorry. that query does made more sense.
> cloud-initramfs-utils source package handles that in the initramfs, and
> it most likely does not support GPT.
Ah ok. Is there a particular reason why this is a separate package? And no, it doesn't support GPT.
> it's really pretty simple code using sfdisk. I'm told that newer kernels
> allow you to reread partition sizes without unmounting all fs on the disk
> (which is why the code is in initramfs).
I played around in Fedora 16 (kernel 3.3.0) but partprobe returns:
Error: Partition(s) 2 on /dev/vda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes.
I haven't found a way around it yet.
> I'd have to dig up more details on that, which would be a simplification
> if we can do it.
> > ...Juerg
> >> It just gets the device by os.stat("/") because that was the most
> >> way I could think to get the device name of /, independent of root=.