Bending the old house to suit

OK, we love our new old house, but two 13-watt CFLs in the kitchen just didn’t cut it.  Last week, we put up a rather modern-looking 6-lamp halogen Z-bar in the center, which lets us actually see what we are cleaning and cooking.

But, the pale moon over the breakfast nook is just that, pale.  So, back to the store, where we pick out a nice pendant light with a ribbed glass shade that speaks more to the period of the house and the metal matches the light bar, more or less.  Dropping the old light, we find what we expected, wires poking out of the textured beaverboard.  but, at least, no gaping hole in the board and the ceiling is finished right up to the wires.  So, we trot down to our friendly neighborhood Ace Hardware yet again, for yet another rework box.  I trace around it on the ceiling, cut a circle with my trusty Leatherman knife, and pry out a chunk of beaverboard.  The box fits snugly in the hole, flush with the ceiling, and even has a joist to screw it into.

After fighting with the lamp for a reasonable time for an unsupervised DIYer (Judy was off to a quilt guild committee meeting), I read the directions, put the mounting screws in the holes they were supposed to  go in,  remove one of the pendant rod sections to put the lamp at the desired height, rethread the wires, and Wow! we have a right handsome light.  Using the same 13W CFL, which is now two feet closer to the table, we have sufficient light on the table.  Life is good.    Next week, we need to take down the bar light and patch the ugly hole in the ceiling and surrounding texturing.

Curiouser and Curiouser — Wifi at last?

OK, another mystery.  I added the patch from the CD, added DKMS from the CD, added the bcmwl-kernel-source package, which crashed the system.  Backed out the bcmwl-kernel package.  Then, recompiled the STA driver downloaded from Broadcom, cleaned up the /etc/init.d/wifi.sh script, dropped and reloaded the newly compiled wl module, restarted networking, and voila! , the blue light blinks red and blue and the wireless interface is now working.  But, wifi-radar still can’t connect.

Browsing around for a different approach, I find that Ubuntu 9.10 comes with the latest and greatest version of Gnome Network Manager.  Hey, maybe that’s what that little antenna symbol in the top toolbar is…  Click, I can see the network offered; click, and I’m connected!  Whoof.  Almost an entire week since we started this upgrade, and five days of fighting with drivers and configurations, and we are back mobile-prepared again, just hours  before starting on our week-long road trip.  Now, if it will only survive a reboot…

Your mileage may vary (Linux tips)

The battle for wireless connectivity continues.  The mystery of the system crashes is at least revealed, if not understood.  A blog by Alvonsius indicated there is a package on the Karmic Koala install disk that will enable Broadcom adapters:  bcmwl-kernel-source.   I had installed it (from web archives, not the disk) on Saturday, which instigated the video lockups (go figure!). Last night, I rediscovered this helpful hint and applied it, upon which the system crashed a few minutes after logging in.

OK, back to single-user (recovery) mode, remove the offending package, and reboot.  The system is once more stable.  Now, the next step is to remove the driver obtained directly from Broadcom and the scripts that load it, and try again with the Ubuntu package.  Now, the other day, when the crashing and burning started, it was some time after unsuccessfully trying the bcmwl package on an updated system, so the fix was not quite so obvious.

Meanwhile, I am getting a lot of flack from other members of the household about choosing to use a “one-off” system like Linux.  Now, these are professional people, but not computer people.  Like most of the world, they don’t seem to understand that a computer system isn’t just a single machine, but a system representing an entire population of generations of software writers, so its behavior is just as unpredictable in specific instances as that of an unruly crowd.  The world of Microsoft and Windows is more or less totalitarian, so that users’ actions are restricted and the shortcomings of the system are hidden behind barriers of state secrecy.  In the Open Systems world, there is a lot more freedom, but there also isn’t always a cop around when you need one.  But, then, you do have the option to take matters into your own hands and deal with the problem.  Which is OK if you have the tools and knowledge it takes.  On the other hand, in the world of proprietary software, the danger is much like that in totalitarian societies: if you are being beaten and robbed, it is no use calling the police–they are already there.

Linux Wireless: the saga continues

The Great Ubuntu Upgrade project has been underway for nearly a week now.  the upgrades to 9.04 went absolutely smoothly–almost everything worked afterwords (printers and drivers needed to be reinstalled).  But, I upgraded my Compaq C714NR to 9.10 on Friday, and did a fresh install on Sunday, with the ensuing gigabytes of system patches and additional package installs to restore essential functionality to my development system,  and still no wireless.  This particular model, along with a few others that use the Broadcom wireless chips, have been the bane of the Linux users’ existence.  With diligence, one can get the wireless networking to function, but it is never clean or straight-forward.

Today, we even resorted to booting Windows Vista (and suffering through the six months of upgrades since we last booted it) just to make sure we had the wireless chip turned on.  But, this time, when we rebooted to Linux, the red light was on.  One of the most frustrating parts of the whole roll-your-own solution and follow the footsteps of others–who have had a slightly different model chipset and on a different version of Ubuntu–is that is is really easy to make things worse.

The Broadcom STA driver is an abomination.  It compiles, and you can insmod it and talk to the chips, but removing the b43 and ssb drivers and trying to use just the wl driver gets nothing.  The Broadcom documentation is essential a demo version–the procedure is not persistent through a reboot.  I finally reinstated the b43 and ssb drivers, booted, removed those drivers, and did a manual insmod,  on wl, per the Broadcom README, and I got a blue light, and can even do iwlist scanning, but the dhcpclient still won’t talk to the chip.  In this current episode, I used a modified version of Sampbar’s (Samuel Barrett) procedure for 8.04, and created a script that allows the b43 and ssb drivers to load to turn on the chip, then dumps them and substitutes the wl driver.  Looks good, but still doesn’t work.

One of the issues is that, despite all the messages to the forums and helpful hints, I haven’t found a comprehensive documented guide to the design of the networking startup process so we know what is happening where and when.  The /etc/network/interfaces file has a lot to do with the configuration, but doesn’t seem to be the whole answer.  The device driver modules have everything to do with it, but also interact with a lot of  other utilities.

Wifi-radar I have used for some time, but have never actually gotten it to work–I always end up fiddling with the network settings and just use wifi-radar to verify I have connections.  Looking more closely this time, it looks like the default settings in wifi-radar apply to a machine with a DHCP server, not the client.  Lots of tweaking with very little guidance.

The path of least resistance seems to be to get away from the Broadcom chipset altogether and get a USB wifi adapter.  But, the mileage with those seems to vary also–some folks say it works out of the box (or at least imply that installation was “normal,” which could include ndiswrapper setup or that the drivers were in Linux already).  Looking through the specs on various manufacturer’s adapaters, it appears that slightly different models or even production runs of the “same” model may have different chipsets in them, some of which work with Linux and some of which don’t.

Essentially, this miasma is created by the open standard to which the “PC” class of Intel/AMD machines are built.  When you buy a machine from Sun or Apple, it just plain works out of the box, but you can’t add anything to it that isn’t in the hardware compatibility list for the OS (Solaris or OS/X)–it is guaranteed not to work.  Only devices with tested and certified drivers will work with these machines.  Now, Unix generally expects devices and device drivers to be solid and well-behaved,  since they link with the kernel, so this seems to be a very good plan.  On the other hand, vendors make a lot of money just grinding out Windows drivers for their proprietary chipsets.  Supplying drivers for Linux means a couple of things:  1) the code is open, which then reveals the chip settings and the design of the device, and 2) the devices need to be well-behaved and the drivers written to cover all cases without locking up or crashing.

So it goes. the outcomes of this diversion is yet to be concluded.  One of the things we did learn was that you really shouldn’t keep upgrading a highly-customized machine.  Eventually, it becomes necessary to backup the data, clean off the machine, and start over.  There are a number of glitchy problems that have been observed in 9.10 that seem to be related more to upgrading from earlier versions:  The panics and black screens and graphics blowups that evolved as we fought with the wireless driver issues have not resurfaced with the fresh install.  But, the “powersave click” started up right from the install CD boot, requiring tweaking the modprobe.d configuration file for the sound card.

So, what’s next?  I may decide to try one of the more stable industrial-strength distros, like CentOS, which I have used in clusters and production servers, as the base system, and run Ubuntu and other distros as virtual machines.  A new machine is not yet in the budget, but a new disk drive and more RAM will run about $100, which would provide enough power to do virtualization.

Ubuntu and Laptops

In an earlier thread, I mentioned I was going to upgrade our Ubuntu versions.  Well, I had been putting it off because you never know what cans of worms you are going to open when you do that.

One of the problem children in the Linux world in general has been Wi-Fi.  It seems everyone makes Windows drivers for their hardware, but a lot of them don’t support Linux.  Our laptop, a Compaq C714NR, has a Broadcom 4311 chipset in it, which has been a struggle.  Through three or four iterations of Ubuntu, we have managed to get it working [most of the time] by using ndiswrappers and the Windows XP drivers.  Well, with Ubuntu 9.10 (Karmic Koala), Broadcom has finally got with the program and provided buildable sources for Linux.  But, that said, their track record for solid results has been less than stellar.  I’m still working the problem, but I did get the new Broadcom drivers built and loaded.  The main issue is getting rid of all the ndiswrapper stuff and a plethora of helpful scripts and settings provided by others, for various previous versions of Ubuntu.

In the middle of the WiFi issue, my machine went into a kernel panic, evidenced by a sudden blank screen a few minutes after logging in and a blinking Caps Lock light on the keyboard.  Booting to recovery mode (what us old-time Unixers call Single-User Mode) allows one to fix driver issues in command-line mode.  After some tweaking of the startup scripts, rebooting went to command-line mode right away.  A few more adjustments, and the Gnome desktop came back next boot–for about 30 seconds, giving way to an almost-blank screen with “LVDS-8 setmode 1280×800 17” displayed in the upper left of the screen, no flashing Caps Lock…  A ‘Net search produced yet another /etc/modprobe.d script to set the video mode — seems there is some instability in the video settings.

Now, you might think that Linux isn’t any better than Windows in terms of grief.  But, this is more an issue of too many different configurations to test and not a lot of tight specifications to test to.  Being open source, these things get discussed by a lot of smart people and fixed fairly promptly, as long as they come to the attention of someone who understands the issues–like driver developers and other systems programmers who contribute to the various distributions or to the kernel code base.

But, I digress.  Meanwhile, looking through the dmesg output, it appears that the wifi is working just fine, but I still haven’t been able to wean the machine off its Ethernet cable.  With a road trip coming up in a few days, it is imperative to get the wifi up and running, or look for another alternative.  The latter is not a good prospect because of the huge number of add-on packages and custom software integrated into my system, it would take weeks to teach a fresh install to do all the things the current configuration could do–if we can keep it running and on-line…

Musings on Unix, Bicycling, Quilting, Weaving, Old Houses, and other diversions

%d bloggers like this: