© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
@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.