✨ Custom partitioning

[mudler]

Is your feature request related to a problem? Please describe.
Currently custom partitioning is allowed by formatting the device from cloud config, and call the installer with --no-format in the options

Describe the solution you'd like
I'd like the configuration to be streamlined in the top-level YAML, e.g.:

custom_partitioning:
- label: ""
  device: ""
  size: "100GB"

Describe alternatives you've considered
Keep things as they are

Additional context

[jimmykarily]

This is the same problem describe here I think: #391

At least, the same solution could apply.

[jimmykarily]

Duplicate? #209

[mauromorales]

@jimmykarily I don't think this is a duplicate but about making custom partitioning work also at upper level, i.e. not only kairos-install.pre.before ... will put this one on the todo list

[mudler]

We now have the mechanism, but we need to properly expose it to the cloud-config to the user.

See: #209 (comment)

Ideally we should be generating the cloud-config as #209 (comment) within specifying custom layouts in the install block.

[Itxaka]

Now kairos-agent exposes the full config via cloud-config, which means that potentially we should be able to set the partitions via the install key in the cloud-config, like elemental was able to do:

  # default partitions
  # only 'oem', 'recovery', 'state' and 'persistent' objects allowed
  # size in MiB
  partitions:
    oem:
      label: COS_OEM
      size: 60
      fs: ext4
    recovery:
      label: COS_RECOVERY
      size: 4096
      fs: ext4

  # extra partitions to create during install
  # only size, label and fs are used
  # if no fs is given the partition will be created but not formatted
  # This partitions are not automounted only created and formatted
  extra-partitions:
    - Name: myPartition
      size: 100
      fs: ext4
      label: EXTRA_PARTITION
    - Name: myOtherPartition
      size: 0
      fs: ext4
      label: EXTRA_PARTITION

Im gonna test if this works, because if so, it just needs documentation

[Itxaka]

indeed, that works out of the box.

So with the following cloud-config:

#cloud-config

install:
  debug: true
  auto: true
  device: /dev/vda
  grub_options:
    extra_cmdline: "rd.immucore.debug foobarzz"
  partitions:
    oem:
      size: 124
    recovery:
      size: 7500
    state:
      size: 16000
    persistent:
      size: 1000
  extra-partitions:
    - Name: myPartition
      size: 100
      fs: ext4
      label: EXTRA_PARTITION
    - Name: anotherOne
      size: 100
      fs: ext4
      label: ANOTHER
    - Name: extra
      size: 0
      fs: ext4

stages:
  initramfs:
    - name: "Set user and password"
      users:
        kairos:
          passwd: "kairos"
      hostname: kairos-{{ trunc 4 .Random }}

You get the following disk structure:

kairos-2yc7:~ # sudo lsblk -o NAME,SIZE,LABEL,PARTLABEL
NAME     SIZE LABEL           PARTLABEL
loop0  812.4M                 
sr0    983.2M COS_LIVE        
sr1      364K cidata          
vda       45G                 
|-vda1     1M                 bios
|-vda2   124M COS_OEM         oem
|-vda3   7.3G COS_RECOVERY    recovery
|-vda4  15.6G COS_STATE       state
|-vda5  1000M COS_PERSISTENT  persistent
|-vda6   100M EXTRA_PARTITION myPartition
|-vda7   100M ANOTHER         anotherOne
`-vda8  20.8G                 extra

Which shows:

• proper sizes for all the partitions as marked in the cloud config
• 3 extra partitions
• last partition took all the remaining space as marked on the config (size: 0)
• missing label in the last partition, according the the config

So this works out of the box with nothing to do on our side other than documentation, nice!

Things to note:

• Changing labels for our partitions is not supported AT ALL. Everything will fail.
• All values are exposed in the config file, so you can shoot yourself in the foot by setting wrong sizes and different labels
• For extra partitions, only size, label and fs are used. If no fs is passed the partition is not formatted, only created. No mountpoints or anything are possible at this point, maybe we should try to expand on that.
• Only one(1) partition is allowed to have 0 as size between the partitions and extra-partitions. Persistent defaults to 0, so in order to add an extra partition with 0 size, you need to set the size to persistent as well. So like this:

  partitions:
     persistent:
       size: 300
  extra-partitions:
    - name: newpart
      size: 0
      fs: ext4

Several improvements that we can consider for this feature:

• on sanitize of the install spec, make sure to override the LABEL and FS even if we already got it from the config and print a warning that we are ignoring those values to avoid installing a broken system
• expose the extra-partitions mountpoint somehow during install so we can add extra partitions.
• expose the disk of the extra partitions so its not tied to the install disk. This means that we could potentially have one disk with the install system and another with different partitions.

The last 2 items would work very well together, being able to set up custom mounts in a different disk directly.

[jimmykarily]

I like the last 2 suggestions. This one I don't understand though: override the LABEL and FS even if we already got it from the config . How do we know which partition was supposed to be COS_PERSISTENT for example, if the user neglected specifying one? Maybe we should just fail with an error and let the user fix the partitions if we detect badly configured partitions?

[Itxaka]

. This one I don't understand though: override the LABEL and FS even if we already got it from the config How do we know which partition was supposed to be COS_PERSISTENT for example, if the user neglected specifying one? Maybe we should just fail with an error and let the user fix the partitions if we detect badly configured partitions?

No, I mean, even if its set on the config file by the user, we override those with the default values as they cannot be configured that way. Like FS maybe ok with a validator, but the labels need to be fixed otherwise the whole system doesnt work. currently you can override it and set the label to whatever you want, but good luck getting immucore to know which partition is the state one to be able to boot lol

How do we know which partition was supposed to be COS_PERSISTENT for example

Values are set in the ElementalPartitions as defaults. So we know that the Partitions.Persistent should have the default COS_PERSISTENT label. Like its a very well defined struct with named structs on it to identify exactly what we need:

type ElementalPartitions struct {
	BIOS       *Partition
	EFI        *Partition
	OEM        *Partition `yaml:"oem,omitempty" mapstructure:"oem"`
	Recovery   *Partition `yaml:"recovery,omitempty" mapstructure:"recovery"`
	State      *Partition `yaml:"state,omitempty" mapstructure:"state"`
	Persistent *Partition `yaml:"persistent,omitempty" mapstructure:"persistent"`
}

[Itxaka]

@jimmykarily this is what I mean with that, even if the user sets those values on the config file, we override them with the default ones as those are neede for the system to work as expected: kairos-io/kairos-agent#108

[jimmykarily]

gotcha, thanks!