When using LVM, wrong partition type code is used

Bug #1682204 reported by Rod Smith
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Invalid
Undecided
Unassigned
curtin
Triaged
Medium
Unassigned

Bug Description

When MAAS is configured to use LVM for deployment, LVM physical volumes (partitions) are given the wrong partition type code -- 0x83 on MBR disks or 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (8300 in gdisk) on GPT disks. These type codes are used for Linux filesystems, and indeed, some tools (like fdisk) report them as such.

The appropriate type code for LVM partitions is 0x8E (on MBR) or E6D6D379-F507-44C2-A23C-238F2A3DF928 (on GPT; 8E00 in gdisk; "lvm" flag in parted). This type code explicitly identifies LVM partitions. See, for instance:

* http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
* https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

For the most part, Linux ignores partition type codes, so the current misuse of type codes doesn't negatively affect deployment, booting, or routine operation; however, it's conceivable that some utility or script that will be run on a node will try to use type codes to identify LVM vs. Linux filesystem partitions and come to the wrong conclusion because of the incorrect type code and therefore misbehave in unpredictable ways.

MAAS version information on the server on which I discovered this issue:

$ dpkg -l '*maas*'|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============================-==============================-============-==================================================
ii maas 2.1.5+bzr5596-0ubuntu1~16.04.1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cert-server 0.2.30-0~74~ubuntu16.04.1 all Ubuntu certification support files for MAAS server
ii maas-cli 2.1.5+bzr5596-0ubuntu1~16.04.1 all MAAS client and command-line interface
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 2.1.5+bzr5596-0ubuntu1~16.04.1 all MAAS server common files
ii maas-dhcp 2.1.5+bzr5596-0ubuntu1~16.04.1 all MAAS DHCP server
ii maas-dns 2.1.5+bzr5596-0ubuntu1~16.04.1 all MAAS DNS server
ii maas-proxy 2.1.5+bzr5596-0ubuntu1~16.04.1 all MAAS Caching Proxy
ii maas-rack-controller 2.1.5+bzr5596-0ubuntu1~16.04.1 all Rack Controller for MAAS
ii maas-region-api 2.1.5+bzr5596-0ubuntu1~16.04.1 all Region controller API service for MAAS
ii maas-region-controller 2.1.5+bzr5596-0ubuntu1~16.04.1 all Region Controller for MAAS
un maas-region-controller-min <none> <none> (no description available)
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-maas-provisioningserver <none> <none> (no description available)
ii python3-django-maas 2.1.5+bzr5596-0ubuntu1~16.04.1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.1.5+bzr5596-0ubuntu1~16.04.1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.1.5+bzr5596-0ubuntu1~16.04.1 all MAAS server provisioning libraries (Python 3)

I'm attaching the /var/log/maas directory tree from this server.

Revision history for this message
Rod Smith (rodsmith) wrote :
Revision history for this message
Blake Rouse (blake-rouse) wrote :

This is an issue with curtin not MAAS.

Changed in maas:
status: New → Invalid
Revision history for this message
Rod Smith (rodsmith) wrote :

I've discovered that, when using a "flat" layout, swap partitions are similarly misidentified as type 0x83 (on MBR) or 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (on GPT), when they should be 0x82 (on MBR) or 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F (on GPT; 8200 in gdisk).

Ryan Harper (raharper)
Changed in curtin:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Ben Gardner (bengardner) wrote :

I did a fresh install from ubuntu-20.04-live-server-amd64.iso and see the same problem.
The LVM partition was assigned the generic Linux GUID instead of the LVM GUID.
This broke my custom disk extraction utility. I manually corrected the GUID.

Revision history for this message
Nguyen Trung Hieu (thaygiaoth) wrote :

by command for easy checking:

On Ubuntu 20.04.2

root@ubuntu20042:~# lsblk -o +PARTTYPE
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT PARTTYPE
loop0 7:0 0 55.4M 1 loop /snap/core18/1944
loop1 7:1 0 69.9M 1 loop /snap/lxd/19188
loop2 7:2 0 31.1M 1 loop /snap/snapd/10707
sda 8:0 0 8G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi c12a7328-f81f-11d2-ba4b-00a0c93ec93b
├─sda2 8:2 0 1G 0 part /boot 0fc63daf-8483-4772-8e79-3d69d8477de4
└─sda3 8:3 0 6.5G 0 part 0fc63daf-8483-4772-8e79-3d69d8477de4 --> wrong GUID
  └─ubuntu--vg-ubuntu--lv 253:0 0 6.5G 0 lvm /

On CentOS 8

[root@eficentos8 ~]# lsblk -o +PARTTYPE
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT PARTTYPE
sr0 11:0 1 8.6G 0 rom
nvme0n1 259:0 0 8G 0 disk
├─nvme0n1p1 259:1 0 600M 0 part /boot/efi c12a7328-f81f-11d2-ba4b-00a0c93ec93b
├─nvme0n1p2 259:2 0 1G 0 part /boot 0fc63daf-8483-4772-8e79-3d69d8477de4
└─nvme0n1p3 259:3 0 6.4G 0 part e6d6d379-f507-44c2-a23c-238f2a3df928 --> correct GUID
  ├─cl_eficentos8-root 253:0 0 5.6G 0 lvm /
  └─cl_eficentos8-swap 253:1 0 820M 0 lvm [SWAP]

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I don't want to come across as dismissive -- but does this actually matter for anything?

Revision history for this message
Rod Smith (rodsmith) wrote :

@Michael Hudson-Doyle, see @Ben Gardner's comment #4; specifically:

"This broke my custom disk extraction utility."

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Well I guess it's possible to construct situations where this matters... but also I think this should be reasonably easy to fix, at least for the live server installer. MAAS could implement a similar fix. I guess it could also be fixed in curtin too but that would be a bit of an abstraction violation in some ways.

(I don't think anything at all in udev etc cares about partition type codes, it's all libblkid probing for magic numbers so IMO a disk extraction tool would be more robust to do the same)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.