How to Force GPT disk label

Users
1

I’m using MAAS (2.4.2) to install CentOS some server in a very remote location and I face a tricky problem. All machine have an HW raid of 12TB capacity. So I aim to a GPT partition table.

When I deploy the OS, the disk got formatted with a DOS label, so 10TB over 12TB are wasted. I found a related questions here and here, but all solutions described there did not work for me. Either I got a DOS label or I get a non booting system. I’m aware of curtin customization, but even early commands come too late.

I tried to modify the php relevant code inside MAAS (models/partitiontable.py) to always use GPT, but again I get is only a DOS label.

I found nowhere a log of the switch from GPT to DOS label.

After the commit I dumped the internal MAS database (as suggested in the answer above, but data structure has changed). And I get (other server record suppressed):

>  id |            created            |            updated            | table_type | 
> ----+-------------------------------+-------------------------------+------------+
>  27 | 2020-03-21 15:14:38.370525+00 | 2020-03-21 15:14:38.370525+00 | GPT        |

If I launch the recovery image I get:

ubuntu@pssproto13:~$ sudo fdisk -l /dev/sda
Disk /dev/sda: 10.9 TiB, 11999998115840 bytes, 23437496320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0310cd8b
Device     Boot Start        End    Sectors Size Id Type
/dev/sda1  *     2048 4294967262 4294965215   2T 83 Linux

The commit log reads (only an excerpt):

  "NAME": "sda",
  "MODEL": "ServeRAID M1215",
  "PATH": "/dev/sda",
  "FIRMWARE_VERSION": "4.62",
  "SERIAL": "600605b00cdc3b30206fb2250d5cb54e",
  "ID_PATH": "/dev/disk/by-id/wwn-0x600605b00cdc3b30206fb2250d5cb54e",
  "SIZE": "11999998115840",
  "BLOCK_SIZE": "4096"

And again I get a DOS partition table.

The servers (Lenovo servers with IMMI2 management) are set up to boot in UEFI mode:

BootModes.OptimizedBoot=Enabled
BootModes.QuietBoot=Enabled
BootModes.SystemBootMode="UEFI Mode"

Any ideas on how I can recover the unavailable disk space? Thank in advance for your suggestions.

2

Hi Carlo,
When I did the database edit trick, use of GPT was reflected in the GUI. i.e. the storage layout in the GUI showed that it was going to use a GPT partition table.

I’ve just checked now and my MAAS automatically selects GPT partition tables when I partition a storage device with more that 2TB of space.

Your version is MAAS is a bit old, I suspect you might need to upgrade. I’m using MAAS 2.6.2.

Cheers,
Lloyd

3

Thank you for your suggestion. As also the MAAS machine is remote, I need to be very careful, and so slow. I will update about results

4

MAAS does not currently allow you to specify the partition table type. It uses the following algorithm

  • If the system is UEFI GPT it always used as it is a requirement for booting on UEFI systems.
  • If the system is booting in BIOS mode MBR is always used on the boot disk as not all BIOS systems support GPT.
  • If the disk is 2TB or greater and is not a boot disk GPT is used as MBR doesn’t support disks 2TB or greater.
  • MBR is used in all other scenarios as it is the most compatible.

It looks like MBR is being forced due to your system booting in BIOS compatibility mode. Can you recommission the machine to use UEFI?

5

@ltrager
Thank you for your clear summary. All my machines have, as only disk, a hardware raid of 12TB. They are all set-up to UEFI boot. From IMMI2 bios report:

BootModes.OptimizedBoot=Enabled
BootModes.QuietBoot=Enabled
BootModes.SystemBootMode="UEFI Mode"

I’m aware this should drive MAAS to format disks with a GPT label. But for some reason this does not happen.

6

MAAS uses the mode the system was in at commissioning time. Try recommissioning the system after you are sure UEFI mode is selected. If MBR is still being used goto the event log, click view full history, and search for TFTP and post the results.

7

Sorry for the delayed reply.
I reinstalled one of the machine. After commissioning I verify the Boot setting:

BootModes.OptimizedBoot=Enabled
BootModes.QuietBoot=Enabled
BootModes.SystemBootMode="UEFI Mode"

Then, I installed again, and I got a DOS MBR. The event log around TFTP requests reads:

Node commissioning - 'cloudinit' searching for network datasources      Sat, 04 Apr. 2020 09:47:34
Node commissioning - 'cloudinit' searching for local datasources        Sat, 04 Apr. 2020 09:47:31
TFTP Request - ubuntu/amd64/generic/bionic/daily/boot-initrd            Sat, 04 Apr. 2020 09:46:18
TFTP Request - ubuntu/amd64/generic/bionic/daily/boot-kernel            Sat, 04 Apr. 2020 09:46:15
TFTP Request - pxelinux.cfg/01-08-94-ef-41-43-80                        Sat, 04 Apr. 2020 09:46:14
PXE Request - commissioning                                             Sat, 04 Apr. 2020 09:46:14
TFTP Request - pxelinux.cfg/e239b5d0-0515-e711-a635-0894ef414380        Sat, 04 Apr. 2020 09:46:14
TFTP Request - ldlinux.c32                                              Sat, 04 Apr. 2020 09:46:14
TFTP Request - pxelinux.0                                               Sat, 04 Apr. 2020 09:46:14
TFTP Request - pxelinux.0                                               Sat, 04 Apr. 2020 09:46:14
Node powered on                                                         Sat, 04 Apr. 2020 09:41:15
Powering node on                                                        Sat, 04 Apr. 2020 09:41:10

This is not helpful to me. Any ideas on how can I proceed?
Thanks for your answers.

8

pxelinux is only used when booting into legacy BIOS mode. On some systems you not only have to tell the machine to boot into UEFI made but configure it to perform a UEFI network boot as well.

9

Thanks for your answer. I will check if in the hundreds bios tems on these machines there is a network boot item. I will report about it.

1 Like