Using “content:” in gadget.yaml for a “role: system-data” partition makes it not be system-data anymore

building with -b ./build creates the following (the proper files from the gadget copied via "content:"):

$ find build/volumes/beaglebone/part3
build/volumes/beaglebone/part3
build/volumes/beaglebone/part3/meep.txt
build/volumes/beaglebone/part3/system-data
build/volumes/beaglebone/part3/system-data/etc
build/volumes/beaglebone/part3/system-data/etc/foo.txt

$ find build/unpack/gadget/writable/
build/unpack/gadget/writable/
build/unpack/gadget/writable/meep.txt
build/unpack/gadget/writable/system-data
build/unpack/gadget/writable/system-data/etc
build/unpack/gadget/writable/system-data/etc/foo.txt

Hey, what is the forecast time-wise on this being fixed & released?

@ogra: I just performed some experiments while trying to reproduce this bug, but my observations are a bit different than yours. Actually it's still more or less a bug, but not as severe. The story:

So what I noticed happening is: when there is a system-data partition, ubuntu-image actually never considers the content: section of the partition's definition when creating the partition *images*. At one point we do copy over the content-defined parts to the partX/ directory for every partition (which is what you saw in comment #1), but for system-data partitions we basically ignore the contents of that directory and only create a clean ext4 partition with the rootfs contents only.

You can check that is the case by going to the volumes directory (after using -b ./build or similar) and mounting the part3.img image file (or whichever partition number it has) and looking into its contents. You should only see the rootfs data there. In this case the part3/ directory contents have no correlation to what's in part3.img. Which is why looking into the part3/ dir and seeing files without the rootfs could cause confusion.

This means that basically right now the "role: system-data" role takes precedence over the "content:" definition, so the end result should fit your expectation as per the bug description. I'm not saying this is what we ultimately want, but I'm just saying that in theory an image built with a gadget.yaml like this should still have a 'valid' rootfs.

This makes me wonder: are you sure you do not have the rootfs contents in your system-data partition in the final image? Maybe I am seeing something different han you on your system?

That being said, the current behavior is not correct for sure, but I still need to think if this should be done by ubuntu-image or by snap prepare-image. Might be that the original idea was for the responsibility to be on the u-i side, seeing that we do handle the 'content:' parsing anyway for all other partition roles, but let me think about it a bit more.

@sil2100 weird, I wonder why I always ended up with the opposite but will re-check it again ...

nontheless, we need the "content:" directive on a "role: system-data" partition working for a customer project soon where some udev rules (and other files) need to be pre-installed in the system-data partition.

While I could apply hacks to do this from i.e. a customized hacked initrd I would really prefer if we could give something clean to the customer for their production images instead.

On Thu, Mar 15, 2018 at 05:15:37PM -0000, Oliver Grawert wrote:
> nontheless, we need the "content:" directive on a "role: system-data"
> partition working for a customer project soon where some udev rules (and
> other files) need to be pre-installed in the system-data partition.

I agree that this is a useful feature to have, and this has come up before.
However, it doesn't follow from the spec (which is admittedly ambiguous),
and it's new feature work. If this is a requirement for a customer project
"soon", you might need to look at contributing that feature.

In any case, if there is a deadline for this please communicate this to us
so we can try to schedule it appropriately.

> While I could apply hacks to do this from i.e. a customized hacked
> initrd I would really prefer if we could give something clean to the
> customer for their production images instead.

For a possibly-reusable example of this from the joule images, see:

  git+ssh://git.launchpad.net/~vorlon/tuchuck/+git/uc16-build-script

> For a possibly-reusable example of this from the joule images, see:
>
> git+ssh://git.launchpad.net/~vorlon/tuchuck/+git/uc16-build-script

This script is exactly what we want to get rid of for the upcoming
customers and what triggered the work making me hit this bug/missing-feature
altogether.

For production images a simple "ubuntu-image /path/to/model" should
DTRT for the customer, there should not be any wrapper scripts needed
and there should not be any files injected that do not come from a snap
(like you would not ship randomly injected files in a desktop iso that
are not part of a .deb or postinst script shipped in a .deb).

Status changed to 'Confirmed' because the bug affects multiple users.