Is it a requirement for a drive to use GPT partition table if wanted use UEFI boot? Or is it still possible to use MBR partition table as format for drive's partitions and have bootloader saved in a separated EFI partition?
As I understand for now, MBR contains both, information about drive's partitions and boot loader. But UEFI firmware requires boot loader to be placed in separated EFI (FAT32) partition. So if UEFI firmware supports MBR format as a format for drive's partitions, everything should be ok, am I correct?
UPDATE:
Background: I have single Xubuntu 14.04 installation on SSD drive, currently it's using BIOS boot with MBR partition table type. I'd like to convert to UEFI boot, I'm wondering if it's possible to continue to safely use MBR as partition table type with separated EFI partition created for boot loader.
I'm familiar with BIOS-UEFI conversation process.
Thank you for your answers!
It's theoretically possible to use an MBR partition table in an EFI-mode boot; however, almost nobody does this, so it's poorly tested. Also, in my own (brief) tests with this method, it seems to produce more problems related to boot loader naming and NVRAM entries (as managed by efibootmgr in Ubuntu). Thus, it's not something I recommend. The saying "if it ain't broke, don't fix it" probably applies to your case -- you say you'd "like" to convert to EFI-mode booting, but you've provided no reason for this. In the absence of such a reason, I'd say it's inadvisable to do the conversion, since nothing's "broke."
Also, if you set up an EFI-mode boot from an MBR disk, I can't promise that future Ubuntu updates will like it. It's conceivable that the Ubuntu installer or update process would choke, possibly creating serious problems down the line. OTOH, it all might go just fine. That's part of why "untested" in this context translates to "you probably don't want to try this" -- there are just too many unknowns, both now and in the future.
That said, if you must do such a conversion, you can certainly try it with an MBR partition table. If you run into problems with NVRAM entries not "taking," you should then do an MBR-to-GPT conversion. Alternatively, you can just plan to do the conversion from the start. See my Web page on the subject for details. Note that partition table data structures are actually quite simple, and the conversion requires no changes to filesystems. Thus, the odds of a catastrophic failure are quite low. If you use gdisk, a problem is most likely to turn up when the program loads the MBR data structures and converts in memory to GPT. At this point, you'll be warned, or at least be told of the problem if you do a disk verification (v in the main menu), so you can abort the operation before writing anything back to disk. OTOH, no partitioning operation is entirely risk-free, and if a problem does occur, it can be catastrophic, so having backups is wise.
No comments:
Post a Comment