This week, we’re spotlighting user Rod Myers (@RodMyers). Rod went above and beyond to troubleshoot install device detection on a system with an Asus motherboard. He also took notes so other community members might be able to avoid or solve similar issues. Thanks Rod!

Here are his notes, with some light editing:

Installing TrueOS on a system with an Asus motherboard with UEFI detect problems

My system has an Asus motherboard. The exact model # is unknown, but it has a graphical bios with mouse support:

American Megatrends (C) 2012

version 2.10.1208

On startup, boot into the BIOS. I pressed either F2 or DEL to open the BIOS. In the BIOS, navigate to the Boot Menu Selection options. Set the CSM (Compatibility Support Module) to AUTO. Under Secure Boot, select Other OS. Press F10 then save and exit.

Reboot the system and open the BIOS again. Select the Boot Menu and scroll down until you see your flash drive with UEFI displayed next to it. For example, a ScanDisk flash drive displays as UEFI ScanDisk. Select the drive. Once selected, the computer boots using UEFI. Press F10 and save/exit once more. This restarts TrueOS in UEFI mode, allowing you to continue installing as per the handbook.

Post-Install

After installation, if the system continues to not start TrueOS in UEFI mode, go back into the BIOS settings to boot the flash drive in UEFI mode. When the TrueOS install is done, reboot the system. The rEFInd boot menu will appear, which means the boot and install process is complete. Otherwise, the system may display a dreaded “reboot and select proper Boot drive” message.

If this error displays, reboot the system and enter the BIOS again. Select the Boot Options and locate the Boot Order selection options. Choose the UEFI OS or UEFI OS:hard drive option. Press F10 to save and exit. Reboot the system and the rEFInd boot option finally displays, completing the boot and install process.

6 Comments

bsdtester
on September 29, 2017 at 12:23 am

During this whole whole procedure, a “BIOS” is not involved, at all.
All we have is 1/3) EFI-Firmware 2/3) At least two ESP-Partitions, and 3/3) an EFI-Extension living on each of the ESPs. All these essential facts are not mentioned.

Therefore, this text is not generalizable and bring no conceptual advancement regarding the necessary steps involved.

1. Then, why this text?
Answer: Because the naming when it’s described is
chosen in ways that can make one very angry.

2. Why are many descriptions bad?
Manufacturers either don’t want you to install other
operating systems (Microsoft/Apple) or
they want to dumb down the process by leaving out reasons
and the descriptions of steps necessary (motherboard makers).

Remark: On Apple’s Support Web Page, search for “Linux”.
You’ll probably find nothing. They are a hardware vendor
but they don’t help you with their hardware. That’s how far
it goes. Even MS-Windows is only described as installable
via their dumbed down ‘bootcamp’ solution and they tell you
certain versions of Windows are not compatible with their
hardware. They simply tell lies. And now imagine what this
means for BSD and Linux. Actually, BSD and Linux run fine
on Apple’s hardware.

Part 2
======

A. The facts neccessary to be known:

1. Check Your firmware
When your computer starts at power on,
enter your EFI-computer’s firmware setup and
take a look around. If there is something about
“BIOS” or “CSM” (BIOS Compatibility Support Module),
switch it off. This is 2017. The 80s are over.

2. Check Your disk
Your disk must be partitioned according to the GPT
partitioning scheme. Windows and macOS computers have
their disk partitioned this way, out of the box, nowadays.

If you buy a new disk, check this out.
It may be, your new disk is not GPT-partitioned.
If you have an old, non-GPT disk, convert it to GPT.

If you need to run an OS that needs MBR or disklabel-disks,
install it in a virtual machine, or don’t use this disk
for modern OSs (BSD, Linux, Windows, macOS, Solaris, whatever).

B. Sometimes, after a successful EFI-installation, You still see
information mentioning “BIOS”.

One known culprit is OpenBSD, because
when you do: ‘dmesg | grep bios’ it gives you:

bios: … EFI …

This info is obiously nonsense. Be aware of this on other Operating
Systems, too. This is wrong information and ‘bug report’-worthy.

OpenBSD should have shown:

system-firmware: … EFI …
or
boot-firmware: … EFI …

I’m mentioning OpenBSD specifically, because they are proud of their
“doing it correctly”. Now, you can imagine what others do, who have
other priorities, like keeping their users stupid and infantile.

If you read some info, never stop thinking about its truthfulness.
Always check for common sense. This is not only true for religion and
other ideologies, but even for technical documentation. It may always
be an involuntary error or a conscious lie.

Part 3 The only really important part and the most easy one
===========================================================

What has to happen:

Computer is powered on. Startup begins.

Hardware-builtin EFI-firmware is executed by cpu.
Firmware knows what a standardized keyboard, display, and disk
are and therefore finds and can use them.

Firmware examines disk.

1. Disk must be GPT-partitioned.
2. Disk must contain a GPT-partition of type ESP
(EFI System Partition).
3. Filesystem within/on ESP must be readable (kind of FAT-FS).
4. Filesystem must contain a firmware extension program.
5. Extension must be loaded from disk into RAM/memory.
6. CPU must start to execute extension.

If You don’t set up anything at all, there’s a standardized
default name and path of the extension program defined by the
EFI standard:

It looks like this, if mounted under BSD,Linux,macOS,Solaris,etc.:
/EFI/BOOT/BOOTX64.EFI

or (because it’s a FAT-FS) the old Microsoft way:

\EFI\BOOT\BOOTX64.EFI

==> End of Essential Hardware Info. That’s all. <==

Now, we have seen, why it's called EFI. The firmware extension
is needed. That's why. Your hardware's firmware has an interface
to be extended by external *.efi executables sitting on the disk's
ESP and waiting to be executed by the firmware. This could be any
software. It even could be a little game. And because it's a whole
filesystem, there could be many *.efi programs and configuration files
for them and help-text files or whatever, too.

It could be a command line shell with additional programs (a text editor
for changing of configuration files, for example). The possibilities are
nearly endless.

Part 4: What does an installer do to make an OS bootable?

Answer: It copies an *.efi program into the ESP that can
read the OS's filesystem, find the OS's kernel file in there,
load it from disk into RAM/memory, and then tell the CPU to continue
now with reading and executing its commands from the kernel.
This is called a boot loader.

When the CPU starts to execute the kernels first instruction,
Boottime is over and Runtime has begun. Only now is there a running
BSD, Linux, Windows, macOS. Before, there wasn't. Before, there was only
the firmware and its extensions.

1. What does the FreeBSD installer do?
Answer: It copies this into the EFI System Partition:

We know this, already: It's the extension-file started by default.
If you have a correctly configured EFI-computer, you do nothing
apart from watching and enjoying the show. It boots by default
into FreeBSD, because FreeBSD names its *.efi file according
to the standard's default "EFI" "64"Bit "Boot" E"x"tension.
FreeBSD follows the standard, and therefore "it just works".

Part the fifth: Being the part where trouble beginneth…
========================================================

Multi-Booting and its inherent dangers:
—————————————

Let's say this is installed like we've seen already, and now
you install another EFI-compatible OS, let's say: A second FreeBSD.

Could this overwrite the existing BOOTX64.EFI?
Answer: YES.

But, good news: You can have several EFI System Partitions on one,
single disk. The first one is chosen by the hardware-builtin firmware's
standard default-behaviour.

How does TrueOS behave?
Answer: Well, it installs rEFIt, an additional boot manager.

How does rEFIt work?
Answer: It's another *.efi extension program within the ESP.
What's its path and filename?
Answer: EFI/BOOT/BOOTX64.EFI

Would FreeBSD and TrueOS overwrite each other's boot code?
Answer: YES. If they use the same ESP. Therefore, create a second one.

Would it be nice and helpful to be able to change the name "BOOTX64.EFI"?
Answer: YES.

Is it possible?
Answer: Technically, YES. Actually, NO.

Let's say, it was possible: How to choose between them?
Answer: Use your firmware setting setup after (re-)starting your computer.

Is there an important difference between EFI and UEFI?
Answer: Yes, UEFI enables Microsoft, and thereby
the USA "Prison, Torture and War" elite
to disable their own citizens' and other peoples' computers remotely
in case of revolution, or war, or both at the same time. All that is
needed is some obscure so called "Microsoft Update".

What does the U in UEFI stand for?
Answer: "Unified", like in "United States".

What's Secure Boot?
Answer: A way to secure the ability of making any computer
unbootable for a small elite possessing the secret encryption
keys. This is possible because people are educated from early
childhood to see themselves as customers instead of citizens.

Do you hate America?
Answer: No. Closed Source software helps the official elite
and other criminals, whereever and in whatever country they
and their hangmen provide for themselves and their own interests.

Tim
on October 4, 2017 at 12:25 pm

Thanks for the writeup and extra background – it is very appreciated!

jack
on October 25, 2017 at 7:32 am

It will be very usefull if You include into installer a option for “normal”, non-uefi installation.

Linux Example of “benefits” of efi installed system (which is the main reason I am avoiding efi):
Suppose You have 2 or more SSD (but I think this will affect single disk too) with two or more OS-es.
Now, If I shutdown, disconnect one disk (where is Arch, for example), and boot into second SSD/OS, then shutdown and connect back beforementioned SSD with archlinux@efi-based-install, suddenly MoBo get demented and can’t see (efi) arch system!
Then I have to boot arch(or any other) linux installation DVD, mount and chroot into that installed system, and do some work to fix this issue.
So this is how “advanced” is EFI.
“Normal” non-efi based installations with UUID-ed partitions can be disconnected and changed in different SATA slots and will ALWAYS be bootable by picking which slot/disk to boot from MoBo boot-menu (usually one of the keys between F8 – F12 )

It is very annoying when you boot, in this case trueos installer, and it immediately go into efi mode, “because it knows what is bast for user” – this are properties of windows and *buntu systems