### Check existing issues - [x] I've verified that this request isn't described by any existing issues. ### Request ### What I’d like to see Allow `imagecraft.yaml` to reuse (or import) the `volumes` definition from the gadget snap’s `meta/gadget.yaml`, instead of requiring users to duplicate the same partition/volume layout in `imagecraft.yaml`. ### Proposed UX / configuration A simple mechanism such as one of the following: - A boolean flag: - `volumes: from-gadget: true` - An explicit source: - `volumes: from-gadget: <path-to-gadget.yaml>` (optional override) - Or a special volume entry: - `volumes: gadget` In all cases, the default behavior stays unchanged: if `imagecraft.yaml` defines volumes explicitly, that remains the source of truth. ### Expected behavior - If enabled, Imagecraft should: 1. Locate the gadget snap used for the image build (from the model assertion and/or user-provided gadget override). 2. Read `meta/gadget.yaml` from the gadget snap. 3. Use the `volumes` section to drive disk layout creation (partition table type, partitions, filesystem types, labels, sizes/offsets, boot assets where applicable). - `imagecraft.yaml` should still be able to override specific values (optional, if feasible), but at minimum the gadget should be usable as the canonical definition. ### Notes - The `volumes` data in the gadget is already the authoritative source for the Ubuntu Core disk layout; duplicating it in `imagecraft.yaml` is error-prone. - This is particularly useful for multi-arch and custom gadgets where the volume definition is the most stable, accurate layout description. ### The problem it solves ### Current pain Today, building Ubuntu Core images with Imagecraft requires duplicating volume/partition layout information in `imagecraft.yaml`, even though the exact same information already exists in the gadget snap’s `meta/gadget.yaml` (`volumes` section). This duplication: - introduces drift (changes in gadget.yaml are easy to forget to mirror in imagecraft.yaml), - creates avoidable build errors (wrong partition flags, filesystem type, ESP formatting, missing boot assets), - makes maintenance harder for custom gadgets and multi-architecture builds.