Looking to add 3rd OS to my desktop

[danaeckel]

Greetings,
I have been away from the FreeBSD scene for quite some time now and looking to get back on the desktop scene. My past experience was a home server running 9.2 that shared printers, files, dhcp, dns, and a few other things. The hardware failed and I shelved the project. Right now I have a desktop with a i7 7700 CPU, 64GB ram, nVidia 1080, Windows 10 is currently installed on NVME m.2, and Ubuntu running installed on a SATA SSD. I would like to install another SSD and install the upcoming FreeBSD 12 after it's release along with X11, KDE Plasma 5. I have grub installed on the NVME drive. So my question is what is the best recommended setup I should use? Should I use Grub or something else? UFS or ZFS? Is it possible to boot a bare-metal FreeBSD HDD in some sort of virtual environment as well as normal? Any other tips and tricks?

Thanks!

 

[tingo]

FWIW, my current multiboot setup (used on a few desktops and a couple of laptops) is using rEFInd as "bootmenu" (it is a Boot Manager), as all (well, almost all) machines today is using UEFI firmware. I use GPT on the drives, then I can have as many operating systems as there is space on available drives.

One very good thing about it is that rEFInd automatically finds new operating systems as they are installed, I never need to do _any_ configuration of it after it is installed.

Drawbacks:
- EFI system partition - the FreeBSD installer always creates a filesystem of a fixed size (100 MB?) no matter how big you create the partition. If you create a larger partition and want to use the rest of the space, you must backup the files, re-create the filesystem, restore the files. I understand why this happens, but it is still very, very far from an elegant solution.
- some installers (including FreeBSD) creates a new EFI (boot) partition instead of using the existing one, requiring me to manually copy files to the correct EFI partition and delete the extra one
- some installers (too many to mention, but Linux distros are one of the culprits) changes the active UEFI boot entry to their own bootloader, requiring manual intervention to get rEFInd back in the "drivers seat" again
- many (most) UEFI firmware implementations doesn't have a way to change or reorder UEFI boot entries. Luckily, efibootmgr (under Linux) works well for that (even if the syntax is a bit arcane. I haven't tested FreeBSDs efibootmgr yet)

Other than that, this scheme works very well for me.