UNIX / Linux keyboard.

OpenBSD on a Dell Inspiron 1000 Laptop

Running a High-End Server Operating System on Low-End Hardware

Platform

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!

Software

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...

NARA research desk

My Dell Inspiron on a research project at the U.S. National Archives with konqueror, konsole, xterm, and kworldclock running.

Initial problem — Boot failure due to APM

Good news — this seems to have been fixed starting with the OpenBSD 4.5 release! Hopefully you won't need the following fix, but I'll keep the explanation on this page just in case.

The system would not boot, it hung within the first 16-20 lines of output after the boot prompt. 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 noapci option.

Fix for the boot failure

  1. Ask for a configuration boot when starting the installation:
    Using drive 0, partition 3.
    Loading...
    probing: pc0 apm mem[633K 444M a20=on
    disk: hd0+
    >> OpenBSD/i386 BOOT 3.02
    boot> boot -c
    
  2. Tell the kernel to disable the APM device, and then continue booting:
    ukc> disable apm0
    ukc> quit
    
  3. The system should now boot. Go ahead and do the install.
  4. 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.
  5. 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
    

Configuring X

Starting with OpenBSD 4.1, you need to make some kernel settings. From the manual page for xf86(4):

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 /etc/sysctl.conf and then reboot:

machdep.allowaperture=2

The biggest things to remember:

  1. Do not use X, use Xorg instead!
  2. Do not use xf86cfg, or, worse yet, xf86config, use xorgcfg instead!

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:

# Xorg

If it works, you will get the X background pattern and a X-shaped cursor. Kill the X server with:
<Ctrl><Alt><Backspace>
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 kdm process:

# pkill kdm

and then configure the KDM display manager:

# /usr/local/bin/genkdmconf

With OpenBSD 3.8 came a move to KDE 3.4, and some profound keyboard problems. The short version is that the getty processes (which run login on the text virtual consoles) grab many of the TTY devices, /dev/ttyC[0-5]. The display manager should run on /dev/ttyC4 but it and the getty processes 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 getty, kdm, or both, but that doesn't seem very promising. 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 getty 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 of /etc/rc or /etc/rc.local, 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 kdm
echo "Starting KDM"
( sleep 5 ; /usr/local/bin/kdm ) &
# Save post-boot kernel ring buffer
echo "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 startkde is called within /usr/local/share/config/kdm.

Things have changed in KDE4. The user's desktop environment is started by the shell script /usr/local/bin/startkde4. That path appears to be hardcoded into the KDE4 display manager kdm. 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 csh/tcsh user:

% limit

If you are a bash user:

$ 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:

  1. Right-click on the Konqueror button on my taskbar, and select Configure Konqueror button.
  2. When the new window appears, click on the Application tab.
  3. The Command field will read something like this:
    kfmclient openProfile webbrowsing
    
    Change 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

Packages, /usr/local/*bin, and ldconfig

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:

  1. 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
    
  2. Tell ldconfig to rebuild /var/run/ld.so.hints with 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!

Wireless

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
Linksys WPC55AG /etc/hostname.ath0 dhcp media auto mode auto
Netgear MA521 /etc/hostname.rtw0 dhcp media DS11 mode 11b -chan

Dealing with Devices

To do this... Linux OpenBSD
List USB devices [verbosely] lsusb [-v] usbdevs [-v]
List PCI devices lspci [-v] lspci [-v]
See pcitweak for far more

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 it in:

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 /dev/ttyU0 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

tuxmobil.org