ubuntu-image 0.7ubuntu1

[Oliver Grawert]

hi,
On Di, 2016-10-11 at 18:20 -0300, Gustavo Niemeyer wrote:
> 
> 
> On Tue, Oct 11, 2016 at 5:56 PM, Oliver Grawert <ogra at ubuntu.com>
> wrote:
> > hi,
> > On Di, 2016-10-11 at 15:12 -0300, Gustavo Niemeyer wrote:
> > > 
> > > We need a different gadget for those cases anyway, right?  We
> > don't
> > > want cloud-init probing arbitrary addresses on someone's data
> > center.
> > >
> > > I agree with Barry here. I'd prefer to encourage people to make
> > > gadget.yaml be reproducible.
> > >
> > > Also, it seems nicer to encode sizes precisely than to have a
> > > "factor" which pads the image based on external factors, for the
> > same
> > > reason.
> > > 
> > 
> > well, it means that you can not use the pc image in kvm, vmware,
> > virtualbox, vagrant anymore ...
> 
> You can use the same image for whatever you need. One image, one
> gadget.
> 
if you define no image size today and use ubuntu-image today you
(should) get a 300MB image that you dd to a device ... on startup,
before the first mount occurs the image gets resized to the full disk
size and it gets made sure that your GPT backup table sits in the right
place at the end of the disk.

if you start to hard code sizes you lose all this flexibility, you will
already not be able to use the pc image on a 2GB USB key today simply
because we hard code the size for it to ~3GB just for the kvm use case.

> Whatever is aimed at VM should be tested in the VM. If it's aimed at
> real hardware, it should be tested in real hardware. If it's the same
> image, then the same image should be tested on both.
> 
> But that's all obvious, so I probably don't understand the point
> being made.

i dont think anyone tests our pc image on a pc today so your point
about whatever is aimed at hardware should be tested on hardware does
not actually match reality.

> Again, I don't understand. If the images are the same, we don't 
> duplicate images. If they have different, then we need to duplicate 
> them regardless. None of that is changing.

so you think we should have a pc.img, a pc-kvm.img, pc-vmware.img and a
pc-cloud.img using the same kernel the same core snap and apart from
one line the same gadget ? 
they will just be padded with zeros up to the value the gadget defines.
this is the only difference and something that should imho be handled
by the build tool not by the gadget to avoid the "can not be used on 2G
USB sticks" situation from the start if possible.

note that i am only talking about our generic images here (designed to
be used with random SD cards on developer boards or with any common
PC), if you have a target device that needs exactly 7 partitions with
each having a defined size on an internal mtd device i want absolute
precision in the gadget.yaml and each partition defined to the byte
indeed. for generic images i think the overall image size definition
(padding) should be an option of the build tool though.

ciao
	oli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.snapcraft.io/archives/devices/attachments/20161011/192daffd/attachment.pgp>