Documentation on the images structure/how to debug invalid builds?

Sergio Schvezov sergio.schvezov at
Tue Jun 9 21:19:11 UTC 2015

On Tue, Jun 09, 2015 at 01:38:56PM -0700, Steve Langasek wrote:
> Hi Seb,
> On Tue, Jun 09, 2015 at 08:31:10PM +0200, Sebastien Bacher wrote:
> > The desktop team continues looking at getting a desktop-next image based
> > on snappy going, we managed to get the a first successful build on i386
> > today (amd64 fails in what looks like the copy of signed boot bits, that
> > needs extra debugging)
> >
> > The build is giving us a device and a rootfs tarball, we are having some
> > difficulties combining those into a working image though, some help
> > would be welcome...
> > I've some question:
> > - is there any documentation describing what the device and rootfs
> > tarballs should contain? that would be useful to valid if the bits
> > available at the url mentioned before are valid
> > - is there some documentation describing what a "built" image is looking
> > like? (like partitions schemes/types, what they should contain to be a
> > valid boot medium, etc)
> > - what's the right way to build an image from those tarball? I've tried
> > to build goget-ubuntu-touch with the changes from
> >
> > then used
> > "u-d-f core rolling --channel edge
> > --device-part=livecd.ubuntu-desktop-next.device.tar.gz
> > --image-part=livecd.ubuntu-desktop-next.rootfs.tar.gz -o wily.img""
> This change only adds support for feeding an image part from a local file;
> it still expects the image part in question to be in the format provided by
> the system-image server.  This is not the same format as the output of a
> Launchpad livefs build - those images must be post-processed to match the
> format used by system-image.  (In theory launchpad could generate them in
> the same format; no one has bothered to implement this because
> post-processing would still be required in order to change the compression
> format and generate deltas.)
> I saw mention on IRC today of setting up auto-importing these images onto a
> system-image channel.  Is there a reason this isn't the answer you're
> looking for in this case?  I can see that ideally it should be easier to
> substitute a locally-generated rootfs for testing, but for the case of the
> desktop image, it seems to me that we should be getting this set up
> officially ASAP.

They want both, the possibility to locally test was desired even though
today that livecd-rootfs build is remote anyways. We would all love for
an all local solution similar to ogra's rootstock-ng thing. I personally
would like to see something in a lp:livecd-rootfs README file that
anyone can blindly setup ;)

Not sure if anything has changed but putting this under
ubuntu-personal/rolling/edge should be a good start.

More information about the snappy-devel mailing list