How to ask curtin to use GPT instead of MBR with MAAS?
up vote
2
down vote
favorite
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.
maas
add a comment |
up vote
2
down vote
favorite
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.
maas
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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.
maas
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.
maas
maas
asked Jul 9 '15 at 7:35
sto
111
111
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
2
down vote
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>
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
add a comment |
up vote
0
down vote
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:
- Commission the node and partition its disk as you would normally (eg: using the web UI) but stop before deploying the node.
- 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) - Grab the block device
id
. You'll see thatpartition_table_type
doggedly says"MBR"
- Now sign-on to MAAS' Postgres DB:
sudo -u postgres psql -d maasdb
- 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) - Optionally repeat the query from step 2 and check that the
partition_table_type
has been updated toGPT
. - 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.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
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>
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
add a comment |
up vote
2
down vote
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>
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
add a comment |
up vote
2
down vote
up vote
2
down vote
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>
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>
edited Jul 10 '15 at 14:54
answered Jul 10 '15 at 14:44
kiko
324111
324111
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
add a comment |
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
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
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
See also bugs.launchpad.net/maas/+bug/1616232
– nturner
Aug 31 '16 at 17:20
add a comment |
up vote
0
down vote
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:
- Commission the node and partition its disk as you would normally (eg: using the web UI) but stop before deploying the node.
- 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) - Grab the block device
id
. You'll see thatpartition_table_type
doggedly says"MBR"
- Now sign-on to MAAS' Postgres DB:
sudo -u postgres psql -d maasdb
- 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) - Optionally repeat the query from step 2 and check that the
partition_table_type
has been updated toGPT
. - 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.
add a comment |
up vote
0
down vote
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:
- Commission the node and partition its disk as you would normally (eg: using the web UI) but stop before deploying the node.
- 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) - Grab the block device
id
. You'll see thatpartition_table_type
doggedly says"MBR"
- Now sign-on to MAAS' Postgres DB:
sudo -u postgres psql -d maasdb
- 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) - Optionally repeat the query from step 2 and check that the
partition_table_type
has been updated toGPT
. - 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.
add a comment |
up vote
0
down vote
up vote
0
down vote
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:
- Commission the node and partition its disk as you would normally (eg: using the web UI) but stop before deploying the node.
- 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) - Grab the block device
id
. You'll see thatpartition_table_type
doggedly says"MBR"
- Now sign-on to MAAS' Postgres DB:
sudo -u postgres psql -d maasdb
- 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) - Optionally repeat the query from step 2 and check that the
partition_table_type
has been updated toGPT
. - 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.
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:
- Commission the node and partition its disk as you would normally (eg: using the web UI) but stop before deploying the node.
- 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) - Grab the block device
id
. You'll see thatpartition_table_type
doggedly says"MBR"
- Now sign-on to MAAS' Postgres DB:
sudo -u postgres psql -d maasdb
- 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) - Optionally repeat the query from step 2 and check that the
partition_table_type
has been updated toGPT
. - 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.
edited Nov 20 at 8:48
answered Nov 19 at 20:45
sxc731
30128
30128
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f646278%2fhow-to-ask-curtin-to-use-gpt-instead-of-mbr-with-maas%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown