0

I have a UEFI computer with a GPT-partitioned drive. On this drive there is an EFI system partition, a second partition with a bootable Ubuntu system, and lots of unallocated space. I'd like to restore the entire drive to a legacy BIOS computer, and boot into Ubuntu from it.

In order to avoid making an entire 2TB drive backup including all the unallocated space, I've tried backing up and restoring the partition images with no luck, I get sent to a GRUB shell. I formatted the destination drive as GPT since it seemed to let me. Maybe I should have done MBR but I wasn't sure if GPT partitions could go on an MBR. So my question is: Is it possible to restore a Linux GPT partition to an MBR or a legacy BIOS system in general? And is there a way to do it with individual partitions instead of a full drive image, to save time?

Improve this question
3
  • vincebel, your wording is unfortunately very unprecise. What you want to do is to convert a disk with a GPT partition table into a disk with a MBR-style partition table. There is no such thing as a "GPT partition". Partitions are just continuous storage areas on a single disk and those areas do not differ when being embedded into a GPT partition table structure or a MBR-style partition table structure.
    – r2d3
    Sep 21, 2022 at 20:45
  • You stated: "And is there a way to do it with individual partitions instead of a full drive image, to save time?" As explained in my first comment there is no MBR or GPT status on partition level. You can't make a disc half MBR and half GPT.
    – r2d3
    Sep 21, 2022 at 20:58
  • @r2d3 thanks, my understanding of drive partitioning is limited. Does this mean a partition from a GPT-partitioned disk should have no problem being restored to a partition on an MBR-partitioned disk? And will the EFI system partition need to be moved over as well?
    – vincebel
    Sep 22, 2022 at 12:36

3 Answers 3

Reset to default
0

Understanding the conversion from a GPT partitioned disk into a MBR partitioned disk

This conversion can create difficulties arising out of the differences in the on-disk format of the two partition table structures.

The term LBA describes an access method to a disk by using a rising "house number" starting at number zero, ending at n-1 where n denotes the total number of sectors of the disk.

GPT (stands for GUID Partition Table)

GPT is a simple structure starting at LBA=0 consisting of a header starting at LBA=1 and a following table where each entry is pointing to a start and end sector of a partition in terms of LBA (logical block address). There is a backup of the structure at the end of the disk.

To prevent legacy operating systems from overwriting this space not recognizing the GPT structure a protective MBR is placed in LBA=0 telling a legacy operating system that the whole space is already used up.

So the on-disk structure would look like:

pMBR GPTHeaderAndTable p1 p2 p3 p4 p5 p6 ... GPTbackup

There is no requirement of free space between each of the partitions.

MBR (stands for master boot record)

MBR initially starts as a simple table as well, located in the first sector of a disk (LBA=0), containing a maximum of four entries. Later on Microsoft extended this structure by introducing the extended partition. An unlimited number of so-called logical partitions can be held in this structure.

The disadvantage is its on-disk layout: It requires a chained list of additional partition tables residing between the space occupied by each partition.

A simple MBR in LBA=0 could hold just a primary partition entry. When dealing with two partitions, a primary partition and another logical one, a second partition table was required residing in between of the primary partition and the logical one:

MBR primary1 ext_table logical1

Note that the second partition labeled logical1 does not follow immediately primary1. ext_table uses up one sector.

When dealing with three partitions, a primary one and two logical ones the MBR structure would require the MBR at LBA=0, and one partition table between each of the logical ones:

MBR primary1 ext_table logical1 ext_table logical2

Each ext_table uses up at least one sector.

Creating a MBR in Microsoft style

To make things worse, Microsofts fdisk was initially placing partition tables on cylinder boundaries [cylinder=anything, head=0, sector=1] and the partition itself was placed in [cylinder=anything, head=1, sector=1] On a disk with a CHS-layout of 63 sectors that would yield in 63 unused sectors. CHS-adressing (cylinder, head, sector) is an outdated scheme to adress sectors. It's information is required for legacy operating systems such as Windows XP. MBR-style partition tables contain CHS-style and LBA-style information to address partition.

Depending on how compatible your conversion program wants to be, it needs at least 1 sector for an additional partition table between each partition.

With the appearance of advanced disk format and its physical sector size of 4096 bytes it was pretty dumb (perfomance-degrading and stressing for the disk) to follow those practices. I think Gparted at least and maybe others allowed to partition differently, putting partition starts on megabyte boundaries (wasting 2048 sectors between each partition (2048*512=1048576)).

The space requirement of a MBR-style partition could cause the move of a partition by some sectors. This is a risky operation especially when there is no power buffer like a laptop battery that suggest making a backup. With the time needed for a backup one might consider rather getting a second disk partition the disk and copy the partitions over to the new disk one by one.

comments regarding your comments

@vincebel: There is no guarantee of this conversion to work and it may be a risky operation. The above should explain that to you.

@gronostaj: I try to explain additional space requirements. On the other hand, the space for the GPT table and its backup is not required anymore. But the conversion method can increase space requirements the more partitions you have. PLease don't use abbreviations like ELI5. I am not a native English speaker and I have to look them up. Thank you.

Improve this answer
0

Essentially speaking, the most important information in a partition entry (of a partition table, regardless of the type) are just a pair of numbers denoting a starting point (logical block address, LBA) and an ending point of the partition (i.e. a contiguous range of logical blocks, or sectors if you prefer, of the drive). Naturally they give you the size of the partition as well.

So as long as on the destination drive you can create MBR/msdos partition table with partitions (entries) that have the same sizes as the source partitions on the GPT-partitioned drive, and that the logical block / sector size of both drives are the same, you can do something like dd if=/dev/sdXn of=/dev/sdYm (where n may or may not equal to m) to dump each of the partitions at a time (but certainly, you can write a little shell loop to automate things, if you insist; just that it's probably not considered a safe practice by most) from the source drive to the destination drive, and all the data on each of them would be preserved properly.

What would really be concerning / problematic to you is that you may not be able to boot the destination drive out-of-the-box after the dumping / restoration, because metadata that is lost / changed in the new partition table might be crucial for the bootloader you use to load properly. Essentially speaking you'll just need to reinstall (including a proper rewrite / regeneration of relevant bootloader conf) it right.

Additionally, you might need to see which variant(s) of grub you need on the destination drive. Say you need it to be bootable on both BIOS/CSM and native UEFI, you'll need to install both the i386-pc variant and the x86_64-efi variant (or, for the corner case of 32-bit UEFI, the i386-efi variant).

It might be worth noting that in data can be placed on logical blocks that do not belong to any of the partitions on a drive, such as the "gap" between the MBR and the nearest (i.e. in terms of starting LBA) partition that follows. For example, i386-pc grub places some of its code there. (But this is just a little side note. It isn't exactly relevant in your case.)

P.S. The word "sector" can have different meaning in different context. Some consider it to particularly refer to "physical block" on a (conventional) HDD. In the Linux kernel code (not necessarily in userspace programs) it refers to 512-byte block specifically. In this answer, it's just used as a synonym of "logical block", in case the term looks too strange to you.

Improve this answer
1
  • But really, consider file-based backup and restore solutions / approaches such as tar or rsync. Often they save you a lot of time, and in the case of SSD, write cycles.
    – Tom Yan
    Sep 23, 2022 at 0:56
-7

It's not possible to change the partition map type, eg. go from GPT to MBR without erasing the partitions too.

edit: The above line is incorrect. Thanks to gronostaj for the correction.

For a linux system you should be able to

The process is very destructive so make sure your backup works before deleting the partition map.

Improve this answer
9
  • This is just not true. GPT is significantly larger than MBR and a conversion is possible as long as partitions don't exceed MBR's limitations. gdisk can do it.
    – gronostaj
    Sep 21, 2022 at 19:24
  • @gronostaj then for my situation would the process be to convert my GPT drive to MBR on the source device using such a tool, create a backup .img of the MBR drive, then restore to the legacy BIOS system?
    – vincebel
    Sep 21, 2022 at 19:28
  • No, you don't need to convert. What you need to is to install GRUB for BIOS/Legacy instead of GRUB for UEFI in a small unformatted "bios_grub" partition. Unlike Windows, Linux allows Legacy with GPT and even UEFI with MBR. Maybe it shouldn't but it does...
    – ChanganAuto
    Sep 21, 2022 at 20:15
  • gronostaj, your reasoning is wrong because it does not take the space requirements of MBR structures into account.
    – r2d3
    Sep 21, 2022 at 20:15
  • @r2d3 - gronostaj's comment literally had the requirement, that it's possible, provided the partitions don't exceed MBR's limitations. Which is essentially limited to 2TB disk, but that comment, is coming from a Windows expert. However, what I do know about Linux, makes me agree what the author wants should easily be achievable with GRUB.
    – Ramhound
    Sep 21, 2022 at 21:40

You must log in to answer this question.

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