TrueOS Boot Loader starts after installation but doesn't find anything


The Problem I’m stuck with:


FreeBSD EFI boot block
Loader path: /bootloader.efi

Initializing modules: ZFS UFS
Probing 17 block devices . . . . . . . . . . . * . . . . . . . . done
ZFS found the following pools: tank1
UFS found no partitions
Consoles: EFI console


The last line’s ‘-’ is underlined (text cursor, presumably)
I think if all had gone well, this would be a
"nice rotating dash" or “twiddle”.

But nothing moves nothing rotates, and the only input
possible is the poweroff button of the computer’s chassis.


  1. EFI-Installation from USB-image went through flawlessly.

  2. Rescue shell of Install USB stick can mount the installed FreeBSD-ZFS partition under /mnt.

  3. Refit and Grub can both start the trueos *.efi-file from the ESP-partition.

  4. TrueOS was installed on an entirely empty, newly bought, external 4TB USB-HDD.

  5. I repeated the installation to be sure wether I made any mistakes. Don’t know of any.

  6. In VirtualBox, TrueOS works flawlessly.

  7. OpenBSD can be EFI-booted from an external
    USB-HDD without problems

My Question:
Because Re-Installation gives me no possibility for
any input at boot time:

How can I repair this with the installed TrueOS mounted within the rescue shell?

Another related effect bothering me is this:
If I boot from the installer flash drive and have the
already installed TrueOS-USB-HDD connected to the
computer at the same time, then the installer-USB-drive shows exactly the same behaviour as shown at the top of this post: The only possible action for me is
hardware-poweroff button.

Is there any possibility to get more output from the bootloader? Is there a downloadable debug version?


What brand is your new external USB-HDD?.. Also number 7 is irrelevant.


My external USB-HDD:

Big Text On Package

Expansion Desktop Drive 4TB

Small Text On Package Label

Expansion Desktop
STEB4000200 4 TB
PN: 1TFAD3-570 Model: SRD0NF2
SN: NA8FL6LN DOM: 02/2017

With Linux: Disk after TrueOS Install:

gdisk -l /dev/sdc

GPT fdisk (gdisk) version 1.0.1

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 7814037167 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): DAD51E19-8BF6-11E7-BB7F-0023DF919B8E
Partition table holds up to 128 entries
First usable sector is 40, last usable sector is 7814037127
Partitions will be aligned on 8-sector boundaries
Total free space is 32352 sectors (15.8 MiB)

Number Start (sector) End (sector) Size Code Name
1 40 204839 100.0 MiB EF00
2 204840 7805616167 3.6 TiB A504
3 7805616168 7814004775 4.0 GiB A502

Edit (still Linux info):

Second Edit (still Linux info):

lsusb -vvv | grep -E ‘Vendor|Manufacturer|Product’

idVendor 0x0bc2 Seagate RSS LLC
idProduct 0x3322
iManufacturer 2 Seagate
iProduct 3 Expansion Desk


I should have added:

The USB-HDD is USB 3.
The computer’s USB ports are only USB 2.

Maybe, this helps with finding a solution more quickly.


The reason for hanging boot loader after install was indeed the USB-HDD’s identity.

After doing an ‘entire disk’ install onto another
external USB-HDD (this time a “USB 2”-only one)
everything went perfectly.

This disk works:

lsusb -vvv -s 2:4 | grep -E ‘Vendor|Product|Manufacturer’

idVendor 0x1bcf Sunplus Innovation Technology Inc.
idProduct 0x0c31 SPIF30x Serial-ATA bridge
iManufacturer 2 Sunplus Innovation Technology.
iProduct 3 USB to Serial-ATA bridge

BUT: Another Problem!

After doing the last security update on the host computer’s
native OS (Mac OS X 10.11), this happens:

  1. Boot Loader still boots.
  2. BootEnvironment Menu still appears.
  3. Kernel starts, but
  4. panics with vfs-error and falls back to
  5. “db>”-prompt.

Is there a compatibility problem with Mac OS X?

Computer’s hardware (Linux Output):

dmesg | grep DMI:

[ 0.000000] DMI: Apple Inc. iMac9,1/Mac-F2218FC8, BIOS IM91.88Z.008D.B08.0904271717 04/27/09


I think here is the problem:

“The USB-HDD is USB 3.
The computer’s USB ports are only USB 2.”

The USB is serial data transfer much slower as the parallel data transfer. The transfer speed of the USB2 is only 40MB/sec and I think this is very very slow for the boot process of TrueOS.
The OpenBSD is only 200-300MB all the system the TrueOS is about 3GB (!) therefore about the TrueOS have to load much more data under the boot process (under about same time) as the OpenBSD and I think this is simple not enough for the TrueOS.
I think the USB3 also not enough. Maybe you can somehow connect the HDD for the machine with firewire, I don’t know, I have never tried yet. I think the only way is to buy an adapter (hdd adapter DVD bay) and change the DVD of the machine for this adapter after take out the HDD (the new Seagate external HDD) from its cover and after take it into the adapter (and so into the machine).


Thanks for answering.

After examining the details, I found these causes for not booting:


  1. Kernel panic happens while drive spins up and kernel message is: ‘mountroot’ failed.
    My suspicion: Delay is needed for kernel to wait for disk.
    Possible solution: ‘boot -p’

  2. I got the kernel to boot, nonetheless.
    But I have to retry several times. It’s a little bit strange.
    From the ‘loader’ FORTH-prompt, I typed
    by mistake: ‘boot -P’ (unintended upper case). This caused the kernel to wait for the spinning up of the disk, and it booted flawlessly.

B) After my last software install (xfce-desktop), ‘bootfs’ in the BootEnvironment selection menu was empty. Has to be filled in manually by selecting one from the existing list.

Software was installed via AppCafe.

After my last successful boot, this showed up:
~% about | grep type
type ……………………… BIOS


the output of ‘dmesg’ contained
something about ‘Bootcamp’ (Apple’s BIOS Compatibility Support)

But: While being booted into this currently running instance of TrueOS, it is changed to ‘EFI’ instead of ‘BIOS’ and ‘Bootcamp’ is nowhere to be seen within the output of dmesg.
Of course, this last variant is what I really want.

All this is very interesting and entertaining.
And this is no sarcasm. Thanks for the nice software!

Edit: correction
The current state of the still running instance is:

~% ( about ; dmesg ) | grep -Ei 'camp|efi’
type ……………………… EFI
VT(efifb): resolution 1024x640
GEOM: ada0: enabling Boot Camp

And that’s all about EFI so far, because

~% ( about ; cat /var/run/dmesg.boot ) | grep -Ei ‘camp|efi’

gives exactly the same result.

Sorry for partially wrong information.


News about booting behaviour:

After the previous boot-type (EFI), it’s now again:

~% about | grep type
type ……………………… BIOS

I don’t understand this, at all.

To do the reboot successfully, I had to retry the booting about 20 to 30 times.

The Details:

Most of the time, the kernel boots right into the ‘db>’-prompt.

I was able to boot the OS because the kernel gave me a
’mountroot>’-prompt and waited for me to manually enter

Question: Must this string end with a colon(’:’)? Where’s the documentation about the input format?

Sometimes, the kernel gives the ‘mountroot’-prompt,
but the time is too short for me to type anything before
the kernel goes on into the ‘db>’-state.

End of details.

A) Booting switches unreliably between BIOS and EFI.
B) Kernel mostly doesn’t find its root-filesystem.

Reason for B, presumably: Premature timeout during drive/partition/filesystem


Unreliable switching between BIOS and EFI:

Possible solution:


I changed the ‘scanfor’ default setting
On Macs, default is internal,hdbios,external,biosexternal,optical,cd,manual

I set it to

scanfor external,manual

Result after reboot:
~% about | grep type
type ……………………… EFI

I hope, it will reliably stay that way.


2 Booting trials were necessary:
a) Doing nothing gives ‘db>’-Prompt
b) ‘boot -a’ worked after manual entry of BootEnvironment-Filesystem

That’s all, for now.


The ‘scanfor’-Option of rEFInd didn’t help.
After next reboot, it’s “BIOS”, again.


Also, rEFInd’s

spoof_osx_version 10.9

option does not help. Still: “BIOS”.


And what is this?


[root@trueos] ~# gdisk /dev/da0
GPT fdisk (gdisk) version 0.8.10

NOTE: Write test failed with error number 1. It will be impossible to save
changes to this disk’s partition table!
You may be able to enable writes by exiting this program, typing
’sysctl kern.geom.debugflags=16’ at a shell prompt, and re-running this

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): q

Let’s do it:

[root@trueos] ~# sysctl kern.geom.debugflags=16
kern.geom.debugflags: 0 -> 16


[root@trueos] ~# gdisk /dev/da0
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): q

Could this have anything to do with my installation’s state?


Is there any in the BIOS, to point to a uefi hard drive?

My Asus motherboard had that option, otherwise I’d be reviving the

Please insert bootable drive and press enter


Thank You for Your interest.

  1. It’s an iMac. Therefore, Your hint doesn’t apply.
    If You’re interested, You can read more about this

I have not tested this, as yet:

‘Mac OS X’ setting:
sudo nvram enable-legacy-orom-behavior=1

But I will.

I see several ways forward:

a) Installing EFI-Shell and writing *.nsh script.
b) Disabling internal ‘ada0’-disk via device hints.
c) Lengthening the kernel’s detection timeout.
d) Raising the detection retry count.

I don’t think, re-installation would bring anything better than what has been achieved so far.

But if You can think of anything else, Your help is most welcome.

Last Remark:
On the internal ada0 disk, there sits a Windows 10 installation installed under Apple’s bootcamp mechanism. This Windows 10 installation is
booted by the iMac’s firmware (“Startup Manager”) and by rEFInd in BIOS-mode. And this is correct because it was installed to work that way.

The problem with EFI/BIOS switching seems to be located in the FreeBSD kernel. It seems, when it sees the Windows 10 BIOS-compatibility bootcamp partition,
the kernel automatically changes its behavior. But where and how it does this, I have not found out, as yet.


Disabling the internal factory-builtin hard-disk drive totally by deactivating its hostcontroller seems to get the TrueOS into an
orderly behaviour. Now, it seems to boot reliably into EFI mode.

I did it like this:

~% cat /boot/loader.conf.local | grep ahci

After booting, these are the results:

~% ls -l /dev/efi
crwx------  1 root  wheel  0x4 Sep 13 00:29 /dev/efi

~% sysctl -a | grep bootmethod
machdep.bootmethod: UEFI

~% about | grep 'type …'
            type ……………………… EFI

I don’t regard this as a solution, but it seems certainly a reliable workaround. Seemingly… We’ll see if it stays that way.


Hardware Compatibility News:

I opened this topic with mentioning that TrueOS wouldn’t boot with my newly bought USB-HDD (my 2nd message from the top). That is still a fact. BUT:

On this same drive, the normal FreeBSD RELEASE (11.1) install works flawlessly. The boot loader boots in EFI mode every time in a fully reliable way. There are zero conflicts with any other builtin controllers or drives.

The FreeBSD X Window System has to be configured manually to use the scfb driver, but that is no problem at all.

Now I have some foundation to compare both installations (TrueOS and FreeBSD). If I find any relevant differences, I’ll report back. But for the next 1 or 2 weeks I’ll configure the new FreeBSD installation.

Then I’ll come back to TrueOS.