I don’t know, but it’s worth a try.
Over the years various releases of Legacy Grub and Grub2 for Linux claim to be able to boot the FreeBSD and NetBSD kernels. In my exprerience it sometimes works and sometimes not. But indeed, Legacy Grub has a ufs2 stage 1.5 ( /boot/grub/ufs2_stage1_5), which allows it to access the BSD file system (provided it is ufs) and possibly load the kernel. But it only works if Legacy Grub is installed in MBR. Otherwise chainloading the bootsector (whether BSD or another boot loader) always works. Grub2 has ufs1 and ufs2 modules (/boot/grub/ufs1.mod and /boot/grub/ufs2.mod) which have to be loaded to access the filesystem.
- Notice that Grub2 is installed in /boot/grub2 under openSUSE and Fedora and grub2-efi in /boot/grub2-efi.
The EFI syntax is different. I don’t have FreeBSD examples but I can show you the difference between a grub2 and grub2-efi entry which boot openSUSE:
Grub2:
menuentry 'openSUSE, with Linux 3.1.9-1.4-desktop' --class opensuse --class gnu-linux --class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,**msdos**9)'
search --no-floppy --fs-uuid --set=root f91ddef2-81ea-4fbe-be2b-b56ff4b2ad45
echo 'Loading Linux 3.1.9-1.4-desktop ...'
linux /boot/vmlinuz-3.1.9-1.4-desktop root=UUID=f91ddef2-81ea-4fbe-be2b-b56ff4b2ad45 quiet splash=silent
echo 'Loading initial ramdisk ...'
initrd /boot/initrd-3.1.9-1.4-desktop
Grub2-efi:
menuentry 'openSUSE, with Linux 3.1.9-1.4-desktop' --class opensuse --class gnu-linux --class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,**gpt**3)'
search --no-floppy --fs-uuid --set=root 2e544d67-fed0-4c94-b056-311ea6d1b585
echo 'Loading Linux 3.1.9-1.4-desktop ...'
linux /boot/vmlinuz-3.1.9-1.4-desktop root=UUID=2e544d67-fed0-4c94-b056-311ea6d1b585 quiet splash=silent elevator=noop
echo 'Loading initial ramdisk ...'
initrd /boot/initrd-3.1.9-1.4-desktop
The nice thing about Grub2 is that, thanks to the search command, which looks for the partition UUID, booting will succeed even if the BIOS drive is the entry is wrong (because it might change while the partition UUID won’t).
I would zero fill the first sector. But the most important with this maiboard is to call the BIOS setup (del del del, etc) with the CD inserted immediately before booting and drag the UEFI striped icon into the first position. Otherwise, either Ubuntu, Fedora, openSUSE or Windows will perform a non UEFI installation. That’s the trick actually. You have to do it every time for CDs or DVDs which include the 2 setups.
Now, are you sure that the non-UEFI approach doesn’t work? It sounds kind of a little bit too clever to install a UEFI OS on an external medium for the sole purpose of booting all MBR based OSes on your local hard drives. You replaced your mainboard and your OSes don’t boot as they use to. Am I right? This happens to many people and the problem is not the UEFI BIOS. You’ll solve this problem by setting the correct drive order - maybe switching SATA ports - and editing the Grub menu (sometimes also reinstalling the Grub boot loader). The way the SATA ports are mapped to BIOS drive numbers depends on the mainboard and on the number of SATA controllers. It may vary from one mainboard to the other. I guess that - unless the BIOS drive numbers change randomly - if you install Grub in the MBR of the first hard disk and add the correct boot entries in Grub menu, you should be able to boot any OS. I haven’t installed FreeBSD for years, but changing the boot device is uncomplicated. You can also specify it at the boot prompt if you chainload the BSD loader (The bestie screen). Ask in the FreeBSD forum! You might also have to edit /etc/fstab. FreeBSD has a weird way of numbering hard disks. For example, if you have two controllers and the first one is empty, the first hard disk might become ad4 while it would be ad0 on another mainboard with a single controller. NetBSD and OpenBSD are more consistent with hard disks … and everything else, IMO. Not being able to boot FreeBSD or another OS after replacing the maiboard is neither rare nor unsolvable.