Gadget with extra partition

Are there any examples of ubuntu core gadget.yaml files that successfully build an image with one or more extra partitions for data? I’ve been trying for 3 days to get this to work.

Primary use case for this extra partition is to avoid a user filling the main writable system-data partition and affecting other running processes.

eg:

volumes:
  foo-test-pc:
    # bootloader configuration is shipped and managed by snapd
    bootloader: grub
    structure:
      - name: mbr
        type: mbr
        size: 440
        update:
          edition: 1
        content:
          - image: pc-boot.img
      - name: BIOS Boot
        type: DA,21686148-6449-6E6F-744E-656564454649
        size: 1M
        offset: 1M
        offset-write: mbr+92
        update:
          edition: 2
        content:
          - image: pc-core.img
      - name: ubuntu-seed
        role: system-seed
        filesystem: vfat
        # UEFI will boot the ESP partition by default first
        type: EF,C12A7328-F81F-11D2-BA4B-00A0C93EC93B
        size: 1200M
        update:
          edition: 2
        content:
          - source: grubx64.efi
            target: EFI/boot/grubx64.efi
          - source: shim.efi.signed
            target: EFI/boot/bootx64.efi
      - name: ubuntu-boot
        role: system-boot
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        # whats the appropriate size?
        size: 750M
        update:
          edition: 1
        content:
          - source: grubx64.efi
            target: EFI/boot/grubx64.efi
          - source: shim.efi.signed
            target: EFI/boot/bootx64.efi
      - name: ubuntu-save
        role: system-save
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 16M
      - name: extra-data
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 20G
      - name: ubuntu-data
        role: system-data
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 1G

Using the python version of ubuntu-image:

During the prepare_filesystems step, it builds a list of part_images https://github.com/canonical/ubuntu-image-legacy/blob/1.11+21.04ubuntu1/ubuntu_image/common_builder.py#L352

However during the populate_filesystems step, it uses the part_image at the same index in the list as the partition in the gadget https://github.com/canonical/ubuntu-image-legacy/blob/1.11+21.04ubuntu1/ubuntu_image/common_builder.py#L464

Unfortunately, there are cases where the entry into the part_images list is skipped https://github.com/canonical/ubuntu-image-legacy/blob/1.11+21.04ubuntu1/ubuntu_image/common_builder.py#L245

So the list of part_images is out of sync with the list of partitions in the gadget unless the skipped partitions are the last in the gadget and therefore likely last on disk.

With the go version of ubuntu-image I believe I get something similar, but is a bit harder to debug

[0] make_temporary_directories
[1] prepare_image
WARNING: proceeding to download snaps ignoring validations, this default will change in the future. For now use --validation=enforce for validations to be ta
ken into account, pass instead --validation=ignore to preserve current behavior going forward
Fetching snapd
Fetching foo-gating-mir-kiosk
Fetching foo-gating-docker
Fetching pc-kernel
Fetching core20
Fetching foo-test-pc
Fetching core18
Copying "docker_1458.snap" (docker)
Copying "mir-kiosk_6458.snap" (mir-kiosk)
[2] load_gadget_yaml
[3] populate_rootfs_contents
[4] populate_rootfs_contents_hooks
Building from a seeded gadget - skipping the post-populate-rootfs hook execution: unsupported
[5] generate_disk_info
[6] calculate_rootfs_size
[7] populate_bootfs_contents
[8] populate_prepare_partitions
Error: Error running mkfs:
-----
mke2fs 1.45.5 (07-Jan-2020)
Discarding device blocks: done
Creating filesystem with 524288 4k blocks and 131072 inodes
Filesystem UUID: b6925dbe-7562-4f63-816b-00f390c93d50
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Copying files into the device: __populate_fs: No such file or directory while changing working directory to "/tmp/foo1/volumes/foo-model-001/part5"
mkfs.ext4: No such file or directory while populating file system
-----
root@c6211da09345:/src# ls -l /tmp/foo1/
gadget.yaml  root/        unpack/      volumes/
root@c6211da09345:/src# ls -l /tmp/foo1/volumes/foo-model-001/part3/EFI/boot/
bootx64.efi  grubx64.efi
root@c6211da09345:/src# ls -l /tmp/foo1/volumes/foo-model-001/
total 943324
-rw-r--r-- 1 root root        440 Mar 15 15:07 part0.img
-rw-r--r-- 1 root root    1048576 Mar 15 15:07 part1.img
-rw-r--r-- 1 root root 1572864000 Mar 15 15:07 part2.img
drwxr-xr-x 3 root root       4096 Mar 15 15:07 part3
-rw-r--r-- 1 root root 2147483648 Mar 15 15:07 part5.img

removing the extra-data partition from the gadget works successfully for both versions of ubuntu-image

Hi, this sounds like a bug, @jawn-smith any ideas ?

Sorry not sure how I didn’t see this ping. Taking a look today.

1 Like

I created a PR with a “fix” for this, but we do still need some discussion on that PR to make sure this is the intended behavior.

I think I’m a bit confused by the PR. AFAIU it will not create the filesystem on that partition, which makes it unusable. Shouldn’t it rather create the filesystem, but without any content?

Yeah you’re correct. There’s an incorrect comment above the dd commands that threw me off momentarily and made me thing there was a mkfs call happening there. I’ll update it.

@stuart-warren We’ve gotten this merged and released in the snap in latest/edge. Are you able to try that snap and let me know if your problem is resolved?

Thanks, I got an image to build so that’s some progress. but this version won’t boot currently

❯ gpt show -l foo-model-001.img
     start      size  index  contents
         0         1         PMBR
         1         1         Pri GPT header
         2        32         Pri GPT table
        34      2014
      2048      2048      1  GPT part - "BIOS Boot"
      4096   3072000      2  GPT part - "ubuntu-seed"
   3076096   1568768
   4644864   4194304      3  GPT part - "extra-data"
   8839168  12132319
  20971487        32         Sec GPT table
  20971519         1         Sec GPT header

Screenshot of virtualbox

[edit] Sorry, this may be unrelated

@stuart-warren are you putting the image onto a removable media like USB to boot?

Hi,

Picking up where @stuart-warren left off.

It seems the above error was not relevant to this issue.

I have tested the edge version of ubuntu-image @jawn-smith, it seems although it creates the image ok the install/seeding fails. The disk partitioning fails with Numerical result out of range

Here is a screen shot from a test in QEMU. I have the systemd debug shell running during install.

The gadget volume config used is similar to posted above:

volumes:
  foo-test-pc:
    # bootloader configuration is shipped and managed by snapd
    bootloader: grub
    structure:
      - name: mbr
        type: mbr
        size: 440
        update:
          edition: 1
        content:
          - image: pc-boot.img
      - name: BIOS Boot
        type: DA,21686148-6449-6E6F-744E-656564454649
        size: 1M
        offset: 1M
        offset-write: mbr+92
        update:
          edition: 2
        content:
          - image: pc-core.img
      - name: ubuntu-seed
        role: system-seed
        filesystem: vfat
        # UEFI will boot the ESP partition by default first
        type: EF,C12A7328-F81F-11D2-BA4B-00A0C93EC93B
        size: 1500M
        update:
          edition: 2
        content:
          - source: grubx64.efi
            target: EFI/boot/grubx64.efi
          - source: shim.efi.signed
            target: EFI/boot/bootx64.efi
      - name: ubuntu-boot
        role: system-boot
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        # whats the appropriate size?
        size: 750M
        update:
          edition: 1
        content:
          - source: grubx64.efi
            target: EFI/boot/grubx64.efi
          - source: shim.efi.signed
            target: EFI/boot/bootx64.efi
      - name: ubuntu-save
        role: system-save
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 16M
      - name: extra-data
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 2G
      - name: ubuntu-data
        role: system-data
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 2G

Cheers, Just

I guess this is a snapd issue now ?

In any case, now that we know the outcome of the above, I guess perhaps we should raise this via support.

Cheers, Just

Thanks for filing the ticket. I’ve replied there.

For posterity, all partitions with exception of ubuntu-boot, ubuntu-save and ubuntu-data are getting created at build time. Those remaining ubuntu-* partitions will be created during install. They should not be placed between existing partitions, this isn’t supported. FWIW I don’t think it’s even possible to support this case reliably without multiple reboots. (i.e. more reboots than what we have now). When ubuntu-data is listed last, it will be resized to fill the remaining space on the disk.

Also for prosperity, I will post the working gadget volume config :slightly_smiling_face:

volumes:
  foo-test-pc:
    # bootloader configuration is shipped and managed by snapd
    bootloader: grub
    structure:
      - name: mbr
        type: mbr
        size: 440
        update:
          edition: 1
        content:
          - image: pc-boot.img
      - name: BIOS Boot
        type: DA,21686148-6449-6E6F-744E-656564454649
        size: 1M
        offset: 1M
        offset-write: mbr+92
        update:
          edition: 2
        content:
          - image: pc-core.img
      - name: ubuntu-seed
        role: system-seed
        filesystem: vfat
        # UEFI will boot the ESP partition by default first
        type: EF,C12A7328-F81F-11D2-BA4B-00A0C93EC93B
        size: 1500M
        update:
          edition: 2
        content:
          - source: grubx64.efi
            target: EFI/boot/grubx64.efi
          - source: shim.efi.signed
            target: EFI/boot/bootx64.efi
      - name: extra-data
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 2G
      - name: ubuntu-boot
        role: system-boot
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        # whats the appropriate size?
        size: 750M
        update:
          edition: 1
        content:
          - source: grubx64.efi
            target: EFI/boot/grubx64.efi
          - source: shim.efi.signed
            target: EFI/boot/bootx64.efi
      - name: ubuntu-save
        role: system-save
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 16M
      - name: ubuntu-data
        role: system-data
        filesystem: ext4
        type: 83,0FC63DAF-8483-4772-8E79-3D69D8477DE4
        size: 2G

Extra volume is just before ubuntu-boot

Thanks for all responses :+1:

Cheers, Just