You are not logged in.
I cannot figure out what I'm doing wrong trying to boot Arch, Windows 7, and FreeBSD on my system. My motherboard has UEFI 2.x firmware and my disk contains a GPT table. Anyway, I can boot Arch Linux and Windows 7 without issues using the firmware's built in UEFI shell and from GRUB2. However, FreeBSD simply will not boot. GRUB2 is installed under Arch, which is why I'm asking the question in this forum -- perhaps a few people know a little more about what's what in the package grub2=efi-x86_64.
Here's some useful information:
GPT disk information:
#gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.2
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1188BEF2-7D18-467B-A5ED-0E7A37229F9E
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 8-sector boundaries
Total free space is 1380469 sectors (674.1 MiB)
Number Start (sector) End (sector) Size Code Name
1 4096 823295 400.0 MiB EF00 EFI System
2 823296 3146551295 1.5 TiB 8300 Linux filesystem
3 3146551296 3702228991 265.0 GiB 0700 Basic data partition
4 3702228992 3702229119 64.0 KiB A501
5 3702229120 3897264119 93.0 GiB A503
6 3897264120 3905652727 4.0 GiB A502Contents of /etc/grub.d/40_custom:
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "Windows 7 Professional x86_64" {
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
menuentry "FreeBSD chainloader" {
insmod ufs2
set root='(hd0,gpt5)'
chainloader +1
}
menuentry "FreeBSD, with kFreeBSD kernel" --class freebsd --class bsd --class os {
insmod part_gpt
insmod ufs2
set root='(hd0,gpt5)'
echo Loading kernel of FreeBSD kernel ...
kfreebsd /boot/kernel/kernel
kfreebsd_loadenv /boot/device.hints
set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0p5
set kFreeBSD.vfs.root.mountfrom.options=rw
}I'll start with the chainloader menuentry --> when I try to boot I get the error
invalid efi file pathI presume this is because I'm telling GRUB to pass information to FreeBSD's BTX loader, which is only familiar with BIOS (i.e. GRUB is hosted on a UEFI firmware system and it expects to load an EFI application, but I tell it to load FreeBSD's bootloader)?
The second menuentry tries to boot the kernel directly. When I try this option I find that GRUB only gets so far as to print the part about "Loading kernel of FreeBSD kernel..." and then my system reboots. No error messages this time, which is what bothers me the most.
Offline
I should say I know nothing about FreeBSD. But the wiki claims that FreeBSD needs to be installed on a single partition. Is it possible that it doesn't like the boot loader being on a different one?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I did not notice that. However, a launchpad bug report seems to indicate that it does not require such a partitioning scheme.
As far as I am aware, FreeBSD requires a boot partition for use with GPT (it does not mount this partition, but uses it to host the gptboot code). The only other partition I created for FreeBSD was a swap partition.
I have had an interesting thought, though, which is that I could install FreeBSD onto a GPT drive first and then create the EFI System Partition (ESP) after. The EFI specification does not require the ESP to be the first partition, so it should still find it as long as the partition is properly flagged. This way, perhaps I could load FreeBSD by simply booting from the HDD in my firmware's shell and I could boot Windows/Linux from the actual EFI bootloaders (Windows boot loader / GRUB2-EFI). In the meantime, I was hoping someone has tried to do something like this. I don't think I could be the only one!
Offline
FreeBSD should support UEFI to be able to boot in a UEFI system, irrespective of the bootloader used. I persume FreeBSD kernel does not support UEFI yet. Check whether any CONFIG_EFI equivalent option is there in FreeBSD's kernel config.
Offline
FreeBSD should support UEFI to be able to boot in a UEFI system, irrespective of the bootloader used. I persume FreeBSD kernel does not support UEFI yet. Check whether any CONFIG_EFI equivalent option is there in FreeBSD's kernel config.
Not yet. There used to be used a UEFI capable bootloader for IA64, but nothing has been really worked on for the amd64 architecture yet. See the following link for details
Offline
the.ridikulus.rat wrote:FreeBSD should support UEFI to be able to boot in a UEFI system, irrespective of the bootloader used. I persume FreeBSD kernel does not support UEFI yet. Check whether any CONFIG_EFI equivalent option is there in FreeBSD's kernel config.
Not yet. There used to be used a UEFI capable bootloader for IA64, but nothing has been really worked on for the amd64 architecture yet. See the following link for details
Then its clear. Unless the FreeBSD kernel supports UEFI, it won't boot in your system irrespective of which UEFI boot loader you use.
Even in case of linux kernel, its not just the bootloader (grub2 etc.) that interacts with the firmware, once the kernel is launched it also interacts with the firmware for memmap, acpi and such stuff. You won't be able to boot a CONFIG_EFI disabled linux kernel in any UEFI system.
Offline
Then its clear. Unless the FreeBSD kernel supports UEFI, it won't boot in your system irrespective of which UEFI boot loader you use.
Even in case of linux kernel, its not just the bootloader (grub2 etc.) that interacts with the firmware, once the kernel is launched it also interacts with the firmware for memmap, acpi and such stuff. You won't be able to boot a CONFIG_EFI disabled linux kernel in any UEFI system.
Well, unless, of course, the firmware supports BIOS emulation (they all do). I think the only problem is that by using the EFI version of GRUB2 it creates an expectation of UEFI (the firmware boots grubX64.efi, which is an EFI application). There are actually some ways to create a Hybrid MBR/GPT disk, but from what I read and understand, it is quite screwy... and requires writing into the protective MBR of your GPT table.
--EDIT--
I'm not saying that a Hybrid disk scheme would allow both UEFI and BIOS booting from the same disk. I sincerely doubt the possibility of this because, as I said before, the presence of something like an EFI application (e.g. GRUB2-EFI) or the presence of something like the EFI System Partition creates the expectation of an OS that is UEFI capable. According to the thread from FreeBSD forums that I posted earlier, it does seem that some people have been able to boot FreeBSD using the EFI spec but, as you pointed out, they are basically screwed when it comes to ACPI events once the OS is up (for example, sending a power-off signal).
I'm going to give up on this triple boot scheme for now and I'll probably just purchase another HDD on which to let FreeBSD be by itself. I just wish the prices would go down...
Last edited by badhat (2012-03-25 22:05:12)
Offline