We've discussed multiple times in meetings and threads that we want to represent the content of the images accurately inside gadget.yaml. The fact we're not yet doing that is a bug that we need to fix, and if there's disagreement we should talk about it. The whole point of redesigning these tools is to evolve the status quo towards something we are aiming at with underlying goals. If we are going to rush it in, we can just pick up the tooling we had (or the hack you mention) and put the images out. <div class="gmail_extra"> <div class="gmail_quote">On Oct 12, 2016 3:41 PM, "Oliver Grawert" <<a href="mailto:ogra@ubuntu.com">ogra@ubuntu.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi, On Mi, 2016-10-12 at 15:17 -0300, Gustavo Niemeyer wrote: > Instead of asking whether I've read the thread, I'd appreciate if you > could try to understand the point I'm making so we can make some > progress. > The gadget.yaml should represent accurately what goes into the image. > Not one image in fact, but multiple, one per volume, and all of their > partitions. i understood during all sprints where we discussed it that this is not GA material ... today snap prepare-image and ubuntu-image simply create a writable partition (it is the default thing carrying our payload whithout which we can not boot), today we do not define the writable partition anywhere. to have it supported in the gadget we will likely need changes in all places, starting with the gadgets themselves, snapd for "snap prepare- image" and ubuntu-image (and in case you want a fancy different name in various other places inside the image). for the change you are suggesting we will *not* have a solution this week. to have image building *at any point* in cdimage adam will need a functional ubuntu-image he does not need to patch like mvo and I have to do today to actually create functional images. > We need to represent the "writable" partition in the gadget as well > if it is supposed to be in those images, otherwise how do we provide > parameters for it, and where does it go? Which position? And so on. > A lonely "size" parameter is not meaningful in that context without > further details. Then, how do we resize the boot partition, or any > other one? > this is not about partitions at all ... a VM sees the img file as a disk device, the padding tells the initrd that there is space on the device it can resize the writable partition to. we can implement all sorts of fancy and detailed gadget stuff if you think we have the time to do so, but we have been waiting for ages to even be able to have a gadget usable by ubuntu-image at all, now we are waiting for ubuntu-image to be finished and are still not able to provide builds on cdimage (they happen on my personal desktop PC today and get rsynced to my people.u.c account, likewise mvo builds the betas by hand and manually scp's them to cdimage) how long do you estimate it will take to change all our setups to have "writable" defined in the gadget, to pull out the generic code that creates "writable" today and have it properly replaced ? it wont help to discuss theoretical changes here if we can not manage to implement them before release while still not being able to create official images in the official ubuntu build system. the change that barry and I are discussing will not change anything in the images they will stay exactly identical to what we currently release but they will be buildable without having to locally hack your ubuntu-image so adam can start moving with the cdimage implementation. ciao oli</blockquote></div></div>