cloud-init-dev team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

copying list. 

On May 2, 2012, at 6:08 AM, "Haefliger, Juerg" <Juerg.Haefliger@xxxxxx> wrote:

> 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. 

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'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 reliable
>> way I could think to get the device name of /, independent of root=.
>