OpenBSD on a Dell Inspiron 1000 Laptop
OpenBSD on a Dell Inspiron 1000 Laptop |
|
Table of contents:
A Dell Inspiron 1000. 2.2 GHz Celeron CPU, originally with 256 MB RAM, 38 GB disk. The Hitachi disk died after a little over a year, and was replaced by 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 ca. 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 3.7, 3.8, 3.9, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5 and later are also just fine.
You know 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 be fixed 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.
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
machdep.allowaperture=2
The biggest things to remember:
If you don't have X set up yet, 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.
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):
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:
% limit
If you are a bash user:
$ ulimit -a
Strict!
And see the below discussion of Ethereal / Wireshark for another
place where this causes trouble.
My fix was as follows:
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:
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 |
This tends to fail. The OpenBSD community hasn't built Wireshark packages for a while, since Wireshark has a bad security track record. It has to run with root privileges to do most of what people find useful, and its packet dissectors (the modules analyzing the large set of supported protocols) are very complicated and prone to bugs. Privileged processes running untrusted code leads to big security problems!
On top of this, the Wireshark community hasn't seemed to worry about making Wireshark build cleanly from source on OpenBSD. Here is the trick, based on what I found at http://www.linbsd.org/ethereal_on_openbsd38.html The followed has worked with Ethereal, and it works with Wireshark.
| 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.
|
||||||||
|
| © Bob Cromwell Jul 2009. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache. Root password available here, privacy policy here. |
