I have one SSD and one HDD in my computer.
I use the SSD as the drive which holds the OSes (Ubuntu and Windows).
I installed them on my SSD in BIOS/legacy mode (MBR format) and I still have an ESP on my HDD where I had the OSes before, is it safe to remove it? Will it cause any issues with other partitions on the HDD? I'm only using the HDD as a data disk.


It should be safe, but if you want to be absolutely sure, temporarily comment out any /etc/fstab entries referring to the data disk in Ubuntu, shutdown your system, temporarily unplug the data cable from the HDD and then verify your OSes are still bootable. If both OSes still boot just fine, then you can be absolutely sure the ESP can be removed. If there are problems, just plug the data cable back in.

After testing, remember to uncomment the /etc/fstab entries in Ubuntu you did comment out at the start.

If your system is really booting in legacy mode, then the ESP partition should absolutely be not a factor: it is essentially just a plain FAT32 partition in a GPT-partitioned disk with a specific partition type UUID.

In theory, an UEFI-capable system could be configured to first read an UEFI driver from ESP on one disk, and then start up a legacy compatibility layer to boot in legacy BIOS mode from another disk the UEFI firmware cannot directly access without the driver; but that would be a very special configuration and I don't think most UEFI firmwares allow that kind of configuration to happen. So if you had such a special configuration, you would probably already be aware of more details of that specific UEFI implementation than possibly anyone else outside the engineering team that developed the system/motherboard.

Removing the ESP may or may not affect the partition numbering, depending on whether the tool you use for the removal just marks the ESP's slot in the GPT partition table as unused or completely rebuilds the GPT partition table. In practice, it means if you're referring to the partitions on the HDD by the /dev/sd* device name in Ubuntu, you may have to adjust the partition number(s) for that disk by one. If you're using volume labels or UUIDs to identify the partitions in Ubuntu's /etc/fstab, you don't have to do anything in any case.

  • I'm also planning to reinstall my SSD OSes in UEFI mode with GPT partition table. Also by rebuilding the GPT partition table could it cause problems with the other partitions? (I might remove it through Windows' partitioning tool or maybe GParted) – XxMoNsTeR Mar 31 '18 at 14:31
  • If you remove partition /dev/sdX1, then /dev/sdX2 might or might not become the new /dev/sdX1 depending on how the tool is designed to do the removal operation. But if it causes any other "problems with the other partitions", then the partitioning tool is definitely broken. – telcoM Mar 31 '18 at 14:49
  • Maybe I should not remove the ESP after all, the problem is it's in between two partitions which I could make into one partition, I also have some 1MB small partition after the ESP that Ubuntu's Disks tool detects it as BIOS Boot partition type, I'm not sure what that is though. I guess I'll stay with the separated data partitions and only remove the ESP when I'll be formatting the whole hard drive. – XxMoNsTeR Mar 31 '18 at 15:04
  • 1
    The "BIOS Boot Partition" is a partition that allows (some implementations of) UEFI systems to boot in a legacy style on GPT-partitioned disks. The legacy MBR style allowed embedding of a bootloader after the MBR block but before the beginning of the first partition, but GPT has no such free space. So when a legacy MBR bootloader is used on a GPT-formatted disk, the BIOS Boot Partition is used to store the bootloader instead. – telcoM Mar 31 '18 at 15:53
  • You generally don't want to place ESP and rootfs on different physical drives as it makes your system dependent on one more device for no good reason. – Michael Shigorin Apr 1 '18 at 14:18

Depending on what you have on the HDD, the easiest way to check is to just disconnect it and see if all your OSes boot without issue.

Removing ESP (as in, deleting the partition from the table and not creating a new one) has 2 primary effects:

  1. data on the partition is lost
  2. partition numbering on that disk will shift

Before moving on, check if all you OSes boot in BIOS/Legacy mode.

To safeguard for (1), check your Linux/*nix OSes if they're not using the partition for something (/boot or whatever), in fstab.

For (2) - do you have any OSes left on the GPT disk? If so, you might want to check how your bootloader finds the right partition on that disk. I'm not aware of any Linux distro that has configured GRUB to find the right partition via number - all should use UUID, it may be different for other OSes (I think UUID-based partition referencing only landed in Windows 8, not sure though). If you're mounting any of the partitions on the HDD in Linux/*nix, check your fstab entries if you're using UUID or some other number-agnostic method, otherwise your mounts will break.

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.