Solved Can't boot on UEFI

Hello,
I've just installed Debian and Freebsd 12 on my Asus X53S Laptop with UEFI System. When I boot FreeBSD I have the FreeBSD Efi Loader but when I boot in multi user or single user mode I get stuck and the laptop reboots.



My GPT hard disk:
Code:
/dev/sda1 EFI
/dev/sda2 Debian EXT4
/dev/sda3 Debian Swap
/dev/sda4 EFI
/dev/sda5 FreeBSD UFS2
/dev/sda6 FreeBSD Swap

My Grub Config:
Code:
insmod ufs2
insmod bsd
set root='(hd0,5)'
chainloader /boot/loader.efi

How can I boot FreeBSD?
 
Just wondering … Why do you have two ESPs (EFI partitions)? I'm surprised that your boot process even gets that far. Normally there should be just one ESP per drive that contains entries for all bootable operating systems. Maybe the fact that there are two ESPs on your drive confuses FreeBSD's boot loader somehow. But that's only a guess.
 
What about an i386 install of FreeBSD. It does not include EFI and will work on your GPT partition.
Looking at your specs I see 2340M and 4GB RAM. So you won't miss anything.
That's my fallback method.
Sandy Bridge didn't have many UEFI-Only machines so this will probably work. On UEFI-Only platforms it will not.
Depends on your firmware settings too. Legacy and CSM on for best results.
 
I have only UEFI disable/enable in my laptop settings. I tried to delete the second efi partition but the problem persists:
Code:
/dev/sda1 EFI
/dev/sda2 Debian EXT4
/dev/sda3 Debian Swap
/dev/sda4 FreeBSD UFS2
/dev/sda5 FreeBSD Swap
Do I have to put some settings in /dev/sda1 or do I have to set all the FreeBSD files in the system /dev/sda4 partition?
I switched to MBR to dual boot Debian and FreeBSD and now it's okay, but I want to understand because I want to switch to UEFI.
 
I have only UEFI disable/enable in my laptop settings. I tried to delete the second efi partition but the problem persists:
Code:
/dev/sda1 EFI
/dev/sda2 Debian EXT4
/dev/sda3 Debian Swap
/dev/sda4 FreeBSD UFS2
/dev/sda5 FreeBSD Swap
Do I have to put some settings in /dev/sda1 or do I have to set all the FreeBSD files in the system /dev/sda4 partition?
I switched to MBR to dual boot Debian and FreeBSD and now it's okay, but I want to understand because I want to switch to UEFI.
Here's some background on UEFI booting.

The ESP (EFI system partition) is just a FAT file system. You can mount it in FreeBSD on /mnt with this command, for example:
Code:
mount -t msdosfs /dev/ada0p1 /mnt
(That's assuming that your disk device is ada0.)

Inside the FAT file system you'll find a directory called EFI or efi (FAT is not case-sensitive, so “EFI” and “efi” is the same). Within that directory, there should be one subdirectory for every bootable operating system. These subdirectories contain boot loader binaries (and possibly other stuff, such as configuration files) for that particular operating system. For example, Windows uses EFI/MICROSOFT, Ubuntu uses EFI/UBUNTU, and so on. I guess that Debian uses EFI/DEBIAN.

There's one important thing to know: The UEFI BIOS will not simply search the ESP and use whatever boot loaders it can find. Instead, boot loaders need to be registered with the BIOS. The information is saved to so-called UEFI variables, which are stored in NV RAM. In FreeBSD, these variables can be read and written with the efibootmgr(8) command. However, there's one little problem: The operating system can access the UEFI variables only if it was booted via UEFI, so there's a chicken-and-egg problem. There are several ways to solve this problem, though – More on that below.

Among all the subdirectories within EFI in the ESP, there is a special case: EFI/BOOT is intended to be used as a fallback boot loader. The UEFI BIOS runs it if no other boot loader was registered (i.e. no UEFI variable required). This is intended to be used for removable media (USB sticks, for example), but it can also be abused if there is only one operating system on your disk anyway, so you don't need to switch between multiple systems. In this case, the boot loader must be named BOOTX64.EFI, i.e. the full path within the ESP would be EFI/BOOT/BOOTX64.EFI. FreeBSD provides /boot/boot1.efi which is an EFI-compliant first-stage boot loader. You can copy it to the ESP under the aforementioned name, and the UEFI BIOS will be able to load it (again: only if there are no other boot loaders!). After that, boot1.efi searches for the first ZFS or UFS partition and boots FreeBSD from it. Usually this should be your root file system that contains the /boot directory.

However, if you need to be able to boot multiple operating systems, you cannot use the fallback loader mechanism. In this case, there should be a dedicated subdirectory in the ESP for FreeBSD. I suggest EFI/FREEBSD, but you can use anything you like. Copy /boot/boot1.efi into that directory. Again, the name doesn't matter, you can rename it to BOOTX64.EFI, but you don't have to. And now comes the important part: You have to register it with the UEFI BIOS. As mentioned above, you cannot do this if you have booted via legacy BIOS (i.e. what's called “CSM” = compatibility support module). One way to solve that problem is to boot from a different operating system that is already UEFI-enabled (maybe your Debian installation). Another way is to boot from an UEFI-enabled USB stick. Then you can use the efibootmgr(8) command to register your FreeBSD boot loader with the UEFI BIOS. Please see the manual page, especially the examples section. For example:
Code:
efibootmgr -c -d /dev/ada0 -p 1 -l /EFI/FREEBSD/BOOTX64.EFI -L "My own FreeBSD"
efibootmgr -a 0002
The first command creates a new boot entry for the ESP in partition 1 of ada0 (i.e. /dev/ada0p1), using the specified path for the loader binary, and the boot manager label “My own FreeBSD”. Note that newly created entries are inactive, so the second command activates it. (In this example, the number of the newly created variable is “0002”; it might be different for you). Just typing efibootmgr -v will list all current entries.

One final note: If there are both an MBR and an ESP, some BIOS implementations automatically fall back to legacy BIOS booting. If you don't want that, either disable legacy booting in the BIOS setup (it can often be found under the name “CSM” or “Windows 7 compatibility”), or destroy the MBR. If you're not sure whether you just booted via UEFI or legacy BIOS, the command sysctl machdep.bootmethod will tell you.

Ok, one really final note: Whatever you do, be sure to have a backup of your valuable data.
 
Last edited:
Sorry for hooking into this old thread.

There's one important thing to know: The UEFI BIOS will not simply search the ESP and use whatever boot loaders it can find. Instead, boot loaders need to be registered with the BIOS. The information is saved to so-called UEFI variables, which are stored in NV RAM. In FreeBSD, these variables can be read and written with the efibootmgr(8) command. However, there's one little problem: The operating system can access the UEFI variables only if it was booted via UEFI, so there's a chicken-and-egg problem. There are several ways to solve this problem, though – More on that below.

This just happened on my machine. The firmware does not boot the fallback because fo the removable media constraint: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247845
I assumed my firmware is broken, but reading your words this means that FreeBSD is broken any my firmware is standards compliant.
 
You mean removable media? I.e. The FreeBSD installer does not write this efibootmgr(8) command to NVRAM when the target is on removable media, e.g. a USB thumb drive? But I have
Code:
efibootmgr -v
ootCurrent: 0009
Timeout    : 2 seconds
BootOrder : 0009, 000D, 0008, 000A, 0007, 000B, 000C, 0012
+Boot0009* ATA HDD0 VenMsg(bc7838d2-0f82-4d60-8316-...
[...]
Boot0008 USB FDD VenMsg(bc7838d2-0f82-4d60-8316-...
Boot000C USB HDD VenMsg(bc7838d2-0f82-4d60-8316-...
[...]
and I never invoked that manually.
 
mjollnir Yes, I mean removable. Corrected the typo. I didn't expect efibootmgr to write to removable media. I was saying that the EFI fallback boot loader was designed for removable media, and not for local (internal) devices. Though, FreeBSD 12 still adds it to the ESP on my SSD, but not registers with NVRAM => no boot.
 
[...] Though, FreeBSD 12 still adds it to the ESP on my SSD, but not registers with NVRAM => no boot.
Ah ok, did not know that, thx. But see my previous post: I do have my HDD/SSD listed in the NVRAM, and I did not register that manually. Thus I strongly guess the installer did it.
 
No, the installer does not register your drive. This is done by your firmware. Look at the source code of bsdinstallband my issue which points to the lines of bsdinstall.
 
Thx, I see. The fix in CURRENT should slowly drip down to -STABLE. You could try to kindly urge them to accelerate this. In that source I see two other issues:
  1. there is a loop over all ESP, but as olli@ pointed out above, there should be only one ESP. I'm a complete noob on this topic. Maybe it's that there can be a ESP on every drive.
  2. the installer formats each ESP ( mkfs_msdosfs). This will wipe out an existing filesystem, whereas IMHO it should add a 'FreeBSD' subdir instead in that case (dual boot).
 
The fix in CURRENT should slowly drip down to -STABLE. You could try to kindly urge them to accelerate this.

That would be best for intermediate or novice users. I will live with the manually created boot var since it does the same as the FreeBSD 13 installer.

Maybe it's that there can be a ESP on every drive.

Technically, yes. Consider you have FreeBSD 11 on another drive and its label is FreeBSD, you wouldn't want to overwrite with level. I guess.
 
And do you agree on the 2nd topic? I'm guessing it's a bug only from reading the source, I did not try it... no need to dual boot, I'm perfectly happy w/ FreeBSD alone.
 
Back
Top