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

[D. Stimits]

Excellent...didn't know about gdisk abilities.


There is still one possible issue (I'm just wondering about this as a puzzle, not so much for practical use): When a GPT partition scheme disk is used as a boot disk there is extra firmware or boot support added to the front of the disk. Does converting to GPT reserve that space for making the disk bootable? Or would one still need to make further movements of partitions to allow room at the start of the disk?

> On April 26, 2019 at 1:44 PM Orion Poplawski <orion at nwra.com mailto:orion at nwra.com > wrote:
> 
> 
>     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 mailto:orion at nwra.com
>     Boulder, CO 80301 https://www.nwra.com/
> 
>     _______________________________________________
>     Web Page: http://lug.boulder.co.us
>     Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>     Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20190426/a6335663/attachment.html>