Clean Up Unneeded EFI Partitions?

S

sackadoo

I’m getting ready to install a FreeBSD-derived OS (Trident) as the 3rd OS on my laptop (Windows 10 and Linux being the others which are already installed). I also posted this question on the TrueOS forum, but so far no one has responded, so I thought it might be best to go to the horse's mouth as it were.

History

A quick note: I don't know how the drive names translate into FreeBSD speak, so rather than guess and stir up confusion, I'm going to refer to them by their Linux names. Hope that's okay.

Originally, this laptop came with one internal HDD, but I've gradually changed the hardware and OS installations over the last two months like this:
  • sdc was the original drive,
  • added sdb, installed Windows and Linux on it, scraped sdc clean and reformatted it as a shared home/data drive,
  • added sdd, moved Windows to it,
  • added sda, installed Linux there, leaving enough room for a FreeBSD install.

Which is how I came to be in the mess I'm in as can be seen from the fdisk output below.

Also, I have to hit F11 each time I reboot in order to get to the (I think it's) GRUB boot menu.

Part of my concern is that I have no idea where the Windows boot loader is. I'm guessing it's on one of the Microsoft reserved partitions:
  • sdb1,
  • sdc3, or
  • sdd3.
If I don't intervene by hitting F11 on start-up, Windows jumps in and hogs the machine.

And to add to my confusion, I don't know where the Linux boot loader is. It has to be one of:
  • sdc2, or
  • sdd2.

The Laptop

MSI GE72 2QF Apache Pro
UEFI/BIOS
(4) internal drives, (1) HDD, (3) SSDs
(2) external Samsung monitors (designer rez)

I worked out how to deal with the external monitors in Linux, so I'm assuming the same tools will serve the same purposes in FreeBSD and its offspring.

What I'm Planning

In preparation for installing FreeBSD -> Trident, I’d like to clean up some of the extraeous partitions scattered across the four drives in my machine. The objective being to end up with a single EFI boot partition, preferably on sda, that will allow me to boot Trident, Linux, or Windows.

I’ve included the output of fdisk -l below and the way I’m reading it, these are the partitions that I should be able to delete safely (in the fdisk output, I've formatted these as bold-italic to make them stand out):
  • /dev/sdb1 (Microsoft reserved)
  • /dev/sdc2 (EFI System)
  • /dev/sdc3 (Microsoft reserved)
  • /dev/sdd1 (Windows recovery environment)
  • /dev/sdd2 (EFI System)
  • /dev/sdd3 (Microsoft reserved)

However, I’m not sure which EFI partition is used by GRUB (or whatever boot loader Mint installed). It’s been far too long since I dug into this stuff and all this UEFI/EFI stuff is new to me.

Questions

  1. Am I right in thinking I can delete all of the above partitions?
  2. If not, which ones do I need to keep?
  3. What's the best tool to do this partition shuffling? (Please keep in mind that I'm an artist/technical writer, mostly a Windows user for the last 10 years with modest experience in BSD and Linux, with general computer experience going back to 1985. In short, I'm not a complete noob, but I haven't exactly been keeping up with recent developments in drive technology.)
  4. Is it possible to resize and move (if necessary) the Linux OS partition (sda1) to make room for an EFI partition without having to reinstall Linux?
  5. Where is the best place to put an EFI boot partition?
  6. Should I figure out which of the two existing ones is actually being used by GRUB (or whatever that boot loader is) and leave it there? If so, how do I wrench control away from the Windows boot loader on either sdb1, sdc3, or sdd3, if indeed one of those is a Windows boot partition?
  7. Or am I asking all the wrong questions?
Other Notes:
  • /dev/mmcblk0 is a USB stick I had plugged in when I ran fdisk
  • /dev/sde is an external drive and can be ignored for this scenario
  • /dev/loop0 and /dev/loop1 - I have no idea what these are.
Output from fdisk -l:

Disk /dev/loop0: 127.4 MiB, 133599232 bytes, 260936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop1: 91 MiB, 95416320 bytes, 186360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 8BA2E69A-E663-49CB-8191-57C60C57BA7B

Device Start End Sectors Size Type
/dev/sda1 2048 244140031 244137984 116.4G Linux filesystem

Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 200826CF-47D7-46DE-AF6E-94BBE40EF0F0

Device Start End Sectors Size Type
/dev/sdb1 34 32767 32734 16M Microsoft reserved
/dev/sdb2 32768 976771071 976738304 465.8G Microsoft basic data

Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 91777562-C427-4D61-B439-084A12E5B5B5

Device Start End Sectors Size Type
/dev/sdc1 2048 1023999 1021952 499M Windows recovery environment
/dev/sdc2 1024000 1228799 204800 100M EFI System
/dev/sdc3 1228800 1261567 32768 16M Microsoft reserved
/dev/sdc4 1261568 1953523711 1952262144 930.9G Microsoft basic data

Disk /dev/sdd: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 41AFA081-709E-4EF9-B34B-F38815D32746

Device Start End Sectors Size Type
/dev/sdd1 16191 208844 192654 94.1M Windows recovery environment
/dev/sdd2 208971 369494 160524 78.4M EFI System
/dev/sdd3 369621 402388 32768 16M Microsoft reserved
/dev/sdd4 417816 468857024 468439209 223.4G Microsoft basic data

Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc99186e7

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 2048 124735487 124733440 59.5G 83 Linux

Disk /dev/sde: 1.8 TiB, 2000396746752 bytes, 3907024896 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x006d81ce

Device Boot Start End Sectors Size Id Type
/dev/sde1 * 2048 3907024895 3907022848 1.8T 7 HPFS/NTFS/exFAT
 
I think the problem is that there isn't actually a FreeBSD question in there. You are really at the point of needing partitioning help and GRUB help at this point. Maybe ask this first at Linuxquestions.org?
 
sackadoo said:
Also, I have to hit F11 each time I reboot in order to get to the (I think it's) GRUB boot menu.

Part of my concern is that I have no idea where the Windows boot loader is. I'm guessing it's on one of the Microsoft reserved partitions:
  • sdb1,
  • sdc3, or
  • sdd3.
Click to expand...

You have to see if you're booting in BIOS legacy mode or in UEFI mode. I believe Windows 10 boots only in UEFI mode so your boot mode is probably UEFI.

So for UEFI boot what happens, there is a special area on the motherboard called NVRAM. it contains the currently "active" boot entries that you can select. This is where your computer starts booting.
Each entry is located somewhere on a drive in its ESP (EFI system partition) and it's a .EFI file with the bootstrap code for the bootloader. Windows has such .EFI file, but also GRUB or whatever boot loader you are using with FreeBSD. It can be located for example in \EFI\grub\grubx64.efi or whatever, just see what your EFI system partitions contain.

From your FreeBSD or from GNU/Linux you can show the current settings of the NVRAM with the program efibootmgr:

efibootmgr -v

There is a default one (not necessarily the first one in the list, I believe, but rather with the lowest index), so you have to set for example GRUB to be the default entry and you will be able to boot from GRUB always. Changing the NVRAM can also be done with the program efibootmgr, just search for examples.

UEFI boot: how does that actually work, then?

It's AdamW Essay Time again! If you're looking for something short and snappy, look elsewhere. Kamil Paral kindly informs me I'm a chronic sufferer of Graphomania. Always nice to know what's wrong wit
www.happyassassin.net

Then in your GRUB configuration you can use chainload rule to load Windows, your standard GNU/Linux kernel and FreeBSD. But for the FreeBSD I have not done it, you will probably need GRUB's ZFS module if you use ZFS with your FreeBSD.

Regarding the location of the Windows bootloader, my information is a bit old, but it probably has not change a lot.
Normally the Windows firmware from the EFI partition loads the "ntloader" located in your Windows system partition and then the ntloader kicks off the boot process. Windows 10 should not be any different:
amigotechnotes.wordpress.com

Boot Process in Windows and Linux with BIOS or UEFI

I still have many questions about the boot process. There are still many things confusing me, especially with UEFI. Here is what I understand and summarized:
amigotechnotes.wordpress.com amigotechnotes.wordpress.com

And last point - I am not sure if you need an ESP on each drive. Just take a look into the UEFI documentation, but I think it should be possible to use a single ESP for all the drives. I have never used it though, I boot in legacy mode, cause it's simpler.
 
sackadoo said:
Am I right in thinking I can delete all of the above partitions?
If not, which ones do I need to keep?
What's the best tool to do this partition shuffling? (Please keep in mind that I'm an artist/technical writer, mostly a Windows user for the last 10 years with modest experience in BSD and Linux, with general computer experience going back to 1985. In short, I'm not a complete noob, but I haven't exactly been keeping up with recent developments in drive technology.)
Is it possible to resize and move (if necessary) the Linux OS partition (sda1) to make room for an EFI partition without having to reinstall Linux?
Where is the best place to put an EFI boot partition?
Should I figure out which of the two existing ones is actually being used by GRUB (or whatever that boot loader is) and leave it there? If so, how do I wrench control away from the Windows boot loader on either sdb1, sdc3, or sdd3, if indeed one of those is a Windows boot partition?
Or am I asking all the wrong questions?
Click to expand...

I couldn't directly answer any of these questions because I've never attempted to do things this way. I studied the problem first, and then installed FreeBSD and Linux Mint from scratch. It took 2 or 3 tries, all the while tolerating the risk that I might accidentally delete the Windows installation, which was the only thing I couldn't easily redo. You appear to have two Windows installations, and your unnamed Linux distro on /dev/sda looks unusual in that it doesn't appear to have an EFI partition of its own. If this were my machine, I would copy everything of value from /dev/sda1 onto your general purpose NTFS partition on /dev/sde1 using tar to preserve permissions and user settings, and then reinstall the GNU/Linux distro from scratch, using manual partitioning on both GNU and FreeBSD (or Trident) to create the EFI partitions, but that's just what I would do, and you must do as you see fit. I would do it that way because I'm always prepared to do disaster recovery, and by disposition, I prefer installing things from scratch over introducing new uncertainties in configurations that are already uncertain.

Reading over your post again, I think the boot menu you see when you press F11 is probably the firmware's boot menu, and not the Grub boot menu.

I once had a UEFI-capable machine with a multiple boot configuration. It was an Acer Aspire laptop with only a single 1TB drive. After resizing my Windows install to use only half the drive, I installed FreeBSD and then Linux Mint, and wrote down the initial GPT partition layout in my notes:
Code: 
        Partition table
          Slice            Description             Mount pt.?        Comment
        ada0              932 GB GPT                                 The 1TB drive
          ada0p1        100 MB efi                                   Windows boot partition
          ada0p2        16 MB  ms-reserved                           Windows 10, ?
          ada0p3        474 GB ms-basic-data                         Windows 10 data
          ada0p4        1.0 GB ms-recovery                           Windows 10 recovery
          ada0p5        200 MB efi                                   FreeBSD 11.2 boot partition
          ada0p6        12 GB freebsd-swap        none               (no mount point)
          ada0p7        215 GB freebsd-ufs          /                (mount point for root filesys)
          ada0p8        488 MB efi                                   Linux Mint 11 boot partition
          ada0p9        11 GB linux-swap                             Linux Mint swap
          ada0p10       217 GB linux-data                            Linux Mint data
When I struck one of the function keys (I don't remember which one) during the initial boot process, I saw 3 different entries in the firmware's boot menu, which I believe corresponded to the 3 EFI partitions on ada0p1, ada0p5, and ada0p8. Selecting the first entry would boot Windows 10, the 2nd entry would boot FreeBSD, and the 3rd would boot Linux Mint. I wouldn't see the GRUB boot menu until I selected the 3rd entry to boot Linux Mint.

The GRUB boot menu had entries to boot Linux Mint or Windows, but had no entry to boot FreeBSD until I customized it. After customizing it, I changed the firmware options to automatically boot Linux Mint, so it would go directly to the GRUB menu at bootup time.

To customize the grub menu, I added an entry like this to /etc/grub.d/40_custom on the Linux Mint system as root ( sudo su -), and then entered the command update-grub and allowed it to complete before rebooting the system:
Code: 
    menuentry "FreeBSD11.2" {
      insmod ufs2
      root=(hd0,gpt7)
      chainloader /boot/loader.efi
    }
Using chainloader might not be the best way of doing it, but it works. Hope this helps. Also hoping the forum admins will forgive us both, since we are both really pushing the envelope here, but I just wanted to try to clarify some of this, because, even at it's best, multi-booting different operating systems on the same hardware is a very confusing topic, and I'm not the only FreeBSD user who does it. or who tries to do it through trial-and-error, or who reads this forum and might be terribly confused by this thread.
 
Thanks but that wouldn't help with my present configuration which doesn't have Windows, and I'm predisposed against relying on Windows for anything in any case. The nice thing about UEFI is that all you really need is a decent firmware. Installing grub isn't really necessary because the boot menu will let you boot any system which is installed with its own EFI partition, and the firmware setup will let you specify the boot order and choose which partition is booted (first/always).

It's also important in either case to switch off the legacy boot mode before installing the OS, so that the EFI system partition will be created. It looks like sackadoo may have installed his GNU/Linux drive using legacy boot mode -- otherwise, if I'm not mistaken, he should have had an EFI partition installed for it by whatever GNU installer software he's using.
 
Vull said:
Thanks but that wouldn't help with my present configuration which doesn't have Windows, and I'm predisposed against relying on Windows for anything in any case. The nice thing about UEFI is that all you really need is a decent firmware. Installing grub isn't really necessary because the boot menu will let you boot any system which is installed with its own EFI partition, and the firmware setup will let you specify the boot order and choose which partition is booted (first/always).
Click to expand...
Grub's job is not only to do the menu selection, most importantly - it loads the kernel. It's true that it's not necessary to have exactly grub, but at least some boot loader must be there.
I use for example FreeBSD's own boot manager that installs in a separate 512k big partition. I guess, from the EFI program on the ESP the control goes to the freebsd-boot partition and then it loads the kernel from the bootpool (when using ZFS).
For the GNU/Linux OS, one can use grub, LILO, syslinux, refind or whatever other boot managers are available. Grub can also understand ZFS and I think one can boot FreeBSD with grub.
For Windows - it's the NTLDR or for the newer ones Winload.exe.
 
roccobaroccoSC said:
Grub's job is not only to do the menu selection, most importantly - it loads the kernel. It's true that it's not necessary to have exactly grub, but at least some boot loader must be there.
I use for example FreeBSD's own boot manager that installs in a separate 512k big partition. I guess, from the EFI program on the ESP the control goes to the freebsd-boot partition and then it loads the kernel from the bootpool (when using ZFS).
For the GNU/Linux OS, one can use grub, LILO, syslinux, refind or whatever other boot managers are available. Grub can also understand ZFS and I think one can boot FreeBSD with grub.
For Windows - it's the NTLDR or for the newer ones Winload.exe.
Click to expand...
Thanks for the correction. In my example, grub was used to boot the Linux Mint system, but wasn't needed to boot FreeBSD or Windows 10 in a UEFI configuration. In an MBR booting scheme, the situation is slightly different, although in appearance it looks very similar, and this was a source of considerable confusion for me, as I think it probably is for a lot of people. The system I'm using presently is not capable of UEFI booting, although it is capable of MBR booting from a GPT partition table, which, as I understand it, is a fairly common situation for a lot of the older hardware. Unlike the situation with an MBR/MS-DOS partition table, with a GPT table it's possible to have more than one MBR or Master Boot Record. For each FreeBSD system on a GPT drive, the freebsd-boot partition serves as a substitute for the MBR and not as a substitute for an EFI partition. My present configuration uses a freebsd-boot partition instead of an EFI system partition for booting FreeBSD, where the freebsd-boot partition serves the function of the old MBR. The first 5 partitions (FreeBSD slices) are configured like this:
Code: 
ada0      932GB GPT
  ada0p1 freebsd-boot  512K
  ada0p2 freebsd-ufs     100G
  ada0p3 freebsd-swap   5.8G
  ada0p4 linux-data        100G
  ada0p5 linux-swap        6.0G
Here I installed FreeBSD first and GNU/Linux second. After installing the GNU system, I could boot the GNU system from the grub menu, but my FreeBSD system was no longer bootable (since this machine lacks the UEFI firmware which could otherwise have been used to boot it, and because grub doesn't recognize or support FreeBSD systems without special configuration).

So, unlike with UEFI, I needed some kind of substitute boot loader to boot FreeBSD, and I used grub since it was already there. Also, the grub "menuentry" for FreeBSD has to be a little bit different:
Code: 
menuentry "FreeBSD 12.0-RELEASE (dell) /dev/sda2" {
  insmod ufs2
  set root=(hd0,gpt2)
  kfreebsd /boot/loader
}
... and the freebsd-boot partition is only 512K, as opposed to the 200MB used for FreeBSD's EFI partition in the UEFI-capable configuration. My original misunderstanding came from equating freebsd-boot with EFI partitions, but they are not the same thing, nor do they serve the same function.
 
I feel you, my worries exactly. I think UEFI is broken from the beginning as a standard. They married it to Microsoft so now the whole world needs to kiss their rear ends to be able to boot anything. Because, to be serious - who will tinker with the trusted certificates in their BIOS as an end user besides a couple of hackers? It's extremely user unfriendly! In the browsers they solved the issue like a trillion years ago.
That's probably the reason why so many people just do legacy boot and still use GPT as you mention.

I personally spare myself the complexity of multiboot. I install one OS per machine.
I also think a more flexible option for multiple OSes on a machine is to just use VMs.
 
I like UEFI just fine but it's a no-go on this machine. Don't care too much about secure boot either way. I've used multi-boot for my development machines and toys for decades now, and have always been quite comfortable with it once I got my ducks in a row. Certainly wouldn't recommend it for anything more critical than development or play-toys, since it can only run one OS at a time. Due perhaps to the anachronistic nature of my experience, multi-boot seems less complicated than VM to me. Bare metal keeps my resource needs low and allows me to recycle old hardware. My resource usage and carbon footprint are both quite low, and for what little I do with it, I'm happy enough to keep it that way.
 
Hi guys. I`m new in this forum and newest in BSD but I can help.

See here ==> file:///media/ada2s1/Sistemas%20Operacionais/Como%20remover%20entradas%20de%20boot%20UEFI%20obsoletas%20no%20Linux%20-%204Fasters.html

I just did this in my Ghost and it works.

My first help, u-hu
 
lcquerido said:
Hi guys. I`m new in this forum and newest in BSD but I can help.

See here ==> file:///media/ada2s1/Sistemas%20Operacionais/Como%20remover%20entradas%20de%20boot%20UEFI%20obsoletas%20no%20Linux%20-%204Fasters.html

I just did this in my Ghost and it works.

My first help, u-hu
Click to expand...
I don't think anyone here will be able to acess your harddrive to read this file.
 
My ad hoc, trial and error approach to this has had its pitfalls. A lot of this seems to depend on the UEFI firmware implemenation particular to one's host. I "got away with" having multiple EFI partitions per drive for a while, but can't recommend it, and now avoid doing it. The UEFI specifications only specify having ONE EFI partition per drive. Having more than one will likely confuse the firmware on a lot of machines, like, for instance, the Lenova laptop I'm using right now.

This machine has one EFI partition which can boot 4 different operating systems. Windows and FreeBSD can be rebooted using this single EFI partition and the firmware's setup program, and that seems completely independent of whatever I do with my grub configurations.

As I stated above, I only play games like this on development machines, which I regard as play-toys. I take notes, make backup copies, and make it a point to avoid doing any configuration work which can not be easily duplicated later. On live production systems, my best advice is to limit yourself to one operating system per machine. What would be the point of doing otherwise? Only one OS can be running at a time on any multi-boot system.

Always plan for the worst case, and prepare adequate backup and recovery strategies in case something fails. Thanks.
 
I suspect that the person with the original problem has been helped or gave up--TridentBSD is defunct, for one thing. Note that this is over a three year old thread (and yeah, I've posted to old threads too, not noticing.)

Not to say that the answers aren't useful for those dualbooting FreeBSD and Linux, but just note that the original thread is from March, 2019, (and appears as if it may have been in two places on the forum, judging from some of the original answers).

My own solution for UEFI with FreeBSD and Linux has been to use patovm04's tutorial, where they create a ZFS partition on a drive that has otherwise had Linux. Their solutions have worked for me.
forums.freebsd.org

[UEFI/GPT] [Dual-Boot] How to install FreeBSD (with ZFS) alongside another OS (sharing the same disk)

Important notes: 1) This tutorial assumes you have the OS you want to dual-boot with already installed on your drive, and that you already have freed up some disk space. Essentially, you will be installing FreeBSD with root-on-ZFS on the remaining free space of the disk, instead of using the...
forums.freebsd.org forums.freebsd.org
 
You must log in or register to reply here.
Back
Top