← Back to team overview

cloud-init-dev team 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
> > > to
> > > >>> do that? Is it possible at all?
> > > >>
> > > >> Its not configurable at the moment.  Thats not to say that it
> couldn't
> > > be,
> > > >> 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
> > > necessity?
> > > >
> > > 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.
> 
> I'm not sure why I put it in a separate package. Its somewhat unrleated
> but related.

Can we merge the source trees and generate multiple packages instead of having multiple source trees? I think the source kind of belongs together. I'll work on it if people agree that it's the right thing to do.

...Juerg


 
> > 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.
> 
> Well, if you can come up with something that grows the partition, then we
> can add it to cloud-initramfs-growroot , and it can then operate without
> the root partition mounted.


Follow ups

References