DriveSetup won't let you repartition GPT drives to MBR (intel)

[kallisti5]

Run DriveSetup on a GPT disk, choose the disk and the 'Initialize -> Intel' option is disabled.

While we don't yet support writing GPT partition tables, we should be able to write MBR tables over them.

[phoudoin]

Since hrev45192, it should be possible now, right? Can this be closed, then?

[kallisti5]

This still isn't solved as per #10097. While we can overwrite GPT partitions now, we only write a clean partition table to the first 512 bytes. We don't clean up the GPT backup partition table at the end of the disk.

#9489 could also be related.

[siarzhuk]

Can anybody check if the problem can be solved using "writembr" console program? In case that helps - implementing #5980 will fix this one too.

[siarzhuk]

Replying to siarzhuk:

Can anybody check if the problem can be solved using "writembr" console program? In case that helps - implementing #5980 will fix this one too.

I have checked it with USB flash drive - writembr overwrites only first 512 bytes of the disk. To disable GPT bytes in range 512-1024 should be zeroed. After re-plugging the stick - DriveSetup is able to work with Intel map.

[axeld]

As kallisti5 already mentioned: there is a backup GPT header at the end of the disk which has to be cleared as well.

[kushalsingh007]

I will be working on this bug :)

[kallisti5]

This is the final big GPT bug.

At this time, writing an Intel disk system over a GPT disk system results in both disk system in place. (MBR at the front, GPT's backup header at the end). GPT has a higher priority so it gets used.

Here is the result of a GPT disk system created, then an Intel/MBR disk system created over-top of it:

$ gdisk test.img 
GPT fdisk (gdisk) version 0.8.10

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

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 2
Using GPT and creating fresh protective MBR.

Command (? for help): v

No problems found. 204733 free sectors (100.0 MiB) available in 2
segments, the largest of which is 204727 (100.0 MiB) in size.

Command (? for help): p
Disk test.img: 204800 sectors, 100.0 MiB
Logical sector size: 512 bytes
Disk identifier (GUID): 82009838-FFFF-FFFF-3898-0082FFFFFFFF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 204766
Partitions will be aligned on 2048-sector boundaries
Total free space is 204733 sectors (100.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40           67623   33.0 MiB    FFFF  

[kallisti5]

One reason this one is so rough is that we likely need a DiskSystem destroy call added to the API.

Then DriveSetup can call currentDiskSystem->Destroy(); newDiskSystem->Create(Intel) (that's all mumbo-jumbo pseudo code btw :-))

Another option is having Intel/MBR wipe the last block.. but that could have unexpected results like overwriting someones data if they are attempting to reconstruct a partition table.

[bonefish]

Replying to kallisti5:

One reason this one is so rough is that we likely need a DiskSystem destroy call added to the API.

Then DriveSetup can call currentDiskSystem->Destroy(); newDiskSystem->Create(Intel) (that's all mumbo-jumbo pseudo code btw :-))

Most of the required infrastructure is already implemented, with a few pieces missing:

• ​BPartition::Uninitialize(): not implemented yet, but should be straight-forward
• ​BPartition::Delegate::Uninitialize(): looks complete
• ​BMutablePartition::UninitializeContents(): looks complete
• ​DiskDeviceJobGenerator::_GenerateCleanupJobs() and ​DiskDeviceJobGenerator::_GenerateUninitializeJob(): look complete
• ​UninitializeJob::Do(): looks complete
• ​_user_uninitialize_partition(): looks complete
• ​KFileSystem::Uninitialize() and ​KPartitioningSystem::Uninitialize(): look complete
• The uninitialize() hook needs to be implemented for all file and partition system modules. Some (like ​bfs) do that already, but others (like ​gpt) don't.

The stuff up to BMutablePartition::UninitializeContents()) is actually only needed for explicit uninitializing. When initializing a partition already initialized with another disk system the subsequent part should already be executed as a preparatory measure. I believe that's why the bfs module already implements the hook and I'd expect that this part works. So I suppose all that's needed for your use case to work is a proper implementation of the uninitialize() hook in the gpt module.

[kallisti5]

Bumping this to R1B1 milestone and dropping priority of #6452. GPT partitions are really common on new hardware now... and the inability to move from GPT to MBR will result in us having to give "boot to linux and erase last bytes of the disk" instructions to confused an frustrated users.

[pulkomandy]

Agreed, and if the above comments are correct, this one shouldn't be very hard to close.

[pulkomandy]

Fixed in hrev50656.