OpenBSD on a Dell Inspiron 1000 Laptop

Visit tuxmobil.org

Table of contents:

Platform

NARA research desk

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

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

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!
  3. Click here for my /etc/X11/xorg.conf configuration file for the Dell Inspirion 1000
  4. Click here for my /etc/X11/xorg.conf configuration file for the HP OmniBook 2100

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

  1. http://lists.debian.org/debian-devel/2005/07/msg01217.html
  2. http://lists.debian.org/debian-devel/2005/07/msg01229.html
  3. http://lists.debian.org/debian-devel/2005/07/msg01268.html
  4. http://lists.suse.com/archive/suse-kde/2005-Apr/0085.html

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. This fix is needed on the OpenBSD port of KDE, and probably on most Linux distributions.

Go to the directory /usr/local/share/config/kdm, or on Linux, /usr/share/config/kdm. Modify the file Xsession found there. You are looking for something like a case statement that resembles the following — what you are really looking for is the call of startkde:

[... several lines deleted ...]
case $session in
  "")
    exec xmessage -center -buttons OK:0 -default OK \
        "Sorry, $DESKTOP_SESSION is no valid session."
    ;;
  failsafe)
    exec xterm -geometry 80x24-0-0
    ;;
  custom)
    exec $HOME/.xsession
    ;;
  default)
    exec /usr/local/bin/startkde
    ;;
  *)
    eval exec "$session"
    ;;
esac
[... one or a few lines deleted ...] 

Simply insert ssh-agent as shown below. That way the SSH agent is exec'ed and it spawns startkde as its child. That way an SSH agent is up and running, and every one of your KDE processes is a descendent.

[... several lines deleted ...]
case $session in
  "")
    exec xmessage -center -buttons OK:0 -default OK \
        "Sorry, $DESKTOP_SESSION is no valid session."
    ;;
  failsafe)
    exec xterm -geometry 80x24-0-0
    ;;
  custom)
    exec $HOME/.xsession
    ;;
  default)
    exec ssh-agent /usr/local/bin/startkde
    ;;
  *)
    eval exec "$session"
    ;;
esac
[... one or a few lines deleted ...] 

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 

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

When I installed a bunch of packages on 3.9-current, 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

Does... 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, and Rainbow Crack.

tuxmobil.org
Click here to inquire about advertising on this or any page on this site.
Home Unix/Linux Networking Cybersecurity Travel Technical Radio Site Map Contact


Use /bin/vi! Manipulate images with ImageMagick! Hosted on OpenBSD
Hosted on Apache This site is viewable with any browser Valid XHTML 1.0! Valid CSS!
© Bob Cromwell Feb 2012. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache.    Root password available here, privacy policy here.