OpenBSD on a Dell Inspiron 1000 Laptop
Table of contents:
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...
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.
Using drive 0, partition 3. Loading... probing: pc0 apm mem[633K 444M a20=on disk: hd0+ >> OpenBSD/i386 BOOT 3.02 boot> boot -c
ukc> disable apm0 ukc> quit
# 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 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:
The biggest things to remember:
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.
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:
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):
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
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 ...]
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:
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:
kfmclient openProfile webbrowsingChange this to instead read something like this:
ulimit -n 256 ; kfmclient openProfile webbrowsing
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:
$ find /usr -name lib -type d
# 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|
|Linksys WPC55AG||/etc/hostname.ath0||dhcp media auto mode auto|
|Netgear MA521||/etc/hostname.rtw0||dhcp media DS11 mode 11b -chan|
|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.
See my other pages for details on how to build large software packages like Wireshark, OpenCV, OpenVAS, and Rainbow Crack.