I have a HP Envy 700-215xt, with UEFI, and WIndows 7 on it's original 1 TB drive. I've added a 2 TB internal drive, initialized as GPT, and installed Fedora 22 on it's first 500 GB. The UEFI boot order is set to boot to Grub2 on the second drive, which lists Fedora and Windows 7 in it's boot menu. This setup works fine so far.

I have an "Anker" hard drive docking station (which has it's own power supply) connected by an eSATA cable and an adapter to the one remaining SATA connector on the IPM87-MP mobo, and with a 2 TB WD SATA drive installed in the docking station, with the intention of installing a bootable Ubuntu 16.04 on its first terabyte.

My first question is, should the new drive be initialized as GPT as well? It should work for that drive, but if I was to get another drive later and want to use that in the same docking station, is there a possibility of a GUID conflict when UEFI's boot manager tries to boot the same entry for the docking station?

Secondly, if there is a possible conflict in the above scenario, will initializing the drive as MBR prevent such a conflict and allow installation of Ubuntu normally, and for it to show up in the Fedora's boot menu by using Fedora's grub2-mkconfig, and still be able to later install another new drive in the docking station, without any UEFI/GUID conflict?

Thanks in advance,



I recommend using GPT. If the installation creates an entry in the EFI's NVRAM, that entry may or may not survive unplugging the eSATA disk. This is true whether the disk uses MBR or GPT -- that is, it's throwing the dice either way. If you don't intend to boot the eSATA disk on another computer, it might be better to proceed as follows:

  1. Boot the Ubuntu installer in its "try before installing" mode.
  2. Launch a Terminal window.
  3. Type ubiquity -b in the Terminal window. This launches the Ubuntu installer, but -b tells it to not install GRUB.
  4. When you're done, reboot into Fedora and tell it to update its GRUB configuration. (IIRC, grub-mkconfig -o /boot/efi/EFI/fedora/grub.cfg is how you'd do this in Fedora.)

This procedure will cause Fedora's GRUB to retain control of the boot process, and to add an Ubuntu entry to it, rather than have two different GRUBs installed, and possibly battling for status as the GRUB that controls the boot process.

Alternatively, instead of step #4, you could boot into Fedora and install my rEFInd boot manager, which would then take over the role of the program that manages the boot process. rEFInd tends to be a little easier to maintain if you're dual-booting two different Linux distributions.

Note that GPT disks use several GUIDs -- one for the disk itself, one for each partition, and GUIDs used as type codes to identify partitions' intended uses. The first two of those should be unique for each disk and partition, so as to avoid the sorts of conflicts you seem to be concerned about. Unless you do a low-level copy or clone of a disk (and maybe not even then, depending on the software you use and the procedure you follow), two disks should not have shared GUIDs.

| improve this answer | |
  • Thanks for the feedback, Rod. I was concerned about the GUIDs for each disk. Since each disk and each of its partitions will be assigned unique GUIDs, each new disk that is inserted into the hard disk docking station will have its own unique set of GUIDs. Will this prevent more than the first disk from being booted cleanly under UEFI/GPT, since their GUIDs are different from those of the first disk? If the above is the case, will initializing all the disks used via the docking station as MBR prevent such GUID conflict/boot problems? – Naturelover May 7 '16 at 4:18
  • Please re-read the first paragraph of my answer. – Rod Smith May 9 '16 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.