Unable to resize an existing partition

[jlebon]

I'm trying to write an fcct to resize the root partition to e.g. 5G and leave the rest unassigned (let's forget about coreos-growpart.service for now). Here's what I'm using:

storage:
  disks:
  - device: /dev/vda
    wipe_table: false
    partitions:
    - number: 4
      size_mib: 5000
      start_mib: 0
      label: root

This gives me an error:

Ignition failed: create partitions failed: Partition 4 didn't match: size did not match (specified 10240000, got 4405248)

This is needed so that we can grow the rootfs a bit more before trapping it behind e.g. a /var partition. See thread starting at coreos/coreos-assembler#924 (comment).

[arithx]

I believe you need to specify wipe_partition_entry: true

[jlebon]

I believe you need to specify wipe_partition_entry: true

Sure, but I don't want to do that. :) I want Ignition to resize the existing partition on which the root filesystem lives.

[darkmuggle]

I think that we would want a new schema entry for "grow"?

[bgilbert]

I believe you need to specify wipe_partition_entry: true

Sure, but I don't want to do that. :) I want Ignition to resize the existing partition on which the root filesystem lives.

Why not? Resizing a partition is exactly deleting it + recreating it.

Alternatively, for the special case of the root FS, you can just create the var partition at a specified offset into the disk. Automatic resize will then resize root up to the start of var.

[jlebon]

Why not? Resizing a partition is exactly deleting it + recreating it.

Technically yes, but only if it's recreated at the same starting offset. If there's a hole before the partition you're looking to resize, wipe_partition_entry: true will just move it further up.

This isn't an issue of course with the rootfs on FCOS since the partitions are tightly packed. But in the more general case, we should have some way to allow users to do a pure resize (i.e. keep the starting offset at the same place).

[bgilbert]

@jlebon Yeah, I think you're right. That also lets users avoid respecifying any other relevant properties of the partition, such as the type GUID.

[sohankunkerkar]

After some discussion with @arithx and @bgilbert, I'm jotting down an approach here so that other folks can provide some feedback:

1. A boolean variable (resizePartition) is required to indicate whether we want to resize an existing partition.
2. We'd mostly follow the partition re-use semantics table except in the case where the partition is present, shouldExist is true, and wipePartitionEntry is false in which case if the size (size_mib) doesn't match and resizePartition is set to true then we just resize the partition.

[cgwalters]

I think in order to test this sanely we need to use a fcct which also e.g. provisions a /var partition - otherwise what will happen is Ignition will grow root to what's specified, but then our main growpart will kick in after that and resize it fully anyways right?

[cgwalters]

Or, another more complicated idea: Change the code in fedora-coreos-config to detect resizing the root partition in the same way we detect reprovisioning the root filesystem: https://github.com/coreos/fedora-coreos-config/blob/f974aff12fcea21724dda20ce32df0cea93e44b9/overlay.d/05core/usr/lib/dracut/modules.d/40ignition-ostree/ignition-ostree-dracut-rootfs.sh#L14 and if so, then we turn off growpart.

[cgwalters]

Or perhaps we should move the "fallback/default growpart" into Ignition; I think I was arguing that at one point somewhere.

Anyways short term let's just add a var partition for testing.

[jlebon]

Or, another more complicated idea: Change the code in fedora-coreos-config to detect resizing the root partition in the same way we detect reprovisioning the root filesystem: coreos/fedora-coreos-config@f974aff/overlay.d/05core/usr/lib/dracut/modules.d/40ignition-ostree/ignition-ostree-dracut-rootfs.sh#L14 and if so, then we turn off growpart.

Yeah, I think that makes sense. This is actually trivially easy to do because we already have that logic in coreos-growpart. But it's just that it's gated behind rootfs reprovisioning. Opened coreos/fedora-coreos-config#604.