The Debian GNU/Linux Dell Vostro 1000 HOWTO

tdr, Contact

v1.05, 7 May 2008
v1.04, 14 January 2008
This page meets XHTML 1.0 Transitional standards.

1. Introduction

While not strictly a HOWTO, this document chronicles my attempt to get Debian GNU/Linux running on a Dell Vostro notebook. It was conceived out of both a want to inform others, and a need for me to keep track of stuff I did, in case I have (or want) to do it again. It is my sincere hope this document proves useful to someone other than me, though, and as such I'll make every effort to be clear about procedure or any alternative methods available. This document was written with the Dell Vostro 1000 in mind, with that said, I'll list the hardware it contains in the document, in case people looking for other help with related hardware find it here. Comments in italics are not to be entered literally into things like configuration files or commands.
The official homepage for this document is currently
PLEASE feel free to send me any information or suggestions you feel might be useful! Seriously! Any good HOWTO or FAQ should be dynamic, and this document is no exception. It is my hope that the Linux and/or Debian community finds some assistance here, and without contributions I am obviously limited to my own scope of knowledge. Your contributions _will_ be credited properly if they're used in the document!
Let it be hereby noted that this is not strictly a document for experts, nor strictly for beginners. There are certain concepts that you should be familiar with first - namely using a terminal/shell and apt (aptitude, apt-get, et al.). I am notoriously unreliable when it comes to technical style while writing impromptu documentation. As an example, problems are explained thoroughly while stuff that worked is not. Caveat ... user?

1.1 Copyright and License

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Canada License.
This work is copyright Troy Rennie, 2007. Any reproductions must bear the preceeding copyright and licensing notices.

1.2 Disclaimer

Use the information in this document at your own risk. I disavow any potential liability for the contents of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk.
All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements. You are strongly recommended to have performed a backup of your system before major installation, and to perform backups at regular intervals.

1.3 References

Ubuntu Forums, Broadcom ndiswrapper setup, sed trick.
HAL Quirk Site, suspend and resume quirks list/troubleshooter.

1.4 Contributors & Thank You's

Gibi () for his scripts that enable changing the LCD brightness level!
msfk57 () for his information about 64-bit ndiswrapper!
In some cases, I have edited the spelling and grammar to be correct in Canadian English, and removed typos.
Please e-mail me if you are unhappy with any edits I have made, and I will definitely change them.

2. Hardware

2.1 Listing

2.2 lspci output

00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10)
00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge
00:05.0 PCI bridge: ATI Technologies Inc Unknown device 5a37
00:06.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SB600 SMBus (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SB600 Azalia
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200M]
05:00.0 Network controller: Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01)
08:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
08:01.0 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)
08:01.1 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01)

3. Install

Not surprisingly, the base system install with a Debian GNU/Linux 4.0r1 businesscard disc went smoothly. The disc booted, prompted me, and I gave it expert as the installation choice. There were no hardware detection issues, and for some reason the installer wanted to load the entirely useless floppy module. I could not use the Broadcom-chipped wireless adapter to continue the install (expected behaviour!) and so the installer simply loaded the b44 driver, and continued, using a patch cable plugged into my router.
Formatting the drive consisted of making a swap partition, /, and /home.
I picked testing as my flavour of choice.
During the software selection stage, several items were pre-selected. I only chose one, "Laptop". The installer proceeded smoothly until it ran into swsusp, and then it told me that there was no active swap partition, asking if I would like to proceed with the package's installation. Since I use a custom kernel with suspend to disk support built-in, I proceeded.
The rest of the install was smooth, and upon rebooting I was presented with the usual cadre of initscripts and default services, plus a shiny new login prompt.

3.1 Post-Install Tasks

After logging in with the user I created during the install, I ran
sudo aptitude install kdebase kdm koffice zip unzip less
and after that finished, I rebooted to find a default KDM login screen, running Xorg on vt7 configured to use the ati driver.
Logging in and firing up a default KDE session was no issue at all, and after I configured the desktop the way I wanted it, I set to checking the rest of the hardware.

4. Sound

Sound really wasn't an issue. The specific Intel Azalea module provided by the 2.6.22 Debian-packaged kernel worked perfectly after I unmuted the mixer, using kmix.

5. Wireless Networking

This was a _huge_ pain in the ass, mostly because I tried to use the kernel's bcm43xx module. Some would say I brought it upon myself. There were a couple problems with using this module: one, after the first two toggles it wouldn't allow me to toggle the wireless function of the laptop on and off using the Fn-F2 combination provided by the hardware; and two, it would only connect to my AP at 25MBit/sec, and even that was when it decided it wanted to. In short? The module still seems "experimental" in quality, though it has definitely improved from previous releases. The following summarizes my processes.

5.1 General WiFi Requirements

wpasupplicant and wireless-tools, along with default networking tools (like dhclient) were already installed on the system, as part of the initial installation process. I mention those because they're entirely necessary if you want to connect to almost any wireless network. Running /sbin/iwlist scan and /sbin/iwconfig ethX will tell you if your device is working, shows any wireless networks in the area, plus things like signal strength and beacon timing. Use those tools first to see if the driver is working properly, before going crazy and assuming it's your configuration at fault.

5.2 Using bcm43xx

I knew I'd need external firmware for the Broadcom driver, so I ran
sudo aptitude install bcm43xx-fwcutter
which installed the firmware extraction utility. It even cut the firmware for me from a provided driver module - and threw it into /lib/firmware! An excellent example of thoughtful work by the packager.
A reboot later, and the driver reported what I expected: the card was found, the firmware was loaded. A quick dmesg reported the radio was off and correspondingly, the laptop's LED indicator was off. I toggled the wireless on and off to check if the toggle function was working - it worked, but only for one on/off cycle. After that, I guess the driver gave up or something, because no matter what I did, including unloading and reloading the module with sudo rmmod bcm43xx; sudo modprobe bcm43xx, it wouldn't toggle back on. At that point, I rebooted and tried again. Same problem. I unloaded the module and moved on.

5.3 Using ndiswrapper

Using ndiswrapper was a pleasure after the fruitless attempt to use the kernel's driver. I ran
sudo aptitude install ndiswrapper-common ndiswrapper-source ndiswrapper-utils-1.9
which then proceeded to install those packages, plus their dependencies, like build-essential and module-assistant.
To get ndiswrapper up and running, you need the Windows driver for your wireless card - ndiswrapper is just that, a wrapper around the Windows driver until there is good native Linux support for your card. I grabbed the wireless driver from Dell's website, and unzipped it into a directory:
mkdir wifi_driver
cd wifi_driver
wget (can also be copied from your drivers and utilities DVD)
unzip -l R151517.EXE
Then, I proceeded to install the driver using ndiswrapper:
sudo rmmod bcm43xx
sudo ndiswrapper -i DRIVER/bcmwl5.inf
sudo m-a a-i ndiswrapper (this makes a Debian package of ndiswrapper's module)
sudo ndiswrapper -l
sudo modprobe ndiswrapper
I made sure that bcm43xx wouldn't load at boot and ndiswrapper would:
sudo echo "blacklist bcm43xx" >> /etc/modprobe.d/blacklist
sudo echo "ndiswrapper" >> /etc/modules
Looking at the kernel messages with dmesg told me the device was present and the driver was loaded! Yay! But the wireless indicator LED _still_ wasn't on! How frustrating! After poking around for a bit, I found that I had to replace "RadioState|1" with "RadioState|0" in the .conf files ndiswrapper was looking at, presuambly to tell the driver to turn the radio on. I ran
sudo sed -i.original -e 's/RadioState|1/RadioState|0/' /etc/ndiswrapper/bcmwl5/*.conf
and reloaded the module. That seemed to work, and the LED came on. Toggling was also no problem, and it connected to my AP at 54MBit/sec! Hooray!

5.31 A Note For 64-Bit Users Of ndiswrapper

M. Klein sends alternate instructions for 64-bit users trying to get ndiswrapper to work:
"Actually, adding 2 points at your Howto should be enough to help amd64 users:
By this way it works!"
Seems like you need to unload the conflicting driver to get ndiswrapper to work on amd64. Thank you, M. Klein!

5.4 Configuring wpa_supplicant

wpasupplicant is the package name for wpa_supplicant. In short, you need a WPA supplicant to do the actual connecting to an encrypted wireless network. It does the behind-the-scenes authenticating and feeds your card ESSIDs, PSKs, and other fun acronyms. wpa_supplicant runs as a daemon, working in concert with things like ifup and ifdown, and your /etc/network/interfaces file.
Since it appeared that the package was already installed as part of the "Laptop" task, I didn't have to do anything to have the daemon available. Checking /etc/wpa_supplicant/wpa_supplicant.conf informed me I'd need to fill in any wireless network connection information there, and I ended up with something similar to the following. Yours, of course, will be different. In this case, I have a WEP secured wireless network at my university that I use when I'm there. It's important to note that wpa_supplicant connects to open (plaintext) networks in addition to secured WEP and WPA/WPA2-Personal/Enterprise networks. eth1 is my wireless device.


wep_key1=1111111111 (this is an unquoted hex key)
wep_tx_keyidx=0 (this is the index of the key you wish to use)


Essentially, this sets up my university's network and a generic open wireless network, for places like public hotspots and coffee shops, and hotels and so on. The last entry is for a WPA-PSK/TKIP network. Setting ap_scan to 2 tells wpa_supplicant to cycle through the networks based on the priority value, with higher priority having preference over lower priority.
iface eth1 inet dhcp
pre-up wpa_supplicant -Bw -Dwext -ieth1 -c/etc/wpa_supplicant/wpa_supplicant.conf
post-down killall -q wpa_supplicant

-- OR --

iface eth1 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
wpa-driver wext
Either of the two stanzas above work for me. The former is a direct call to wpa_supplicant when the interface goes up and down, and is "cleaner" - that is, you can see the commands being run clearly. The latter relies on scripted parsing of the interfaces file. I've used both techniques without fail. If the one with wpa-conf doesn't work, try the "cleaner" method.

5.5 Alternative: Configuring NetworkManager

Another option for connectivity is NetworkManager. It basically attempts to give you an "always-on" connection - via wired or wireless devices connecting through D-BUS and HAL. It actually works really well, and there's a KDE applet for it too, which makes it extremely convenient for roaming around the WiFi world. All you need to do is install the required packages, comment out your /etc/network/interfaces file (except for the loopback device) and move your /etc/wpa_supplicant/wpa_supplicant.conf file somewhere safe. NetworkManager takes care of that stuff dynamically, generally saving you a bunch of hassle.
sudo usermod --append --groups netdev username
sudo aptitude install network-manager network-manager-kde wpasupplicant
/etc/network/interfaces should contain only:
auto lo
iface lo inet loopback
Reboot, and NetworkManager will be running. Fire up knetworkmanager and investigate the networks it finds. KNetworkManager doesn't currently seem to have an option to configure static IPs, and it forgets hidden wireless SSIDs, causing you to have to re-enter the SSID/key/security information each time you reboot. Other than that, it's peachy keen.

6. Power Management

6.1 Suspend with HAL

Suspending was sort of another issue, as is the case on many laptops - no matter the operating system. The default power management tools are hibernate, acpid, acpi-support and swsusp. I removed hibernate and KDE's laptop tools I had installed earlier,
sudo aptitude purge hibernate klaptop
and added kpowersave. It's a more than capable systray applet that used to be a frontend to powersave but changed to HAL's power management infrastructure somewhere a while ago. After I ran
sudo aptitude install kpowersave
sudo usermod --append --groups powerdev username
modprobe dcdbas
sudo echo "dcdbas" >> /etc/modules
then ran the application (for the terminally-challenged, it's located in Utilities in the K Menu), the icon appeared. I tried "Suspend To RAM" after knocking around the configuration options.
No go. The screen flashed a bit, and it turned off but didn't _stay_ off. I hunted around Google a bit to find the specific HAL quirks I'd need to use to get it to work properly, and I found them on the HAL info page. I needed to use
to get a proper suspend. After trying to figure out how to integrate them into kpowersave's suspend to RAM command or stick them in environment variables, or SOMETHING that wasn't a kludge, I gave up and just put them into the HAL script itself. I hate it, but it works. Clicking "Suspend to RAM" in kpowersave works very well now, as does automatic suspend.
# Make a suitable command line argument so that the tools can do the correct
# quirks for video resume.
# Passing the quirks to the tool allows the tool to not depend on HAL for data.
QUIRKS="--quirk-s3-bios --quirk-vbe-post"

6.2 Suspending with ACPI

Doing a manual suspend was no issue at all with the installed tools. Running
directly worked with no problems. It's also a clean, uncluttered script and easily modified. Why this method isn't in kpowersave, I'll never know. Future patch for alternate suspend methods, anyone interested?
To avoid any future problems with certain drivers, I put them in acpi-support's RELOAD_MODULES variable.
RELOAD_MODULES="ndiswrapper b44"

6.3 Power Button and Lid Switch

I prefer that the power button as well as opening and closing the lid suspends my machine. This accomplished by simply adding the sleep script's path to a few places:
# existing script contents...
# action=/etc/acpi/
# existing script contents...
if [ `CheckPolicy` = 0 ]; then exit; fi

grep -q closed /proc/acpi/button/lid/*/state
if [ $? = 0 ]
After a reboot fueled by laziness, suspending and waking up the machine worked perfectly! Everything was restored and any clock skew from suspending was fixed. My wifi took a few seconds to come back up, but it did. Even the lid switch worked.

6.4 LCD Brightness

After I posted this HOWTO, a very kind person sent in a creative way to control the brightness of the LCD.

This set of tips and scripts is from Gibi:
"dell-brightness contains the definition of the up key to put in /etc/acpi/events/.
Restarting acpid the daemon will execute when you press the fn+up key. changes the brightness. Without a parameter it loops through the levels starting from the actual level.
With up it increases and down decreases the brightness." (place in /etc/acpi)
dell-brightness (place in /etc/acpi/events)

Hopefully, someone has found this helpful. Thanks for reading, and I'd like to again extend my offer for suggestions and new information. Contact information can be found at the top, in the introductory section.