This is what a kernel panic may look like when facing memory corruption.
kernel: panic: solaris assert: arc_buf_alloc_impl(hdr, private, compressed_read, 1, &buf) == 0 (0x5 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, line: 5318
kernel: cpuid = 1
kernel: KDB: stack backtrace:
kernel: db_trace_self_wrapper() at 0xffffffff8046b52b = db_trace_self_wrapper+0x2b/frame 0xfffffe0122681380
kernel: vpanic() at 0xffffffff806c5ba6 = vpanic+0x186/frame 0xfffffe0122681400
kernel: panic() at 0xffffffff806c5a13 = panic+0x43/frame 0xfffffe0122681460
kernel: assfail3() at 0xffffffff8030987c = assfail3+0x2c/frame 0xfffffe0122681480
kernel: arc_read() at 0xffffffff80322ddc = arc_read+0x83c/frame 0xfffffe0122681510
kernel: dbuf_read() at 0xffffffff8032e918 = dbuf_read+0x678/frame 0xfffffe01226815c0
kernel: dmu_buf_hold_array_by_dnode() at 0xffffffff80338bf3 = dmu_buf_hold_array_by_dnode+0x203/frame 0xfffffe0122681630
kernel: dmu_read_uio_dnode() at 0xffffffff8033a167 = dmu_read_uio_dnode+0x37/frame 0xfffffe01226816a0
kernel: dmu_read_uio_dbuf() at 0xffffffff8033a10b = dmu_read_uio_dbuf+0x3b/frame 0xfffffe01226816d0
kernel: zfs_freebsd_read() at 0xffffffff803d7e80 = zfs_freebsd_read+0x660/frame 0xfffffe0122681780
kernel: VOP_READ_APV() at 0xffffffff80a7b77c = VOP_READ_APV+0x7c/frame 0xfffffe01226817b0
kernel: vn_read() at 0xffffffff807a0815 = vn_read+0x195/frame 0xfffffe0122681830
kernel: vn_io_fault1() at 0xffffffff8079e4e9 = vn_io_fault1+0x169/frame 0xfffffe0122681970
kernel: vn_io_fault() at 0xffffffff8079c6ac = vn_io_fault+0x18c/frame 0xfffffe01226819e0
kernel: dofileread() at 0xffffffff807291aa = dofileread+0xba/frame 0xfffffe0122681a20
kernel: kern_readv() at 0xffffffff80728db8 = kern_readv+0x68/frame 0xfffffe0122681a70
kernel: sys_read() at 0xffffffff80728d46 = sys_read+0x86/frame 0xfffffe0122681ac0
kernel: amd64_syscall() at 0xffffffff809d5f18 = amd64_syscall+0xa38/frame 0xfffffe0122681bf0
kernel: fast_syscall_common() at
I’m experimenting further with
ports-mgmt/synth. I let
synth create some packages for me and I then removed all installed packages, save the
pkg package manager.
What a surprise I got when attempting to add my own metaport! Continue reading
pkg add chokes on apparantly wrong OS version
I spun up a virtual machine yesterday with the intent of learning how to use
ports-mgmt/synth. Continue reading First experiences with
r325743 corrected the mistakes. The below no longer applies. Remove
/boot/loader.rc.local if you created it.
used to be copied from
on FreeBSD/amd64. With r325694
this changed to
. Nothing was added to base/head/UPDATING
, explaining this change.
As instructed in
/boot/loader.rc, to regain our beloved boot menu, we must create and edit
/boot/loader.rc.local, essentially redoing what was handled by the previous
I too was bitten by the
portupgrade uninstall error, due to broken pipes, on my laptop running FreeBSD/amd64 stable/10. Others have identified the
file 5.26 utility as the culprit, introduced in
stable/10 as r298920.
Watch PR 209211 for any progress.
base/head was corrected at r299234, and
stable/10 will follow soon. Continue reading portupgrade uninstall error, broken pipe
All FreeBSD systems under my care got upgraded last Friday to fix some NTP bugs. That upgrade introduced a new bug in the kernel. The bug first appeared at r298004 in
base/head, and later at r298134 in
base/stable/10. The i386-based systems were more notably affected than the amd64-based systems, as the former typically has less memory than the latter. Continue reading Memory leaks in recent stable/10 kernel
I spent some days last week converting our 32-bit AMANDA server to a 64-bit counterpart using spare but aged hardware. The former AMANDA server ran on very aged hardware in comparison. Going 64-bit also ment turning to ZFS-based storage.
Today, I replaced the two 320 GB first generation SATA drives with two 1 TB third generation SATA drives. The new drives, like their predecessors, are connected to the second generation SATA controller on the motherboard. Replacing the drives is nevertheless an improvement. Continue reading Replacing drives on AMANDA server
As of r294999 it’s possible to boot FreeBSD/amd64 stable/10 from ZFS pools on systems running UEFI firmware. Up until now I have booted my UEFI ZFS laptop using the older
boot1.efi boot loader with
/boot located on a UFS partition. Earlier today I updated my EFI System Partition (ESP), put
/boot back where it belongs, in the ZFS pool, and scrapped the UFS partition. Thanks to everyone who made this happen.
One of the old webservers at work, a Dell PowerEdge R200, crashed a couple of weeks ago. I suspect the six year old motherboard finally gave up. Continue reading Dell PowerEdge R320, JBOD, mfi(4), and gpart(8)
When upgrading from one major version of FreeBSD to another, in my case from FreeBSD/amd64 stable/9 to FreeBSD/amd64 stable/10, it’s customary to upgrade the installed ports afterwards, beginning with
I forcefully upgraded all installed ports using
portupgrade -afpv, but the upgrade of
lang/ruby21 failed miserably.
I removed all traces of Ruby 2.1, i.e.
databases/ruby-bdb, before manually compiling and installing
ports-mgmt/portupgrade using the ports collection.
Now, I needed to know which remaining ports were still compiled for stable/9. The following snippet allowed me to gather the origins of such ports:
pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1
Now, I could feed that list to the newly installed
portupgrade and upgrade the remaining ports:
portupgrade -fprv `pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1`
In the end, I should have removed
lang/ruby21 completely after upgrading
ports-mgmt/pkg, and reinstalled
ports-mgmt/portupgrade manually using the ports collection. Only then is it safe to forcefully rebuild and reinstall all the other ports. Don’t forget to add
devel/cvs if you used to rely on
cvs in base, and adjust all references from