User:NeddySeagoon/msdos to gpt
Convert a MSDOS to GPT Disklabel In-place
This is a "Notes to Self" page before I actually do it
How did I Get into this mess?
A long time ago, I started out with a rented Xen DomU and 10G HDD. It's been migrated several times always getting bigger.
It reached 2TB a while ago and that's the end of the road for a MSDOS Disklabel. I need to add more space.
Convert in Place without data loss
That's really not possible
As usual there is a lot of incomplete misleading information on the internet. In place conversion is not supported without jiggery pokery and this page is not going to be any exception.
The backup GPT has to go somewhere
Literal in-place conversion overwrites the end of the filesystem on the last partition. Either that partition needs to be shrunk, or the volume needs to be made bigger.
As the drive in question is a Logical Volume on the host, this page will grow it at the outset, then the backup GPT will go at the end of newly enlarged volume.
A 2TB backup to my home PC is possible but my internet is 80Mbit/down 20/Mbit up so the restore will take a long time.
Overview
- Understand the on disk data layout
- Post conversion boot considerations
- Grow the volume.
- Make sure the kernel supports GPT
- Reboot - check that the new space is present
- Convert the disklabel
- Update the boot loader
Details of steps
Understand the on disk data layout
The history is in User:NeddySeagoon/The_Olde_Way and will be summarised here.
MSDOS on disk data layout
The MBR is in Logical Block Adress (LBA) 0 as its the only block on the HDD that BIOS can read.
The MSDOS partition table occupies the last 66 bytes of LBA 0. The rest of the volume is user space.
By convention, the first partition starts at LBA 63 but with GPT becoming common this was changed to LBA 2048.
The unallocated space (outside of any filesystem) before the first partition start is normally used by the boot loader.
If your first partition starts at LBA 63 the first partition start must be moved to LBA 2048
GPT on disk data layout
The MBR is in Logical Block Adress (LBA) 0. Now its called the Protective MBR. Its purpose is to serve as a warning that GPT is in use.
The primary GPT appears in LBA 1 to LBA 33 inclusive. That's space for 128 partitions.
Partition 1 can start at LBA 34 but by convention, its LBA 2048.
An the end of the volume the secondary copy of the GPT appears. That's LBA-33 to the end of the drive.
The end of the last MSDOS partition may use these logical blocks too
Post conversion boot considerations
Think about it now or booting from the converted volume will not work
Notice from the on disk data layout that the primary copy of the GPT will overwrite the boot loader embedded space. Both start in LBA 1. That cannot be avoided.
The choices are to
- switch to UEFI booting,
- try BIOS booting with GPT,
- have a small separate BIOS boot volume.
Depending on your system, not all options may be available.
Doing nothing is not an option.
This is a good time to break up the existing /boot partition into 2Mb for a bios_boot partition for grub to use in lie of the embedding space and format the rest of the old /boot as VFAT.
That keeps your options open.
- The bios_boot is required for a hybrid BIOS booting from a GPT volume.
- A VFAT partition is required for UEFI booting and is tolerated by BIOS booting.
Grow the volume
On the host
root #lvextend -L+2T /dev/guests/bloodnocadds 2TB to the guest VM.
That works as
root ## pvdisplay --- Physical volume ---
PV Name /dev/md3
VG Name guests
PV Size <5.40 TiB / not usable 4.56 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 1414342
Free PE 769222
Allocated PE 645120
shows lots of free space.
Now the guest HDD has grown from 2TB to 4TB but the guest cannot detect it yet.
Make sure the (guest) kernel supports GPT
On the guest ...
user $$ grep EFI /usr/src/linux/.config # CONFIG_EFI is not set
CONFIG_EFI_PARTITION=y
...
EFI_PARTITION=y has been the default for many years. If the output includes # CONFIG_EFI_PARTITION is not set, update the kernel now.
Reboot - check that the new space is present
Reboot the guest. fdisk should show a 2TB partition table on a 4TB disk.
Stop here if the space that will be used by the backup GPT is not present
Convert the disklabel
Update the boot loader
Historical note
Once upon a time all drives used 'head stepper' motors and HDD were just more finely engineered floppies with more than two heads.
This may matter as when the Cylinder/Head/Sector (CHS) addressing scheme was in use, partitioning tools allocated space to partitions as integer cylinders. As real CHS addressing became a myth a conventional cylinder became about 8Mb. Partitioning tools perpetuated the CHS myth for many years. As HDD were not made that way, there was a small space off the end of the last partition that was a fractional part of a cylinder.
Why might it matter?
If its there at all and its big enough, the secondary GPT will go there, meaning that a lot less jiggery pokery is required.
root ## fdisk -l /dev/vda Disk /dev/vda: 2 TiB, 2199023255552 bytes, 4294967296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x665dea2d
Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 133119 131072 64M 83 Linux
/dev/vda2 133120 4294967295 4294834176 2T 8e Linux LVM
The drive has 4294967296 sectors
The end of the last partition is at sector 4294967295
No unallocated space for me but it was worth looking.