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
The strange combination of FreeBSD/i386, stable/10, OpenSSL from ports, optimized assembly code, Dell PowerEdge 1950, Intel Xeon X5450@3.00GHz, and BIOS 2.5.0, resulted in core dumps for all applications linked with OpenSSL from ports. Continue reading FreeBSD/i386, stable/10, OpenSSL from ports, optimized assembly code, Dell PowerEdge 1950, Xeon X5450@3.00GHz, and BIOS 2.5.0
I have (successfully) attempted to migrate a running i386 stable/9 system into a running amd64 stable/9 system, and attempted to migrate a running i386 stable/10 system into a running amd64 stable/10 system, only to see if these tasks are in fact feasible. The results speaks for themselves, given the boundary conditions outlined below.
If your system has a separate root filesystem of less than 1 GiB, then I suggest you consider scrapping the 32-bit system altogether, and install a fresh 64-bit system. If you wish to continue having a separate root filesystem, make that filesystem no smaller than 2 GiB to accommodate future expansion. You may gain additional free space by deleting
/boot/kernel*/*.symbols prior to installing a new kernel. If this isn’t good enough, then you should limit the modules installed using the
MODULES_OVERRIDE directive in your kernel configuration file. (When 11.0 comes out, all kernel symbol files will live in
/usr/lib/debug/boot/kernel, relieving the stress on the root filesystem.)
The boundary conditions are:
- base built from the appropriate stable branch of the source code tree,
- amd64 snapshot for the appropriate stable branch to speed up parts of the transition,
- the system being able to run with the
GENERIC kernel until a new custom kernel is optionally installed,
- if your system needs a custom kernel to function properly, one can be precompiled on a spare 64-bit system and transferred to the subject at the right moment,
- ports built from the ports collection with
ports-mgmt/portmaster as a vital instrument, and
- the ports listed below.
Continue reading Migrating FreeBSD from i386 to amd64
On my FreeBSD/i386
head VMs I have set up
clang as the system compiler.
I have also set
corei7 as this is accepted by
clang and pretty much describes the capabilities of the host system.
CPUTYPE woes with
editors/emacs on FreeBSD/i386
Some of my servers are running a fairly old version of FreeBSD/i386. I began researching how to upgrade them from stable/8 to stable/10 via stable/9. It’s pretty straightforward, but there are some pitfalls you should avoid. Continue reading Upgrade FreeBSD/i386 from stable/8 to stable/10 via stable/9
None of the below is relevant as of 2014-06-06, other than the possible need of reverting
sys/dev/pci/pci.c. I have confirmed that FreeBSD/i386 stable/8 r267147 works as expected on Dell OptiPlex GX260.
If you happen to run FreeBSD/i386 stable/8 on older Dell desktop PCs, like an OptiPlex GX260, you might want to back out r262226 prior to upgrading to the latest revision. The change done to
sys/dev/pci/pci.c in r262226 renders the kernel unable to mount the root filesystem.
You’re in the clear if you run 8.4-RELEASE, or stable/9, or stable/10 for this particular hardware. Maybe it’s time to move on to stable/10 or stable/9.
Luckily, none of my PowerEdge servers running stable/8 are affected.
Here’s what you should do (once) prior to running
make buildworld buildkernel on affected systems:
svn diff -r 262226:262225 sys/dev/pci/pci.c | patch
The above action will add the character
M to your kernel’s global revision number, indicating one or more local changes.
sys/dev/pci/pci.c be corrected for this deficiency in the future, you might want to revert the changes made above by running:
svn revert sys/dev/pci/pci.c
I’ve been experimenting with
carp(4) on FreeBSD/i386 10.0-CURRENT and FreeBSD/amd64 10.0-CURRENT for the past year or so.
carp(4) is no longer a pseudo-interface, but rather accessible on every conceivable interface. Continue reading CARP on FreeBSD 10.0-CURRENT
Jeg børstet støvet av noen tilårskomne filer forleden dag. Jeg fant et lite program som jeg skrev en gang i 2000. Programmet teller ned til slutten av Unix-epoken.
Den opprinnelige definisjonen av datatypen
time_t, 32-bit heltall med fortegn, vil få overflyt i midten av januar 2038. Moderne 64-bit OS som FreeBSD/amd64 9.0 har for lengst gått over til 64-bit
time_t. Bare ta en titt i fila
/usr/src/sys/amd64/include/_types.h, omtrent ved linje 83. Problemet med overflyten i år 2038 vil fortsatt gjelde alt utstyr og (binære) filformater som bruker den gamle definisjonen, slik som FreeBSD/i386 9.0. Ta en titt i fila
/usr/src/sys/i386/include/_types.h, omtrent ved linje 91. Den engelske utgaven av Wikipedia har en utfyllende artikkel om problemet.
Kildekoden for det søte, lille programmet mitt, er gjengitt under. Continue reading endofepoch.c