FreeBSD Problems

From Exterior Memory
Jump to: navigation, search

This page contains miscellaneous problems I've encountered. I list them here, or post them at the FreeBSD forum, in hope they are useful for others.

IPv6 bugs

While FreeBSD is rather stable, it is by no means bug-free. I have encountered the following IPv6-related bugs in FreeBSD.

kern/165190: [lo] [patch] loopback interface is not marking ipv6 packets (should marked as [kern] instead of [ipfw])

kern/170604: [ipfw] ipv6 reass broken

kern/124933: [pf] [ip6] pf does not support (drops) IPv6 fragmented packets

kern/172648: [pf] [ip6]: 'scrub reassemble tcp' breaks IPv6 packet checksum on SYN ACK

kern/168190: [pf] [patch] panic when using pf and route-to (maybe: bad fragment handling?)

(not reported) ipfw matches recv data for outgoing ICMPv6 replies.

USB3 bugs

Main article: Installing & Upgrading forum, topic 34120: Mounting installer on USB stick failed with error 19 (USB 3 driver not present)


I copied the FreeBSD installer on a memstick. After booting I first get the FreeBSD menu, and after selecting "boot" I get the a few lines and the error:

Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19.

Loader variables:


mountroot> ?
List of GEOM managed disk devices:
   ada1 ada0


Apparently, that particular installer could not be booted from a USB 3 port, only from a USB 2 port. This problem occurred in 2012 and may be fixed by now.


My solution was to stick the USB stick in another port. In my case I moved it from a USB3 to a USB2 port, and that solved my problem.

Hope this tidbit may help others with a similar problem. For the FreeBSD experts: why would this error be there, and how would it matter where the USB key was plugged in? Because it was USB 3? Because the USB 3 port has another controller? And why would it fail if I first see the boot menu (so the computer could read the stick just fine).

Kernel Reboot Crash

Main article: System Hardware forum, topic 34160: kernel panic during reboot (likely cause: bug in driver, I suspect a USB 3 driver). Fixed in FreeBSD-9.3.


My 2012 server (ASRock E350M1/USB3 motherboard, 16 GByte memory) doesn't reboot. If I halt or reboot the machine (with /sbin/reboot or /sbin/shutdown -r or -h), the machine seems to shutdown properly at first, but by the time it should actually reboot, it displays the following kernel panic:

trap number             = 12
panic: page fault
cpuid = 0
uptime = 49s

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff80b4026c
stack pointer           = 0x28:0xffffffff81178d70
frame pointer           = 0x28:0xffffffff81178d80
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1627  (reboot)
trap number             = 12
panic: page fault
cpuid = 0
uptime = 49s

kernel trap 12 with interrupts disabled

The above numbers are the same each time. The only difference I see is that when I run /sbin/shutdown, the current process is 1 (init) instead of reboot.


Trap 12 is usually caused by bad hardware. However, this was not the cause. It was a bug in a FreeBSD device driver. I suspect a USB3 driver.


The kernel no longer occurs after upgrading to FreeBSD 9.3 So it was indeed a bug in FreeBSD, not faulty hardware.

DHCP client configuration error


# dhclient -d em1
/etc/dhclient.conf line 9: expecting a statement.

The /etc/dhclient.conf file contains:

option vendor-specific-info code 43 = string;
option vendor-class-identifier code 60 = string;
interface "em1" {
    send vendor-specific-info 03:05:4d:35:34:30:0a:1f:04:20:20:20:20:04:08:41:6d:69:4e:45:54:20:20:05:0c:32:2e:37:2e:32:20:20:20:20:20:20:20;
    send vendor-class-identifier "AMINOx4x";


FreeBSD uses the OpenBSD dhclient. OpenBSD and ISC have very similar DHCP clients. However, OpenBSD does not support this particular feature to create custom names for unsupported codes.

For some reason, neither the OpenBSD nor the ISC client lists the names for code 43 and 60 in their man pages. However, they are supported, as can be seen by examining the DHCP client source code.


interface "em1" {
    send vendor-encapsulated-options 03:05:4d:35:34:30:0a:1f:04:20:20:20:20:04:08:41:6d:69:4e:45:54:20:20:05:0c:32:2e:37:2e:32:20:20:20:20:20:20:20;
    send dhcp-class-identifier "AMINOx4x";

The alternative is to install the ISC DHCP client, but I had some other problems with that, so I won't recommend that.

ZFS boot size


After upgrade FreeBSD, the following error is shown right after booting:

  ZFS: unsupported ZFS version 5000 (should be 28)
  gptzfsboot: No ZFS pools located, can't boot


In my case, the error message was faulty. The ZFS partition was fine, but the bootloader was not. I allocated a boot partition, but it turned out it was too small.

The small partition was created as:

gpart create -s gpt ada0
gpart add -b 34 -s 94 -t freebsd-boot ada0
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0

94 blocks is 47 kibyte, which I thought was enough for the 40 kibyte of /boot/gptzfsboot.


Use a larger size for the boot partition. The FreeBSD handbook says the max size of the boot partition is 512 kiByte (1024 blocks), and that's what's the FreeBSD installer since FreeBSD 10 uses by default now:

gpart create -s gpt ada0
gpart add -b 40 -s 1024 -t freebsd-boot ada0
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0

Note that this recommendation starts at block 40, instead of block 34 even though GPT only needs the first 34 blocks. This is the same as what the FreeBSD installer does by default. The reason is that modern disks have a 4 kibyte block size instead of the traditional 512 byte block size. By starting at block 40, you are certain that your partition aligns with the native block sizes of your disk.

ZFS on i386


Since FreeBSD 10.1, my i386 system no longer boots with an error:

Trying to mount root from zfs:zroot []...
Fatal double fault:
eip = 0xc181f6d4
esp = 0xda377ff0
ebp = 0xda378024
cpuid = 0; apic id = 00
panic: double fault
cpuid = 0
KDB: stack backtrace:
#0 0xc0b720f2 at kdb_backtrace+0x52
#1 0xc0b332cb at vpanic+0x11b
#2 0xc0b331ab at panic+0x1b
#3 0xc10554eb at dblfault_handler+0xab


This is likely caused by a known issue with FreeBSD >= 10.1 on i386 with multi-disk ZFS configurations.

FreeBSD/i386 10.2-RELEASE installed on ZFS may crash during boot when the ZFS pool mount is attempted while booting an unmodified GENERIC kernel.


As described in /usr/src/UPDATING entry 20121223, rebuilding the kernel with options KSTACK_PAGES=4 has been observed to resolve the boot-time crash.

See FreeBSD kernel cross-compiling for how to build and install a custom FreeBSD kernel.