Recently I've been playing around with NetBSD on the Dell Latitude E6500 laptop that I use when I work at home.
Because I wasn't sure whether I was going to like it, and I only have one hard drive in the laptop, I decided to try installing NetBSD 5.1 onto a 16GB Kingston USB flash drive. This part basically "just worked." I burned the NetBSD 5.1 ISO image for i386 to a CD-R, and booted off of it. I inserted the USB drive after the laptop had decided to boot off the CD. The installer reported the USB drive as a SCSI disk, sd0:
umass0 at uhub7 port 3 configuration 1 interface 0 umass0: Kingston DT 100 G2, rev 2.00/1.00, addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: <Kingston, DT 100 G2, PMAP> disk removable sd0: 30524 MB, 7660 cyl, 255 head, 32 sec, 512 bytes/sect x 62513152 sectors
I let the installer partition it for exclusive use by NetBSD according to its defaults. Once the installation finished, I ejected the CD-ROM and the laptop booted off the USB drive right into NetBSD. I logged in as root and used useradd(8) to make myself a new user account.
I had to turn on a few things in /etc/rc.conf after the installation. (The afterboot man page was a good checklist to follow.) I added rtclocaltime=YES to tell NetBSD that my system clock is set to local time, not UTC time, as is required for a machine that runs Windows. I added xfs=YES and xdm=YES to bring up the X Window System font server and graphical login window on boot.
Once I had enabled xdm, I logged in as my unprivileged user (brg) account. The default X session launched xsm (the X Session Manager). This turned out to be a particularly poor choice. xsm dumped core when I clicked on the big, enticing box labeled chooseSessionListWidget. It looks like it dereferenced a null pointer in SessionSelected(). I have never had an occasion or need to use xsm, so I just installed a sane .xsession to work around this problem.
Once successfully logged in to X, I noticed a bunch of noise in the xconsole window related to getty respawning too quickly. It seemed that /etc/ttys had been trying to run a getty on /dev/console. Taking a wild guess, I edited /etc/wscons.conf to turn on "screen 0", then edited /etc/ttys to disable the getty on console and enable the getty on ttyE0. This seemed to work. I could switch back and forth between the 4 text-mode screens and the X display using Ctrl-Alt-F1 through Ctrl-Alt-F5, and xconsole shut up about the getty.
One of the things that is particularly nice about BSD in general is the relative feasibility of having fully rebuildable source code to everything on the system. So, perhaps without really thinking very hard about it, I downloaded the NetBSD 5.1 source CD image as well, onto my Windows 7 NTFS partition. I mounted the NTFS partition read-only and then used vnconfig to set up a vnd instance pointing to the CD image. This didn't work -- the kernel logged a "dos partition I/O error", apparently from scan_mbr() in sys/kern/subr_disk_mbr.c. I was able to work around the problem by moving the image onto the (FFS-formatted) flash disk first. The vnd(4) manual page says that "the vnd driver does not work if the file does not reside in a local filesystem." Maybe what this means is that the file has to reside in a local FFS filesystem.
Once I had X running and the system sources installed, I wanted to get the machine on the network. The E6500 has an internal Intel WiFi Link 5300 wireless card, which is supported in NetBSD-current by the iwn driver, but not yet in the NetBSD 5.x branch. On the other hand, the Intel on-board Ethernet controller is supported; NetBSD calls it wm0. wm0 worked out of the box, but I usually use this laptop where it would be inconvenient to get an Ethernet cable, so my goal was to get the wireless interface working.
Anticipating that I was going to need to hack the kernel a bit, I created a new kernel configuration file. I copied the GENERIC configuration to start. I figured I was going to want to try to log in to my employer's network at some point, so I added the IPSEC options and fired off a build.
I roughly followed Chuck Zmudzinski's advice for getting the similar Intel WiFi Link 5100 working with a 5.0.2 kernel.
Once the kernel was patched, built, and booted, I downloaded the iwlwifi firmware from intellinuxwireless.org. That website offered two versions of the firmware, one in an archive called iwlwifi-5000-ucode-5.4.A.11.tar.gz, containing a file called "iwlwifi-5000-1.ucode", and the other in an archive called iwlwifi-5000-ucode-8.24.2.12.tgz, containing a file called "iwlwifi-5000-2.ucode". By trial and error I discovered that the driver only looks for the filename "iwlwifi-5000-1.ucode", so I settled on the older version of the firmware, which I unpacked into the /libdata/firmware/if_iwn directory.
My home wireless network uses WPA-PSK. On NetBSD you use wpa_supplicant to authenticate yourself to a WPA-PSK network. This requires writing a short configuration file, which is typically named /etc/wpa_supplicant.conf. That file looks a bit like this, in my case:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
network={
ssid="something"
psk="something"
}
Once wpa_supplicant could connect to my home wireless network, I set up an /etc/ifconfig.iwn0 file so that the boot scripts would know how to configure it. That file just looks like this:
!wpa_supplicant -B -iiwn0 -c/etc/wpa_supplicant.conf dhcp
This means that in order to bring up iwn0, /etc/rc.d/network should run wpa_supplicant with the given command line, then attempt to configure the interface with DHCP, by starting dhcpcd. The -B option tells wpa_supplicant to put itself in the background; -i tells it which interface to use, and -c tells it where to find the configuration file. dhcpcd will wait until the interface is ready before obtaining an address.