Since I’ve opted to give up Windows entirely, I’ve lost quite a few of the ‘not-quite-necessities’ I once had. One of those things was the ability to update the microcode within my computer to support updates and fixes. Well, no more! Thank you, Dell.

Below is a small tutorial on how to use prebuilt packages in Ubuntu Feisty Fawn, but should work 100% with Debian Etch, my laptop’s former OS.

Note that when I prepend a line with a ‘%’, that means you open a terinal and do it at the prompt; yours may look different. That’s fine. Everything should just work. This MAY NOT WORK IF YOU KILLED YOUR DELL BIOS SUPPORT PARTITION; YOU HAVE BEEN WARNED! :)

First of all, you’ll need to install the smbios support libraries; these are available within the Ubuntu repositories:

%sudo apt-get install libsmbiosxml1 libsmbios-bin libsmbios1

Next, you’re going to need the firmware-tools and firmware-addon-dell packages. I’ve built my own from Dell’s etch build sources. These are for IA32, if you need x64, that’s a directory up, and sorry, I can’t offer those, I do not have an x64 installation to test with.

You may use my i386 builds if you wish, I’ve signed my debs, you can check them with dpkg-sig:

%wget http://www.holwegner.com/files/firmware-addon-dell_1.2.13-1_i386.deb
%wget http://www.holwegner.com/files/firmware-tools_1.2.6-1_all.deb

You can get my key and add it to your keyring:

%gpg --keyserver wwwkeys.eu.pgp.net --recv-keys F8C314E3
gpg: requesting key F8C314E3 from hkp server wwwkeys.eu.pgp.net
gpg: key F8C314E3: public key "Shawn Holwegner (GPG Signing Key) <me@mydomain.com>" imported (edited to thwart spambots)
%gpg --armor --export F8C314E3 | sudo apt-key add -
OK

Now, you can check my signature; I’ve tagged both as ‘feisty’ (Note that I have left the response of GPG here so you can ensure they match):

%dpkg-sig -c firmware-addon-dell_1.2.13-1_i386.deb
Processing firmware-addon-dell_1.2.13-1_i386.deb...
GOODSIG _gpgfeisty 743D4D271144FB13C788D9F3B4B33515F8C314E3 1181453286
%dpkg-sig -c firmware-tools_1.2.6-1_all.deb
Processing firmware-tools_1.2.6-1_all.deb...
GOODSIG _gpgfeisty 743D4D271144FB13C788D9F3B4B33515F8C314E3 1181453298

Now, if you trust me, install them:

%sudo dpkg -i firmware-tools_1.2.6-1_all.deb firmware-addon-dell_1.2.13-1_i386.deb

Find out your system ID. Note that this is the area in bold:

%sudo getSystemId
Libsmbios:    0.12.1
System ID:  0x01BD
Service Tag:  6H5GMB1
Express Service Code: 14097792493
Product Name: MM061
BIOS Version: A11
Vendor:       Dell Inc.
Is Dell:      1

Go to http://linux.dell.com/repo/software/bios-hdrs/ and find your system, the directory will be something awfully messy, like system_bios_ven_0×1028_dev_SYSTEM_ID_version_THE_BIOS_VERSION. In the case of my Inspiron 6400, mine was: system_bios_ven_0×1028_dev_0×01bd_version_a15 for my System ID of 0×01BD and BIOS version A15.

Download the “bios.hdr” file from that directory.

%wget http://where/your/bios/is/bios.hdr

Load the “dell_rbu” support module into the kernel:

%sudo modprobe dell_rbu

Finally, flash the BIOS:

%sudo dellBiosUpdate -u -f ./bios.hdr
Supported RBU type for this system: (MONOLITHIC)
Using RBU v2 driver. Initializing Driver. 
Setting RBU type in v2 driver to: MONOLITHIC
Prep driver for data load.
Writing RBU data (4096bytes/dot): ............................
..............................................................
.......................
Notify driver data is finished.
Activate CMOS bit to notify BIOS that update is ready on next boot.
Update staged sucessfully. BIOS update will occur on next reboot.

Now, when you reboot, the system will flash to the BIOS you’ve downloaded, and reboot. Enjoy your new BIOS, I’m enjoying the microcode updates in A15 as I type this! ;)

I've always opted to login to my server and use the good old fashioned textarea entry; however, with the stability of TextPattern's XML-RPC library, I figured I'd give BloGTK a try.

It's fairly basic, but it works rather well, despite my personal belief that UI interfaces and scripting languages are best left as seperate entities.

So, now I can join the myraid of others who use the internet as their mental grocery list.. This is progress, I suppose.

Ok, it died twice again, worked 3 times back at home, and died 4 more when out and about. I give up on this mess.. If I need wireless, elsewhere, I’ll make another config file. NetworkManager is too flaky; the system constantly reloads the ipw3945 driver before wpa_supplicant has had a chance to associate… and the prior version of ipw3945 is unloaded (due in part to the user-level daemon which is required.. thank you Intel..)

So, here’s my (hopefully final) workaround:

/etc/network/interfaces:

auto eth1
iface eth1 inet dhcp
pre-up          /etc/init.d/wifi_wpa.sh start
pre-down      /etc/init.d/wifi_wpa.sh stop

/etc/init.d/wifi_wpa.sh:

#!/bin/sh

PATH=/bin:/usr/bin:/sbin:/usr/sbin

BIN=/sbin/wpa_supplicant

PIDFILE=/var/run/wpa_supplicant.pid


  . /lib/lsb/init-functions

	
case “$1” in
  start)

if [ -x /sbin/wpa_supplicant ]; then
  $BIN -ieth1 -c /etc/wpa_supplicant.conf -Dwext -w -P $PIDFILE 2>&1 &

fi
    ;;
  stop)
    killall wpa_supplicant
    ;;
  *)
    ;;

esac

exit 0

/etc/wpa_supplicant.conf:

network={
  ssid="MYSSID"
  scan_ssid=1
  psk="MYPSK"
}

/etc/acpi/suspend.d/95-iface-down.sh:

#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin
/sbin/ifdown eth1

/etc/acpi/resume.d/95-iface-up.sh:

#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin
#Just to be sure
/sbin/ifdown eth1
sleep 2
/sbin/ifup eth1

Yes, it takes an extra 4 seconds to startup, but damn it, it works without fail. Anyone who’s been dealing with this mess at all, I strongly suggest ‘apt-get —purge remove network-manager’ ;)

I’ve heard many things over the years about Ubuntu.. heck, I even passed out a few of their ‘free’ CDs in ’05 (Hoary, 5.04). It worked great.

However, I’ve recently attempted to adopt it on a fledgling Laptop which was just becoming more of a nuisance to try to keep running than was worth the time invested.

When reading through documents for others who attempting to do the same, it shocked me at how lacking support was in Linux for nearly three year old commodity parts. Ubuntu, the first Linux distribution I actually had a specific reason to distrust (They imported alpha grade drivers, which were at version 0.1 and known to cause crashes into the mainstream), was now not enabling proprietary drivers in their default install.

This, of course, meant that their pretty little installer crashed. Hard.

I ended up installing Ubuntu via apt and wired ethernet. It was more of a pain than getting Debian running.. and Debian tends to scare people away.

The one thing I did like is that Ubuntu’s Gnome ‘Network Manager’ applet actually worked with my ipw3945, and the fglrx driver could be tweaked so I could shut my machine down.

However, upon waking, it still broke the ipw3945. That worked fine for everything else. Oh well.

Here’s my ugly little script I used to reload/reinit the ipw3945 if it crashed, restarting the userspace daemon, and firing off wpa_supplicant, since it never seems to return after sleeping, even if I let it keep the network module loaded:

/etc/acpi/resume.d/70-fixwifi.sh:

#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin
# This script is naaasty...
/etc/init.d/networking stop
REVISION=/sbin/ipw3945d-`uname -r`
ISRUNNING=`pidof $REVISION`
rmmod ipw3945 > /dev/null 2&>1
if [ $? -eq 0 ]; then
  modprobe -r -f ipw3945
  modprobe ipw3945
fi
if [ x$ISRUNNING -eq x ] && [ -x $REVISION ]; then
  $REVISION --quiet
  sleep 2s
fi
WPA=`wpa_cli status | awk -F= ' /wpa_state/ { print $2 }'`
#start everything back up
if [ x$WPA -ne xCOMPLETED ]; then
  # I really hate this, but it's not worth beautifying right now
  killall wpa_supplicant
  /etc/init.d/wpa_start.sh &
  # wait for it
  sleep 5s
fi
/etc/init.d/networking start
/sbin/ifup eth1

/etc/init.d/wpa_start.sh:

#!/bin/sh
ISRUNNING=`pidof wpa_supplicant`
if [ x$ISRUNNING -eq x ]; then
  wpa_supplicant -i eth1 -c \
  /etc/wpa_supplicant.conf -Dwext -w
fi

/etc/wpa_supplicant.conf:

network={
  ssid="MY SSID"
  scan_ssid=1
  psk="MY_WPA_KEY"
}

What it does is test to see if the wireless is loaded, and if so, attempt to remove it. If it is successful (not in use), force unload (why not?) then reload the module. If the userspace daemon isn’t running, fire it off. Finally, take a little nap while wpa_supplicant inserts itself, then fire off networking.

It’s obnoxious, and annoying (note that I hardcoded the interface of eth1), but there seems to be no way of getting nm-applet to properly reinit the interface, itself.

Although when connected, it does still measure the signal and allow me to switch, so that’s good enough for me.

I’ve found yet another oddity. Rather, gcc pointed it out to me, because I wasn’t paying too much attention.

this current patch which should fix RAM resume and suspend problems in 2.6.21.

It modifies the subroutine as follows:

static void tick_resume(int broadcast)
{
        struct tick_device *td = &__get_cpu_var(tick_cpu_device);
        unsigned long flags;
        int broadcast = tick_resume_broadcast();

If you don’t read nerd (or C), this is saying “Ok, so, you told me
what ‘broadcast’ is, but I’m going to ignore that and figure it out, myself.” A bit strange logic, that.

However, there is a proposed update which clears up some of this mess.

Ugh. I miss FreeBSD at times.