FreeBSD Problems
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)
Problem
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: vfs.root.mountfrom=ufs:/dev/ufs/FreeBSD_Install vfs.root.mountfrom.options=ro,noatime [...] mountroot> ? List of GEOM managed disk devices: ada1 ada0
Problem
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.
Solution
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.
Problem
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.
Cause
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.
Solution
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
Problem
# dhclient -d em1 /etc/dhclient.conf line 9: expecting a statement. option ^
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";
}
Cause
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.
Solution
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
Problem
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
Cause
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.
Solution
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
Problem
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
Cause
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.
Solution
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. https://www.freebsd.org/doc/handbook/zfs-advanced.html#zfs-advanced-i386
