2

I'm deploying AMD64 nodes with a 3TB first disk with MAAS but I only get a 2TB partition because curtin uses MBR instead of GPT for the partitioning.

2

Curtin tries to choose the most appropriate partition table type for a given node:

  • For systems that are booting in BIOS mode, it defaults to an MBR-stored DOS partition table
  • For systems that are booting in UEFI mode (including ARMv8-based UEFI-enabled systems like Cavium Thunder and APM X-Gene) it defaults to a GPT partition table

Therefore, the easiest way to get a GPT partition table is to configure the node to boot in UEFI mode, which is supported starting with MAAS 1.5.

There are two additional ways to get curtin to create GPT partitions:

  • You can modify the curtin configuration provided by MAAS to curtin in /etc/maas/preseeds/curtin_userdata to include:

    block-meta:
        format: gpt
    
  • If you have up to 4 partitions, you can easily convert DOS partition tables to GPT partitions post-installation. Curtin makes an effort to leave enough space in the partitioning to allow the conversion to successfully happen, and from r224 onwards it ensures it. Converting can be done with:

    sgdisk --mbrtogpt <device>
    
| improve this answer | |
  • 1
    Unfortunately, on MAAS 2.0 at least, if you convert an MBR partition on a boot disk to GPT using sgdisk, the system appears to be rendered unbootable. – nturner Aug 23 '16 at 17:09
  • See also bugs.launchpad.net/maas/+bug/1616232 – nturner Aug 31 '16 at 17:20
1

I have tried a number of workarounds (including the one suggested in kiko's solution) to no avail.

The following works pretty reliably, at least with MAAS 2.3.5 running on Xenial:

  1. Commission the node and partition its disk as you would normally (eg: using the web UI) but stop before deploying the node.
  2. Run the following cmd-line query: maas $USER block-devices read $nodeid ($nodeid can be read from the URL on the web UI for example; it's an internal six alphanum identifier for the node)
  3. Grab the block device id. You'll see that partition_table_type doggedly says "MBR"
  4. Now sign-on to MAAS' Postgres DB: sudo -u postgres psql -d maasdb
  5. Update the partitioning scheme to GPT, update maasserver_partitiontable set table_type='GPT' where block_device_id=$block_dev_id (substitute `$block_dev_id with the id you read at step 3)
  6. Optionally repeat the query from step 2 and check that the partition_table_type has been updated to GPT.
  7. Deploy the node and enjoy your GPT partition table.

This isn't particularly pretty as hacking directly in MAAS' DB feels a bit off-limits but it's the next best thing until we get given a way to do this through a public API. The kind of API I have in mind would be smth like: maas $USER block-device update $node_id $block_device_id partition_table_type=GPT. This API already exists and allows updating the name of the block device as documented, but ignores the much more useful partition_table_type attribute.

Note: if you need to leave unpartitioned space on the GPT target disk, beware that this procedure appears to trigger a "feature" whereby that space gets absorbed by the last partition you lay out in MAAS. A workaround is to create a throw-away partition and delete it after deployment.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.