MBR to GPT error code 215

Comments

• PB442

  January 2023

  emoji should be D :  drive designation
• PB442

  January 2023

  Further to my post the logs for mgr2gpt show it fails when it cannot get volume name for the recovery boot entry. See excerpt below, (NB: I have not used the real object ID string below):

  
  

  2023-01-08 14:56:07, Info BCD: Opening object {f7942351-391b-12e2-af13-ce8d487bae14}

  2023-01-08 14:56:07, Error GetOSDeviceVolume: Cannot get device data for entry. Error: 0xC0000024[gle=0xc0000024]

  2023-01-08 14:56:07, Error FindOSPartitions: Cannot get volume name for the recovery boot entry. Error: 0xC0000024[gle=0xc0000024]

  2023-01-08 14:56:07, Error Cannot find OS partition(s) for disk 0[gle=0xc0000024]
• admin

  January 2023

  @PB442, For SSD, it still has fragments. Only the fragments haven't affected on reading files. But, when there are too many fragments, it will affect the operations of our software. You can use AOMEI Partition Assistant to defragment for the disk, and then convert it again.
• PB442

  January 2023

  Thank you for the response.  It would appear AOMEI is assessing my drive as though it uses movable heads to read spinning magnetised platters.  This seems outdated when many system disks these days are SSDs, and most new systems ship with SSDs.
  
  I note the advice on defragging an SSD from the maker of the SSD I am using is:
  

  Should I defrag my SSD?

  The short answer is this: you don't have to defrag an SSD.

  To understand why, we first need to look at the purpose of defragmenting a drive. Defragging ensures that large files are stored in one continuous area of a hard disk drive so that the file can be read in one go. Mechanical drives have a relatively long seek time of approximately 15ms, so every time a file is fragmented you lose 15ms finding the next one. This really adds up when reading lots of different files split into lots of different fragments.
  
  However, this isn't an issue with SSDs because the seek time are about 0.1ms. You won’t really notice the benefit of defragged files — which means there is no performance advantage to defragging an SSD.

  SSDs move data that's already on your disk to other places on your disk, often sticking it at a temporary position first. That's what gives defragmenting a disadvantage for SSD users. You’re writing data you already have, which uses up some of the NAND's limited rewrite capability. So, you get no performance advantage whatsoever, but you are using up some of the limited rewrite capability.
  

  To summarize, do not defrag an SSD

  The answer is short and simple — do not defrag a solid state drive. At best it won't do anything, at worst it does nothing for your performance and you will use up write cycles. If you have done it a few times, it isn't going to cause you much trouble or harm your SSD. You just don’t want this to be a scheduled, weekly type thing that takes away from the finite number of SSD rewrites. There are other ways to clean up and increase speed on your computer. There are even reasons for formatting an SSD, encrypting SSDs, and ways to increase storage space on a SSD. They all serve a purpose — there just isn’t a reason to defrag an SSD.

  
  
• PB442

  January 2023

  AOMEI Parition Assitant Pro detects that the partition is on a SSD and also recommends against defragging a SSD!
  
  
  
  Even so, on the assumption AOMEI conversion to GPT cant deal with an overly fragmented disk, SSD or not, I defragged the system partition on my SSD :-(, sufficiently to reduce AOMEI report of fragmentation from 49% to 25%.   
  
  
  
  Then I attempted the conversion to GPT again.  Sure enough I still got error 215.  So I dont think fragmentation is the problem despite the error description leading with that.
  
  
  
  And as to free space, there is plenty in each partition and even more unalloacted on the disk
  
  
  So it seems to me that whatever the problem is, it is not what is reported in the error 215 Information dialog.
• PB442

  January 2023

  So, digging into the logs, the  only line I can find that appears to show a problem is:
  
  [21      ][2023-01-13 01:32:18] disk.cpp(257): Failed to IOCTL_DISK_GET_DRIVE_GEOMETRY. Disk Index: 1
  
  Anyone know what that means, and what needs to be done to fix the problem?
• PB442

  February 10

  So a year and a bit later I came back to the problem with more time to sort it out, and succeeded.  The short version is that Recovery was not properly set up, missing both WinRE.wim and once that was copied in, needing to be enabled (using reagentc enable).  Once both were done, MBR2GPT /validate /disk:0 /AllowFullOS ran successfully instead of reporting an error. I then ran MBR2GPT /convert /disk:0 /AllowFullOS  successfully, converting the drive to GPT successfully.  I then edited the BIOS setup to disable legacy and enable secure boot.  Then restarted and hoped it worked.  It did. I then used AOMEI to expand the C: drive from 2TB (with just 92 GB free) to 3.7TB  (with 1.8TB free) which was the reason I started on this whole exercise last year - to be able to use all of a new 4TB SSD.  The reported error mentioned above when trying to convert to GPT using AOMEI was disk fragmentation, which didn't make sense to me on an SSD, and indeed wasn't the problem.
  
  The longer version is I spent a bit of time chasing dead ends using diskpart, and boot configuration, but I'll spare you those. 
  
  Posting this because it may be of use to someone else facing a similar problem.
  
  So to be clear, I now have a 2011 HP desktop with a Foxconn 2ADA motherboard and an i7-3770 processor happily running Windows 10 and UEFI/GPT without having to do a clean (re)install of the OS. (NB I had previously successfully upgraded the AMI BIOS to a a version beginning with 8 back in 2015 - I think at the time to run a new NVIDIA graphics card.  This was successful and that version of the BIOS had the option for UEFI/secure boot - the original BIOS did not).
  
  Thanks to all who tried to help early last year, and hope this is of use to someone else.