Change PTTYPE and UUID of an fdisk created partition

Question

I've got two systems. On one, I decided to try and increase the virtual disk /dev/sda. So I delete the partition using fdisk and recreate it with a larger end size but identical start location. ( Initially, I make the mistake of creating the partition as an extended one then revert to making it a primary one. ) I also ensure the type (id) is set to 8e ( Linux LVM ).

I write the new partition to disk, reboot and run into a boot issue.

And now the disk won't mount. So I try to recreate the initramfs using the following:

Recovery Option 3 (shell):

vgscan -v --mknodes
vgchange -a y

mkdir /mnt/root
mount /dev/mapper/centos-root /mnt/root

mount -o bind /dev /mnt/root/dev
mount -o bind /sys /mnt/root/sys
mount -o bind /proc /mnt/root/proc
mount /dev/sda1 /mnt/root/boot

chroot /mnt/root

cd /boot
dracut -f
grub2-mkconfig -o /boot/grub2/grub.cfg

but that has no effect. Then I notice the following from the same VM recovery console:

sh-4.2# blkid /dev/sda2
/dev/sda2: PTTYPE="dos"
sh-4.2#

whereas on the first good VM that boots fine ( both are clones of the same template ) I see the following:

# blkid /dev/sda2
/dev/sda2: UUID="owcjYz-ohz3-3obA-KaL0-wcyn-ayc5-EG1Fgc" TYPE="LVM2_member"

So based on the error that it can't find centos-root at boot time, I began to suspect it's because /dev/sda2 is set to PTTYPE="dos" rather then TYPE="LVM2_member" instead:

But how do I change this on /dev/sda2? I tried:

tune2fs /dev/sda2 -U random

returns "Bad magic number in super-block while trying to open /dev/sda2" and "Couldn't find valid filesystem superblock."

Googling for this hasn't proven fruitfull. Using the search string "change partition type LVM2_member" yields fdisk pages showing how to change the partition type in fdisk, which I already did above.

Searching for "change UUID" results in tune2fs commands that won't work on the fdisk partition and will yield the above error. Searching for "PTTYPE" yields only pages with blkid output.

Would anyone be able to share how to change the TYPE and UUID of the /dev/sda2 partition once fdisk creates it?

Perhaps I should be using another command instead? All this would have to be done from the recovery console.

Detailed blkid output of the good disk:

[root@sys01 ~]# blkid -po udev /dev/sda2
ID_FS_UUID=owcjYz-ohz3-3obA-KaL0-wcyn-ayc5-EG1Fgc
ID_FS_UUID_ENC=owcjYz-ohz3-3obA-KaL0-wcyn-ayc5-EG1Fgc
ID_FS_VERSION=LVM2\x20001
ID_FS_TYPE=LVM2_member
ID_FS_USAGE=raid
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_TYPE=0x8e
ID_PART_ENTRY_NUMBER=2
ID_PART_ENTRY_OFFSET=1026048
ID_PART_ENTRY_SIZE=133191680
ID_PART_ENTRY_DISK=8:0
[root@sys01 ~]#

blkid of the bad disk ( host sys02 ):

sh-4.2# blkid -po udev /dev/sda2
ID_PART_TABLE_TYPE=dos
ID_PART_TABLE_SCHEME=dos
ID_PART_ENTRY_TYPE=0x8e
ID_PART_ENTRY_NUMBER=2
ID_PART_ENTRY_OFFSET=1026048
ID_PART_ENTRY_SIZE=133191680
ID_PART_ENTRY_DISK=8:0
sh-4.2#

Answer 1

Reposting my answer here using the available tags for clarity.

pvcreate is responsible for setting the UUID and TYPE flags that we see above. However, doing so on a recreated partition through fdisk /dev/sda will render the data inaccessible on the partition. This is because it apparently overwrites other metadata.

So what I effectively needed to do is the following:

1. Create a new partition using fdisk on another disk.
2. Run pvcreate on the new disk.
3. Use the above commands to bring up the unmountable VG and LV.
4. vgextend over to the new disk.
5. pvmove extents over to the new disk.
6. vgreduce out of the old disk.
7. fdisk then pvcreate to remove the old partition and recreate it with correct tags.
8. Repeat the process again to move extents back to the original partition.