[lug] Conversion of BIOS Disks to UEFI (non-destructive)

[Orion Poplawski]

On 4/25/19 4:02 PM, D. Stimits wrote:
> This is more or less curiosity (and fun), although I do have a use for this,
> but I am speculating on what might be a means of migrating an old style BIOS
> disk partition scheme into a UEFI scheme without destroying the content. I'm
> thinking it wouldn't be easy, but I'm curious if anyone here might have
> experience with that or just any interesting insight into this brain teaser
> (I'm also thinking of regular mechanical hard drive technology and not
> anything solid state).
> 
> 
> Basically, I know the UEFI partition has a protective MBR as a means of
> preventing some non-UEFI software from destroying a disk it thinks is empty.
> This is good, as it means the front matter of a BIOS disk has the same
> structure (though there might be edits needed to that front matter). There is
> also extra space at the start (beyond the protective MBR) used to hold
> firmware (I'm not sure of the size, but I think it might be roughly 2MB...I
> currently have only old style BIOS and can't look).
> 
> 
> So task one would be to take all of the existing partitions, perhaps via an
> interactive BIOS style disk tool, and reduce the free space in various
> partitions. That space would eventually end up between the boot area and the
> first partition in order to hold any firmware. Once partitions have been
> reduced in size the difficult part would be to move them towards the end of
> the disk, and away from the front of the disk.
> 
> 
> To move away from the front of the disk I'm thinking that if the first
> partition is small enough after resizing, then perhaps there is a way to
> create a new partition with that space. Then dd the content of that first
> partition into the free space. Finally, delete the original partition which
> was next to the boot area.
> 
> 
> Now if one has a UEFI partitioned disk of the exact layout of the existing
> BIOS disk in terms of partition size and order, maybe it would be possible to
> dd the very start of the disk from boot records through the firmware to the
> beginning of the disk and have it "just work". This would depend on the
> partition boundaries in the original disk matching where the boundaries are
> from the dd source UEFI disk. I don't know if there is a difference in
> something like a partition boot record which would make this fail.
> 
> 
> If anyone has any thoughts on whether this would work or not (and again this
> is just for fun) I'm curious if anyone here thinks one could do some trickery
> and non-destructively convert a BIOS partition style disk into a UEFI style
> partitioned disk.


I'm pretty sure gdisk will do the conversion - and will warn you if you don't
have enough space (at the front AND at the back for the secondary GPT), e.g.:


# gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.10

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


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.

Command (? for help): ?


Once you've resized the partitions you can use the w command to write the new
GPT partition tables out.



-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20190426/03d9965a/attachment.bin>