Running a High-End Server Operating System on Low-End Hardware
I have been using a Dell Inspiron 1000. It has a 2.2 GHz Celeron CPU, originally with 256 MB RAM and a 38 GB disk. The Hitachi disk died after a little over a year, and I replaced it with a 120 GB Western Digital unit. I also upgraded the memory to 512 MB by adding a 256 MB DDR module, the maximum. It was fine with OpenBSD and just 256 MB, but performance of the KDE desktop improved with the upgrade. An amusing owner's review describes this as "The Ford Pinto of the laptop world circa 2004."
This replaces an HP OmniBook 2100 with a 200 MHz Pentium I, 96 MB of RAM, and a 5 GB disk. BSD doesn't need a lot of hardware! Much of the below also applied to the HP Omnibook.
And that replaced a Toshiba Satellite Pro 430CDS with a Pentium I, 32 MB of RAM, and a 1.3 GB disk. Much of the below was unneeded on that system, although I would never have tried to build Ethereal/Wireshark there!
I started on the Dell Inspiron 1000 by installing the 22 Feb 2005 snapshot of OpenBSD 3.6, due to perceived trouble with the 3.6 official. Now that it's done, I see that the 3.6 official should have worked just fine. And everything through version 4.8 has also been just fine.
You surely know about http://www.openbsd.org/, right? Unless you're just reading this for the parts that also apply to Linux...
Initial problem — Boot failure due to APM
The system would not boot, it hung within the first
16-20 lines of output after the
Reading the output and consulting Google revealed that
it was because of problems with the automatic power
management on the hardware platform.
The provided Phoenix BIOS does not let me turn that off!
Here's what I saw in the failed boot screen after the kernel
loaded and detected the CPU and RAM:
[....] bios0: vendor Dell Computer Corp. version "A06 (Q3B01)" date 11/05/2004 bios0: Dell Computer Corp. Inspiron 1000 apm0 at bios0: Power Management spec V2.1 uvm_fault(0xd06c9800, 0x4000, 0, 1) -> e fatal page fault (6) in supervisor mode trap type 6 code 0 eip d034eeee cs 8 eflags 10046 cr2 465a cpl 0 panic: trap type 6, code=0, pc=d034eeee The operating system has halted. Please press any key to reboot.
While this page is mainly about running OpenBSD,
this will also present a problem with some Linux kernels
unless they are booted with the
Fix for the boot failure
Ask for a configuration boot when starting the
Using drive 0, partition 3. Loading... probing: pc0 apm mem[633K 444M a20=on disk: hd0+ >> OpenBSD/i386 BOOT 3.02 boot> boot -c
Tell the kernel to disable the APM device,
and then continue booting:
ukc> disable apm0 ukc> quit
- The system should now boot. Go ahead and do the install.
- After the install is complete, it cannot boot from the kernel reboot from the disk because of the same problem. So reboot from the kernel now on the disk with the above trick.
Login as root and reconfigure the BSD kernel
to permanently use that change:
# cp /bsd /bsd.original # config -e -u -o /bsd.new /bsd ukc> quit # mv /bsd.new /bsd
Starting with OpenBSD 4.1,
you need to make some kernel settings.
From the manual page for
ACCESS CONTROL Access to the /dev/xf86 device is allowed when the sysctl(8) variable machdep.allowaperture is greater than or equal to 1. This variable (which has a default value of 0) can only be raised when the security level is less than or equal to 0, so it should be set in /etc/sysctl.conf. The possible values for machdep.allowaperture are: 0 the aperture driver is disabled. Opening it returns EPERM. 1 the aperture driver allows access to standard VGA framebuffer and BIOS. Access to pci(4) configuration registers is also allowed. 2 in addition to allowing access to pci(4) configuration registers, the aperture driver allows access to the whole first megabyte of physical memory, permitting use of the int10 emulation in X.Org 6.8 and later. Note that this can cause some security problems, since the process that has access to the aperture driver can also access part of the kernel memory. This mode is not supported on alpha or sparc64.
So, if you want to run X on this platform,
put the following into
and then reboot:
The biggest things to remember:
Do not use
Do not use
xf86cfg,or, worse yet,
X should now be able to automatically figure out your hardware using its built-in short configuration. If that does not work, you might try this:
# mv /etc/X11/xorg.conf /etc/X11/xorg.conf-old # Xorg -configure # mv /root/xorg.conf* /etc/X11/xorg.conf
You can test your X setup by running a bare X server:
If it works, you will get the X background pattern and
a X-shaped cursor.
Kill the X server with:
See below about setting up KDE and its display manager.
Configuring KDM to Start at Boot Time
I wanted to use KDE, and had trouble getting it to run.
The initial trick was to stop any running
# pkill kdm
and then configure the KDM display manager:
With OpenBSD 3.8 came a move to KDE 3.4,
and some profound keyboard problems.
The short version is that the
login on the text virtual consoles)
grab many of the TTY devices,
The display manager should run on
/dev/ttyC4 but it and the
get into a race, the result of which is that the display
manager does not have access to the keyboard on the
virtual console where it is running.
Google reveals some discussion of this — one suggestion
is to attempt to control either
kdm, or both, but that doesn't seem very
I figured out a kludge of a workaround
based on these useful messages (which talk about
the problem in Linux, but it's fairly analogous):
Message 1 Message 2 Message 3 Message 4
My fix is ugly: wait a few seconds to let the
processes quit struggling for resources, then let the
display manager come in and do its thing.
I added a block like the following, either at the bottom
I didn't notice any difference in behavior:
# Keyboard may already be set up, but just in case...echo "Setting up keyboard" kbd us
# Announce, then nap briefly before starting kdmecho "Starting KDM" ( sleep 5 ; /usr/local/bin/kdm ) &
# Save post-boot kernel ring bufferecho "Saving ring buffer" dmesg > /var/log/dmesg
Automatically Starting an SSH Agent Under KDE
SSH agents are a good thing. The problem is, KDE does not generally start one in the right way. You could try messing with the user's X configuration to get one started, but the best solution seems to be to just have KDE do it.
In KDE3 you modified the way
Things have changed in KDE4.
The user's desktop environment is started by the shell script
That path appears to be hardcoded into the KDE4
Move that script to another file:
# mv /usr/local/bin/startkde4 /usr/local/bin/startkde4-real
Then create a script in the old location that will start an SSH agent and have it start the KDE4 environment by calling the real script:
# cat /usr/local/bin/startkde4 #!/bin/sh ssh-agent /usr/local/bin/startkde4-real
KDE and the Limit on Open Files
My experience has been that the Konqueror web browser will fail to load complex pages, especially if there is much already open on your desktop. This is because of the conservative limits OpenBSD places on user utilization of resouces.
If you are a
If you are a
$ ulimit -a
Strict! And see the other page on compiling and running Wireshark for another place where this causes trouble. My fix was as follows:
- Right-click on the Konqueror button on my taskbar, and select Configure Konqueror button.
- When the new window appears, click on the Application tab.
The Command field will read something like this:
kfmclient openProfile webbrowsingChange this to instead read something like this:
ulimit -n 256 ; kfmclient openProfile webbrowsing
Did I Do All Work Required by Packages?
When you install a large number of packages with
pkg_add you may see that several of them
had messages about things you may need to do manually.
But most of those messages have scrolled off the screen
and you can't see them.
You worry that you may be stuck with the wrong spell-check
dictionary, paper size, and worse.
Ask to see those messages:
$ pkg_info -aM | less
When I installed a bunch of packages on a *-current release, I would get unexpected error messages when I tried to run the binaries. They complained that they could not load shared libraries that had been installed. The fix:
Figure out where the libraries are.
Note that only some of the directories reported by
the following command
are really repositories of shared libraries:
$ find /usr -name lib -type d
/var/run/ld.so.hintswith this command:
# ldconfig /usr/lib /usr/X11R6/lib /usr/local/lib /usr/local/lib/qt3/lib
If you are at all interested in software packages, you probably want to see my package management howto page!
I initially thought I had a problem with wireless, but no, it was because I was trying to bring up the wireless in an environment with no other wireless devices...
|Card||Configuration file||File contents|
Dealing with Devices
|To do this...||Linux||OpenBSD|
|List USB devices [verbosely]||
|List PCI devices||
Using a USB-to-serial adaptor:
For example, to talk to a Cisco switch or router console port.
The device shows up in
dmesg output after plugging
uplcom0 at uhub0 port 2 uplcom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 ucom0 at uplcom0
The serial device is now
if you are configuring
minicom or similar.
And now to build some software....
See my other pages for details on how to build
large software packages like:
Wireshark OpenCV OpenVAS Rainbow Crack