Transitional motherboards allow a switch to be set for "EFI", "legacy", or "both". The factory setting (on the ones with which I'm familiar, anyway) is "both".
When dual-booting with an o/s that uses MBR, e.g. XP or W7, the installer will default to EFI without looking to see whether there's already an MBR part on the disc.
Then, when the human refuses to let it have the whole disc, it doesn't know how to back up to go down the MBR path. It just hangs in a functionally-choiceless loop, requiring the human to choose between whole-disc and partition, but rejecting partition as a choice.
It should either know how to back up, or know how to avoid getting into that situation in the first place.
There is actually no way around this problem in the installer: FreeBSD can't boot EFI systems from MBR disks, so, as far as the installer is concerned, the system is unbootable without reformatting the disk as GPT.
There are two workarounds available:
1. Booting the installer using CSM (BIOS compatibility mode). It decides what is and is not bootable based on how it was booted (an EFI-booted system can surely be booted by EFI and a BIOS-booted system can surely be booted with the BIOS). If you start the system this way, you can install onto an existing MBR disk and get the right boot loaders.
2. Set up partitions by hand using the manual editor. The installer will complain that the resulting result will be unbootable since it doesn't know if the system supports CSM booting, but it will let you do it if you press OK.
We should add choice (1) to the documentation and improve the error message.
If the installer can't back up because it's really 2 different, dedicated installers, defaulting (currently) to EFI/GPT, would CSM solve the problem of having an MBR disk where the human DOES want to convert it to GPT?
If not, maybe a "pre-installer" is needed that can take a look at the situation and offer choices? E.g.:
"Your disc is MBR and seems to have something on it, perhaps another operating system that you want to dual-boot, or some important data that should not be destroyed. Please choose how to proceed:
[ ] stop the installation now so that you can switch discs.
[ ] keep the MBR partitioning and existing data. Create an additional partition and install FreeBSD into that new partition. [ ] The original partition holds an operating system. Install the FreeBSD boot manager.
[ ] keep the MBR partitioning, but discard the existing data. Re-format the existing partition and install FreeBSD there.
[ ] convert the disc to GPT. This will erase EVERYTHING on the disc, including the MBR partitioning and all the existing data. Then install FreeBSD.
> FreeBSD can't boot EFI systems from MBR disks
I haven't tested with x86 in a while, but we certainly booted arm64 via EFI from MBR-formatted images. I'm not aware of any reason it wouldn't work for x86 too.
(In reply to MMacD from comment #2)
It's one installer, the issue is that it has no idea if the machine has CSM or not. You can't know that unless you booted CSM. You can just boot the install disk that way by telling your BIOS that don't want to do an EFI boot if you don't want EFI boot. We could provide a "This *might* be bootable if you press OK" fallback, but I would prefer just modifying the warning to tell people to disable EFI boot if they don't want EFI boot.
(In reply to Ed Maste from comment #3)
That's interesting. I don't see an obvious point in the history of the EFI loader where that changed (no disklabel support, for example). How have you set up your disks on ARM?
This situation is also a little dubious in that the firmware would probably either see the FreeBSD EFI partition and boot that, giving no opportunity to run any MBR-based boot manager (or Windows), or see the MBR-based boot manager, which would not be able to start FreeBSD through the EFI loader.
(In reply to Nathan Whitehorn from comment #4)
"It's one installer, the issue is that it has no idea if the machine has CSM or not. You can't know that unless you booted CSM. "
I apologise if this is a dopey question, but I've never had occasion to look at specific load-and-go problems. Despite being comfortable with assembly languages, my interests have always been up at the human end (not surprising, perhaps, in someone trained as a psychologist).
My mental model of what's going on is that the bios (or equivalent) spins up the cd drive (or equivalent), loads the primary boot, and jumps to its well-known start address, carrying on from there. I.e., it's at least a somewhat agnostic operation at that point, capable of going down either of two paths.
Why wouldn't that be a good place to add somebody who could take a diagnostic look at the disc and present something like my menu suggestion? Such code would have the same access as any later code for doing low-level reads in aid of figuring out what's on the disc.
Again: apologies if this is a dopey question, and I'd be happy in that case to be clued up if you feel you can take the time.
(In reply to Nathan Whitehorn from comment #4)
> That's interesting. I don't see an obvious point in the history of the EFI
> loader where that changed (no disklabel support, for example). How have you set
> up your disks on ARM?
Ah, interesting -- prior to r302387 (https://reviews.freebsd.org/rS302387) the arm64 memstick images used MBR, but indeed not disklabel.