15

I have an MBR partition which I want to convert to GPT without loosing all my data. Bios is UEFI. I am not an expert of hard disks, so please be patient. I have seen this and this but I cannot understand if I can apply those procedures without erasing all my files, since the partition has only 2048 free sectors before the beginning of data. This is my partition:

enter image description here

output of sudo fdisk -l /dev/sda

Disk /dev/sda: 111,81 GiB, 120034123776 bytes, 234441648 sectors
Disk model: Samsung SSD 840 
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: 0x00034386

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1  *         2048 201011199 201009152 95,9G 83 Linux
/dev/sda2       201013246 234440703  33427458   16G  5 Extended
/dev/sda5       201013248 234440703  33427456   16G 82 Linux swap / Solaris

Is it possible to perform the conversion and keep my data?

9
  • 1
    Without backups, it's only a matter of time until you lose all your data anyway.
    – user535733
    Feb 6, 2021 at 12:37
  • 1
    If you use legacy boot, the conversion will destroy your boot-loader. Information from your screenshot is insufficient, please add the output of sudo fdisk -l /dev/sda to your question. You also need to understand that the conversion will affect all partitions on the disk, not only one since you change from MBR-partition-table to GPT-partition-table.
    – mook765
    Feb 6, 2021 at 13:00
  • @mook765 added the output of fdisk. Can the boot loader (grub) be reinstalled once destroyed?
    – f.cipriani
    Feb 6, 2021 at 13:16
  • 2
    MBR and GPT are attributes of a disk (e.g. /dev/sda) not a partition (e.g. /dev/sda1). You can't set an individual partition to be GPT, as in your question; you have to set the whole disk to be MBR or GPT. Changing this is an inherently risky procedure. Don't rely on the fact that someone, somewhere on the Internet, managed it successfully. Take @user535733's hint and make sure you have a fresh, complete backup of all drives in your system before you attempt to swap the disk to GPT.
    – Graham Nye
    Feb 6, 2021 at 13:37
  • 2
    I might be missing somehting, but the comments are not really useful... Taking for granted that I made a full backup of my data before trying any procedure, and that I'm able to reinstall grub, can my partition be converted to GPT without loosing any data?
    – f.cipriani
    Feb 7, 2021 at 17:06

4 Answers 4

13
+150

The conversion from MBR to GPT pertains to a disk, not a partition: "Master Boot Record (MBR) disks use the standard BIOS partition table. GUID Partition Table (GPT) disks use Unified Extensible Firmware Interface (UEFI). One advantage of GPT disks is that you can have more than four partitions on each disk. GPT is also required for disks larger than two terabytes (TB)." (Microsoft - Convert an MBR disk into a GPT disk)

Is it possible to perform the conversion and keep my data?

Yes.

Follow this guide (no need to reproduce it here, since it is a SE site).

A summary is listed here.

  1. sudo gdisk /dev/sda.
  2. Command (? for help): n to create a new "BIOS boot" (code ef02) partition.
  3. Command (? for help): w to write the partition table.
  4. partprobe /dev/sda to reload the partition table.

To add UEFI booting:

  1. grub-install /dev/sda to re-install the GRUB boot loader using the new partition scheme.
  2. sudo gdisk /dev/sda and then n to create an "EFI System" partition (ESP).
  3. c to set the label of the new partition to something without white spaces.
  4. Command (? for help): w to write the partition table.
  5. partprobe /dev/sda to reload the partition table.
  6. mkfs -t vfat -v /dev/disk/by-partlabel/EFI-system (e.g.) to build the filesystem for the ESP.
  7. mkdir /boot/efi to create a mount point for the ESP.
  8. Add /dev/disk/by-partlabel/EFI-system /boot/efi vfat defaults 0 2 (or whatever matches items 11 and 12 above) to /etc/fstab, so it is automatically mounted.
  9. mount /boot/efi to mount the ESP.
  10. grub-install --target=x86_64-efi /dev/sda to install the GRUB EFI bootloader.
  11. Reboot.
  12. Change BIOS boot -> UEFI boot in the BIOS.
  13. Use the one-time boot menu to force boot the disk. You may have to navigate to the disk: EFI -> ubuntu -> grubx64.efi.
  14. grub-install to re-install GRUB's EFI bootloader to update the UEFI boot selector.

Notes:

  1. I can't miss this point (even if mentioned across the board): make a backup of your data.
  2. Your /dev/sda1 starts at sector 2048 so you are good to go.
  3. You might need to make some room for the EFI System partition.
  4. This (noted in a comment) lists more disperse instructions across answers. And less detail.
0
3

The short version is, Yes, it is possible. But a few points from me:

  • When doing the conversion, boot from a rescue media (or just from install media), otherwise you will not be able to see if the changes you are doing have any impact on the live system (if a partition is in use, the kernel is not able to reload the partition table)
  • Backup your original partition table. The MBR is exactly 512 bytes, so just doing a dd if=/dev/sda bs=512 count=1 of=backupfile should be enough to make a copy of the original MBR. A copy of the GPT is also stored after the MBR and before the first partition (in this case the first partition starts at sector 2048), so backing up this space should be enough to undo any damage you may cause to your disks dd if=/dev/sda bs=512 count=2048).
  • If at any point you think you messed up, simply do dd if=backupfile of=/dev/sda and you can start over.
  • Now do the conversion. For starters, wipe your MBR with wipefs /dev/sda. You should only see something like the below, so go ahead and wipe it with wipefs -f /dev/sda:
DEVICE OFFSET TYPE UUID LABEL
sda    0x1fe  dos       
  • Now go ahead and create your GPT table with gdisk. The key here is when creating the partitions, make sure to match the start and end to be the same as before.
  • Note that you don't have to create an extended partition in GPT, so just skip that one.

Here is a rundown of the commands you need to run. I did against a file, but you can do against sudo /dev/sda instead.

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): n
Partition number (1-128, default 1): 
First sector (34-234441614, default = 2048) or {+-}size{KMGTP}: 2048
Last sector (2048-234441614, default = 234441614) or {+-}size{KMGTP}: 201011199
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): n
Partition number (2-128, default 2): 5
First sector (34-234441614, default = 201011200) or {+-}size{KMGTP}: 201013248
Last sector (201013248-234441614, default = 234441614) or {+-}size{KMGTP}: 234440703
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): 8200
Changed type of partition to 'Linux swap'

Command (? for help): p
Disk /dev/sda: 234441648 sectors, 111.8 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 75C2AE94-C3C0-4927-A4D2-48BBDECE3AD7
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 2048-sector boundaries
Total free space is 4973 sectors (2.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       201011199   95.8 GiB    8300  Linux filesystem
   5       201013248       234440703   15.9 GiB    8200  Linux swap

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

If your bootloader is on the same disk, there is a very good chance it will fail to boot. This is a much more involved process, so if that is the case... restore your MBR (remember to save the backupfile), and you'd need to create an EFI BOOT partition (if I were you, I'd shrink down the swap and recreate it, to make some space - 500MB or so for the EFI boot partition), and make sure you get the installer on it. Make sure you boot from an UEFI boot media, or it would be tough to install grub in UEFI mode.

1

I can't reply to @chutz, so I'm making my own comment: DO NOT DO WHAT HE SAYS ABOUT BACKUP AND SUBSEQUENT RESTORE OF THE MBR. The MBR is 512 bytes, total. So while I 100% agree with backing up the MBR, ONLY back up the MBR: dd if=/dev/sda of=backupfile.mbr bs=512 count=1 and then restore exactly as he says: dd if=backupfile.mbr of=/dev/sda

But using a count of 2048 means:

  1. You're backing up 2047 times more than you need to, AND
  2. that 2047 * 512 bytes' worth of data might very well overwrite new on-disk stuff, causing corruption. Just Say No.
1
  • 1
    Very good point. The purpose of the backup is to revert any changes done by the operation and making a GPT does modify the data in the space before the first partition. The first partition starts at sector 2048, so the command does not touch any of the data used by the filesystems.
    – chutz
    May 3, 2022 at 20:37
1

I don't have enough rep to comment on user995746's post, so I'll do it here (what a stupid reputation system).

Backing up the full 2048 sectors is what saved my system when this conversion failed. I tried restoring just the first 512 bytes, but the left over GPT bits seemed to render the system unbootable for some reason. Restoring everything prior to the first partition recovered the system.

  1. backing up an extra 1MB is completely negligible in time and space.
  2. there shouldn't be anything you need in thos first 2048 sectors, but there are apparently things you might not want.
1
  • You're right, I'd also better play it safe than sorry. Dec 18, 2023 at 20:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .