Shallow Thoughts

How to set your time zone

My laptop's clock has been drifting. I suspect the clock battery is low (not surprising on a 7-year-old machine). But after an hour of poking and prodding, I've been unable to find a way to expose the circuit board under the keyboard, either from the top (keyboard) side -- though I know how to remove individual keycaps, thanks to a reader who sent me detailed instructions a while back (thanks, Miles!) -- or the bottom. Any expert on Vaio SR laptops know how this works?

Anyway, that means I have to check and reset the time periodically. So this morning I did a time check and found it many hours off. No, wait -- actually it was pretty close; it only looked like it was way off because the system had suddenly decided it was in UTC, not PDT. But how could I change that back?

I checked /etc/timezone -- sure enough, it was set to UTC. So I changed that, copying one from a debian machine -- "US/Pacific", but that didn't do it, even after a reboot.

I spent some time reading man hwclock -- there's a lot of good reading in that manual page, about the relation between the system (kernel) clock and the hardware clock. Did you know that you're not supposed to use the date command to set the system time while the system is running? Me neither -- I do that all the time. Hmm. Anyway, interesting reading, but nothing useful about the system time zone.

It has an extensive SEE ALSO list at the end, so I explored some of those documents. /usr/share/doc/util-linux/README.Debian.hwclock is full of lots of interesting information, well worth reading, but it didn't have the answer. man tzset sounded promising, but there was no such man page (or program) on my system. Just for the heckofit, I tried typing tz[tab] to see if I had any other timezone-related programs installed ... and found tzselect. And there was the answer, added almost as an afterthought at the end of the manual page:

Note that tzselect will not actually change the timezone for you. Use 'dpkg-reconfigure tzdata' to achieve this.

Sure enough, dpkg-reconfigure tzdata let me set the time zone. And it even seems to be remembered through a reboot.

Tags: linux, debian, ubuntu, vaio
[ 10:04 May 16, 2008    More linux | permalink to this entry ]

Upgrading from Ubuntu Gutsy to Hardy

I finally had a moment to upgrade my desktop to Ubuntu's "Hardy Heron". I followed the same procedure as when I went from feisty to gutsy:

1. cp -ax / /hardy
2. cp -ax /dev/.static/dev/* /hardy/dev/
3. Fix up files like /hardy/etc/fstab and /boot/grub/menu.lst
4. Reboot into the newly copied gutsy
5. do-release-upgrade -d

It took an hour or two to pull down all the files, followed by a long interval of occasionally typing Y or N, and then I was ready to start cleaning up some of the packages I'd noticed flying by that I didn't want. Oops! I couldn't remove or install anything with apt-get, because: dpkg --configure -a
But I couldn't dpkg --configure -a because several packages were broken.

The first broken package was plucker, which apparently had failed to install any files. Its postinstall script was failing because it had no files to operate on; and then I couldn't do anything further with it because apt-get wouldn't do anything until I did a dpkg --reconfigure -a

I finally got out of that by dpkg -P plucker; then after several more dpkg --reconfigure -a rounds I was eventually able to apt-get install plucker (which installed just fine the second time).

But apt still wasn't happy, because it wanted to run the trigger for initramfs-tools, which wouldn't run because it wanted kernel modules for some specific kernel version in /lib/modules. I didn't have any kernel modules because I'm not running Ubuntu's kernel (I'm stuck on 2.6.23 because bug 10118 makes all 2.6.24 variants unable to sync with USB Palm devices). But I couldn't remove initramfs-tools because udev (along with a bunch of other less important packages) depends on it. I finally found my way out of that by removing /var/lib/dpkg/triggers/initramfs-tools. I reported it as bug 220094.

Update: I forgot to mention one important thing I hit both on this machine and earlier, on the laptop: /usr/bin/play (provided by the "sox" package) no longer works because it now depends on a zillion separate libraries. apt-get install libsox-fmt-all to get all of them.

Tags: linux, ubuntu, debian, install
[ 20:02 Apr 20, 2008    More linux/install | permalink to this entry ]

Debootstrap

Some time ago, I wished for a simple Linux "Tarball installer", something that could install a minimal install of a Linux distribution onto an existing partition or directory, skipping all the flaky and error-prone hardware-guessing that installers do.

It turns out Debian (and therefore also Ubuntu) has had this for years, and it's totally cool. It's called debootstrap.

Some folks on the #ubuntu+1 channel told me about it, and I found a nice clear howto article on how to use it for Debian. It works just the same for Ubuntu.

First, get the .deb package for the debootstrap you want to use. Here's debootstrap for Ubuntu Hardy Heron. Install it with dpkg -i. Then run it, giving it the name of the system you want to install and the directory (or mounted partition) where you want to install it. Like this: debootstrap hardy /mnt/hda3

That's all! It fetches the files it needs from the online repositories. It takes no time at all -- this really is a minimal system.

Then you need to do some fiddling to turn it into a bootable system. That includes (all paths relative to the newly installed filesystem unless otherwise stated):

• Set up etc/fstab to list the fileystems on the disk, and to mount / from the filesystem you just installed
• Define the hostname in etc/hostname
• Set up a grub boot stanza in /boot/grub/menu.lst (that's /boot on the current system, which should be the same as /boot in the new fstab you just created). Use whatever kernel you were using for your old system, for now.

Now you're read to reboot into the new system. Of course, since this is a very minimal system, you have a lot more work to do. Hardly anything is installed, and nothing has been configured for you. Some things may be challenging (for example, as I write this, X is installed but most of the fonts aren't showing up properly, which may be a bug in Hardy).

Anyway, you can get a good start by mounting your old system's root directory and copying some starter files from there, starting with these:

• Set up your important configuration files: /etc/network/interfaces, /etc/hosts, /etc/resolv.conf, /etc/passwd etc.
• edit /etc/apt/sources.list to include restricted universe multiverse
• Install a kernel package if you're using distro kernels
• Install vim if you're a vim user -- remember, ubuntu comes with something called vim that isn't really vim.
• Create users and homedirs and such
• Install all the other stuff you want -- X, gimp/gtk, development tools, editors, shells -- all that stuff that makes the system feel like home. You're on your own there, so have fun!

Tags: linux, debian, installer
[ 12:54 Apr 06, 2008    More linux/install | permalink to this entry ]

The Importance of Being ESSID (simple Linux wi-fi troubleshooting)

I'm forever having problems connecting to wireless networks, especially with my Netgear Prism 54 card. The most common failure mode: I insert the card and run /etc/init.d/networking restart (udev is supposed to handle this, but that stopped working a month or so ago). The card looks like it's connecting, ifconfig eth0 says it has the right IP address and it's marked up -- but try to connect anywhere and it says "no route to host" or "Destination host unreachable".

I've seen this both on networks which require a WEP key and those that don't, and on nets where my older Prism2/Orinoco based card will connect fine.

Apparently, the root of the problem is that the Prism54 is more sensitive than the Prism2: it can see more nearby networks. The Prism2 (with the orinoco_cs driver) only sees the strongest network, and gloms onto it. But the Prism54 chooses an access point according to arcane wisdom only known to the driver developers. So even if you're sitting right next to your access point and the next one is half a block away and almost out of range, you need to specify which one you want. How do you do that? Use the ESSID.

Every wireless network has a short identifier called the ESSID to distinguish it from other nearby networks. You can list all the access points the card sees with:

iwlist eth0 scan

(I'll be assuming eth0 as the ethernet device throughout this article. Depending on your distro and hardware, you may need to substitute ath0 or eth1 or whatever your wireless card calls itself. Some cards don't support scanning, but details like that seem to be improving in recent kernels.)

You'll probably see a lot of ESSIDs like "linksys" or "default" or "OEM" -- the default values on typical low-cost consumer access points. Of course, you can set your own access point's ESSID to anything you want.

So what if you think your wireless card should be working, but it can't connect anywhere? Check the ESSID first. Start with iwconfig:

iwconfig eth0

iwconfig lists the access point associated with the card right now. If it's not the one you expect, there are two ways to change that.

First, change it temporarily to make sure you're choosing the right ESSID:

iwconfig eth0 essid MyESSID

If your accesspoint requires a key, add key nnnnnnnnnn to the end of that line. Then see if your network is working.

If that works, you can make it permanent. On Debian-derived distros, just add lines to the entry in /etc/network/interfaces:

wireless-essid MyESSID
wireless-key nnnnnnnnnn

Some older howtos may suggest an interfaces line that looks like this:
up iwconfig eth0 essid MyESSID
Don't get sucked in. This "up" syntax used to work (along with pre-up and post-up), but although man interfaces still mentions it, it doesn't work reliably in modern releases. Use wireless-essid instead.

Of course, you can also use a gooey tool like gnome-network-manager to set the essid and key. Not being a gnome user, some time ago I hacked up the beginnings of a standalone Python GTK tool to configure networks. During this week's wi-fi fiddlings, I dug it out and blew some of the dust off: wifi-picker.

You can choose from a list of known networks (including both essid and key) set up in your own configuration file, or from a list of essids currently visible to the card, and (assuming you run it as root) it can then set the essid and key to whatever you choose. For networks I use often, I prefer to set up a long-term network scheme, but it's fun to have something I can run once to show me the visible networks then let me set essid and key.

Tags: linux, net, debian, ubuntu
[ 14:44 Aug 18, 2007    More linux | permalink to this entry ]

Etch: Blacklisting Modules, Udev, and Firewire Networking

The new Debian Etch installation on my laptop was working pretty well. But it had one weirdness: the ethernet card was on eth1, not eth0. ifconfig -a revealed that eth0 was ... something else, with no IP address configured and a really long MAC address. What was it?

Poking around dmesg revealed that it was related to the IEEE 1394 and the eth1394 module. It was firewire networking.

This laptop, being a Vaio, does have a built-in firewire interface (Sony calls it i.Link). The Etch installer, when it detected no network present, had noted that it was "possible, though unlikely" that I might want to use firewire instead, and asked whether to enable it. I declined.

Yet the installed system ended up with firewire networking not only installed, but taking the first network slot, ahead of any network cards. It didn't get in the way of functionality, but it was annoying and clutters the output whenever I type ifconfig -a. Probably took up a little extra boot time and system resources, too. I wanted it gone.

Easier said than done, as it turns out.

I could see two possible approaches.

1. Figure out who was setting it to eth1, and tell it to ignore the device instead.
2. Blacklist the kernel module, so it couldn't load at all.

I begain with approach 1. The obvious culprit, of course, was udev. (I had already ruled out hal, by removing it, rebooting and observing that the bogus eth0 was still there.) Poking around /etc/udev/rules.d revealed the file where the naming was happening: z25_persistent-net.rules.

It looks like all you have to do is comment out the two lines for the firewire device in that file. Don't believe it. Upon reboot, udev sees the firewire devices and says "Oops! persistent-net.rules doesn't have a rule for this device. I'd better add one!" and you end up with both your commented-out line, plus a brand new uncommented line. No help.

Where is that controlled? From another file, z45_persistent-net-generator.rules. So all you have to do is edit that file and comment out the lines, right?

Well, no. The firewire lines in that file merely tell udev how to add a comment when it updates z25_persistent-net.rules. It still updates the file, it just doesn't comment it as clearly.

There are some lines in z45_persistent-net-generator.rules whose comments say they're disabling particular devices, by adding a rule GOTO="persistent_net_generator_end". But adding that in the firewire device lines caused the boot process to hang. There may be a way to ignore a device from this file, but I haven't found it, nor any documentation on how this system works.

Defeated, I switched to approach 2: prevent the module from loading at all. I never expect to use firewire networking, so it's no loss. And indeed, there are lots of other modules loaded I'd like to blacklist, since they represent hardware this machine doesn't have. So it would be nice to learn how.

I had a vague memory of there having been a file with a name like /etc/modules.blacklist some time back in the Pliocene. But apparently no such file exists any more. I did find /etc/modprobe.d/blacklist, which looked promising; but the comment at the beginning of that file says

# This file lists modules which will not be loaded as the result of
# alias expsnsion, with the purpose of preventing the hotplug subsystem
# to load them. It does not affect autoloading of modules by the kernel.

Okay, sounds like this file isn't what I wanted. (And ... hotplug? I thought that was long gone, replaced by udev scripts.) I tried it anyway. Sure enough, not what I wanted.

I fiddled with several other approaches before Debian diva Erinn Clark found this helpful page. I created a file called /etc/modprobe.d/00local and added this line to it:

install eth1394 /bin/true

and on the next boot, the module was no longer loaded, and no longer showed up as a bogus ethernet device. Hurray!

This /etc/modprobe.d/00local technique probably doesn't bear examining too closely. It has "hack" written all over it. But if that's the only way to blacklist problematic modules, I guess it's better than nothing.

Tags: linux, debian, kernel, net
[ 18:10 May 15, 2007    More linux | permalink to this entry ]

Debian "Etch": a Sketch

Since I'd already tried the latest Ubuntu on my desktop, I wanted to check out Debian's latest, "Etch", on my laptop.

The installer was the same as always, and the same as the Ubuntu installer. No surprises, although I do like the way Debian gives me a choice of system types to install (Basic desktop, Web server, etc. ... though why isn't "Development" an option?) compared to Ubuntu's "take the packages we give you and deal with it later" approach.

Otherwise, the install went very much like a typical Ubuntu install. I followed the usual procedures and workarounds so as not to overwrite the existing grub, to get around the Vaio hardware issues, etc. No big deal, and the install went smoothly.

The good

But the real surprise came on booting into the new system. Background: my Vaio SR-17 has a quirk (which regular readers will have heard about already): it has one PCMCIA slot, which is needed for either the external CDROM drive or a network card. This means that at any one time, you can have a network, or a CDROM, but not both. This tends to throw Debian-based installers into a tizzy -- you have to go through five or more screens (including timing out on DHCP even after you've told it that you have no network card) to persuade the installer that yes, you really don't have a network and it's okay to continue anyway.

That means that the first step after rebooting into the new system is always configuring the network card. In Ubuntu installs, this typically means either fiddling endlessly with entries in the System or Admin menus, or editing /etc/network/interfaces.

Anticipating a vi session, I booted into my new Etch and inserted the network card (a 3COM 3c59x which often confuses Ubuntu). Immediately, something began spinning in the upper taskbar. Curious, I waited, and in ten seconds or so a popup appeared informing me "You are now connected to the wired net."

And indeed I was! The network worked fine. Kudos to debian -- Etch is the first distro which has ever handled this automatically. (I still need to edit /etc/network/interfaces to set my static IP address -- network manager

Of course, since this was my laptop, the next most important feature is power management. Happily, both sleep and hibernate worked correctly, once I installed the hibernate package. That had been my biggest worry: Ubuntu was an early pioneer in getting ACPI and power management code working properly, but it looks like Debian has caught up.

The bad

I did see a couple of minor glitches.

First, I got a lot of system hangs in X. These turned out to be the usual dri problem on S3 video cards. It's a well known bug, and I wish distros would fix it!

I've also gotten at least one kernel OOPS, but I have a theory about what might be causing that. Time will tell whether it's a real problem.

It took a little googling to figure out the line I needed to add to /etc/apt/sources.list in order to install programs that weren't included on the CD. (Etch automatically adds lines for security updates, but not for getting new software). But fortunately, lots of other people have already asked this in a variety of forums. The answer is:

deb http://http.us.debian.org/debian etch main contrib non-free

My husband had suggested that Etch might be lighter weight than Ubuntu and less dependent on hal (which I always remove from my laptop, because its constant hardware polling makes noise and sucks power). But no: Etch installed hal, and any attempt to uninstall it takes with it the whole gnome desktop environment, plus network-manager (that's apparently that nice app that noticed my network card earlier) and rhythmbox. I don't actually use the gnome desktop or these other programs, but it would be nice to have the option of trying them when I want to check something out. So for now I've resorted to the temporary solution: mv /usr/sbin/hald /usr/sbin/hald-not

The ugly

Etch looks fairly nice, and I'm looking forward to exploring it. I'm mostly kidding about the "ugly". I did hit one minor bit of ugliness involving network devices which led me on a two-hour chase ... but I'll save that for its own article.

Tags: linux, debian, vaio
[ 13:29 May 15, 2007    More linux | permalink to this entry ]

The Various Debian Upgrade Methods

Carla Schroder's latest (excellent) article, Cheatsheet: Master Linux Package Management, spawned a LinuxChix discussion of the subtleties of Debian package management (which includes other Debian-based distros such as Ubuntu, Knoppix etc.) Specifically, we were unclear on the differences among apt-get upgrade or dist-upgrade, aptitude upgrade, aptitude dist-upgrade, and aptitude -f dist-upgrade. Most of us have just been typing whichever command we learned first, without understanding the trade-offs.

But Erinn Clark, our Debian Diva, checked with some of her fellow Debian experts and got us most of the answers, which I will attempt to summarize with a little extra help from web references and man pages.

First, apt-get vs. aptitude: we were told that the primary difference between them is that "aptitude is less likely to remove packages." I confess I'm still not entirely clear on what that means, but aptitude is seen as safer and smarter and I'll go on using it.

aptitude upgrade gets updates (security, bug fixes or whatever) to all currently installed packages. No packages will be removed, and no new packages will be installed. If a currently installed package changes to require a new package that isn't installed, upgrade will refuse to update those packages (they will be "kept back"). To install the "kept back" packages with their dependencies, you can use:

aptitude dist-upgrade gets updates to the currently installed packages, including any new packages which are now required. But sometimes you'll encounter problems in the dependencies, in which case it will suggest that you:

aptitude -f dist-upgrade tries to "fix broken packages", packages with broken dependencies. What sort of broken dependencies? Well, for example, if one of the new packages conflicts with another installed package, it will offer to remove the conflicting package. Without -f, all you get is that a package will be "held back" for unspecified reasons, and you have to go probing with commands like aptitude -u install pkgname or apt-get -o Debug::pkgProblemResolver=yes dist-upgrade to find out the reason.

The upshot is that if you want everything to just happen in one step without pestering you, use aptitude -f dist-upgrade; if you want to be cautious and think things through at each step, use aptitude upgrade and be willing to type the stronger commands when it runs into trouble.

Sections 6.2 and 6.3 of the Debian Reference cover these commands a little, but not in much detail. The APT Howto is better, and runs through some useful examples (which I used to try to understand what -f does).

Thanks go to Erinn, Ari Pollak, and Martin Krafft (whose highly rated book, The Debian System: Concepts and Techniques, apparently would have answered these questions, and I'll be checking it out).

Tags: linux, debian, ubuntu
[ 21:19 Mar 14, 2007    More linux | permalink to this entry ]

(Really) Reinstalling on Debian

I found myself in a situation where a package was mostly installed, but it was missing some files, notably the startup file in /etc/init.d/packagename. No problem, right? Just reinstall the package.

Well, no. dpkg -i packagename spun and looked busy for a while, but the missing file didn't appear. Removing the package first with dpkg -r packagename, then reinstalling, didn't help either, nor did dpkg -i --force-newconfig packagename. (I didn't try dpkg -r --purge packagename because I already had invested some time into setting up the files in the package and was hoping to avoid losing that work.)

Of course, I could have extracted the .deb somewhere else and pulled the single init.d file out of it; but I was worried that I might be missing other files, and end up with a flaky package.

Well, as far as I can tell, there really isn't any way to do this "right" in Debian: there's no way to tell dpkg "Really install this package, every file in it, even if you think maybe some of the files already got installed before", or "Install any file in this package which doesn't currently exist on disk." It's amazing (I'm pretty sure RPM offered both of these options) but apparently this isn't something dpkg allows.

I found a way to trick it, though:

rm /var/lib/dpkg/info/packagename.*
dpkg -i packagename

You get a lovely warning that
dpkg: serious warning: files list file for package `packagename' missing, assuming package has no files currently installed.
and then dpkg finally goes ahead and reinstalls all the files. Whew!

Update: Aha! It is possible after all. dpkg i --force-confmiss is the option I wasn't seeing. Thanks, Yosh!

Tags: linux, debian
[ 18:01 Nov 18, 2005    More linux | permalink to this entry ]

New Debian Font Weirdness

A recent change to the Debian font system has caused some odd font problems which Debian users might do well to know about.

The change has to do with the addition in /etc/fonts of a directory conf.d containing symbolic links to scripts, and the overwriting of some of the existing files in /etc/fonts.

The symptoms are varied and peculiar. On my sid system, on each boot, the system would toggle between two different font resolutions. I'd start xchat, and the fonts would be too teeny to read; so I'd call up the preferences dialog, see the font was at 9, and increase it to 12, at which point I'd see the font I was used to seeing (though the UI font in the tabs would still be teeny). Subsequent runs of xchat would be fine (except for the still-teeny tab fonts). But upon reboot, xchat would come up with the tab font correct and the channel font HUGE. Prefs dialog again: it's still at 12 where I set it last time, so now I reset it to 9, which makes it the right size. Until the next reboot, when everything became teeny again and I have to go back to 12.

The system resolution never changed, nor did the rendering of the bitmapped fonts I use in emacs and terminal clients; only the rendering of freetype scalable fonts changed with each reboot. Back in the days when all fonts were bitmapped, I would have guessed that the font system was alternating between 100dpi fonts and 72dpi fonts.

At a loss as to what might cause this strange behavior, I took a peek into /etc/fonts/conf.d, which Dave had discovered a few weeks ago when he updated his sarge system and all his bitmapped fonts disappeared. Though my problem didn't sound remotely similar to his: my bitmapped fonts were fine, it was the scalable ones which were flaky.

Turns out the symlink I'd aquired in the update, /etc/fonts/conf.d/30-debconf-no-bitmaps.conf, did indeed point to a file called no-bitmaps.conf, just as Dave's had. Just to see what would happen, I removed it, and made a new symlink, 30-debconf-yes-bitmaps.conf, pointing to yes-bitmaps.conf.

Voila! The size-toggling problem disappeared, and, even better, bitmapped fonts like "clean" now show up in gtkfontsel and in gtk font selection dialogs, which they never did before. I can use all my fonts now!

The moral is: if you've updated sarge or sid recently, and see any weirdness at all in fonts, go to /etc/fonts/conf.d and fiddle with the symlinks. Even if it doesn't seem directly related to your problem.

As to why no-bitmaps.conf causes the system to toggle between two different font scalings, that's still a mystery. The only difference between no-bitmaps.conf and yes-bitmaps.conf is that one rejects, and the other accepts, fonts that have "scalable" set to false. Why that would change the scale at which fonts are rendered is beyond me. I'll leave that up to someone who understands the new debian font system. If any such person exists.

Update 5/24/2005: turns out you can change this on a per-user basis too, with ~/.fonts.conf. man fonts.conf for details.

Tags: linux, debian, fonts
[ 21:45 Apr 12, 2005    More linux | permalink to this entry ]

Debian Networking and Hotplug Update; 2.6 Instability

I like to keep my laptop's boot sequence lean and mean, so it can boot very quickly. (Eventually I'll write about this in more detail.) Recently I made some tweaks, and then went through a couple of dist-upgrades (it's currently running Debian "sarge"), and had some glitches. Some of what I learned was interesting enough to be worth sharing.

First, apache stopped serving http://localhost/ -- not important for most machines, but on the laptop it's nice to be able to use a local web server when there's no network connected. Further investigation revealed that this had nothing to do with apache: it was localhost that wasn't working, for any port. I thought perhaps my recent install of 2.4.29 was at fault, since some configuration had changed, but that wasn't it either. Eventually I discovered that the lo interface was there, but wasn't being configured, because my boot-time tweaking had disabled the ifupdown boot-time script, normally called from /etc/rcS.d.

That's all straightforward, and I restored ifupdown to its rightful place using update-rc.d ifupdown start 39 S .
Dancer suggested apt-get install --reinstall ifupdown which sounds like a better way; I'll do that next time. But meanwhile, what's this ifupdown-clean script that gets installed as S18ifupdown-clean ?

I asked around, but nobody seemed to know, and googling doesn't make it any clearer. The script obviously cleans up something related to /etc/network/ifstate, which seems to be a text file holding the names of the currently configured network interfaces. Why? Wouldn't it be better to get this information from the kernel or from ifconfig? I remain unclear as to what the ifstate file is for or why ifupdown-clean is needed.

Now my loopback interface worked -- hurray!

But after another dist-upgrade, now eth0 stopped working. It turns out there's a new hotplug in town. (I knew this because apt-get asked me for permission to overwrite /etc/hotplug/net.agent; the changes were significant enough that I said yes, fully aware that this would likely break eth0.) The new net.agent comes with comments referencing NET_AGENT_POLICY in /etc/default/hotplug, and documentation in /usr/share/doc/hotplug/README.Debian. I found the documentation baffling -- did NET_AGENT_POLICY=all mean that it would try to configure all interfaces on boot, or only that it would try to configure them when they were hotplugged?

It turns out it means the latter. net.agent defaults to NET_AGENT_POLICY=hotplug, which doesn't do anything unless you edit /etc/network/interfaces and make a bunch of changes; but changing NET_AGENT_POLICY=all makes hotplug "just work". I didn't even have to excise LIFACE from the net.agent code, like I needed to in the previous release. And it still works fine with all my existing Network Schemes entries in /etc/network/interfaces.

This new hotplug looks like a win for laptop users. I haven't tried it with usb yet, but I have no reason to worry about that.

Speaking of usb, hotplug, and the laptop: I'm forever hoping to switch to the 2.6 kernel, because it handles usb hotplug so much better than 2.4; but so far, I've been prevented by PCMCIA hotplug issues and general instability when the laptop suspends and resumes. (2.6 works fine on the desktop, where PCMCIA and power management don't come into play.)

A few days ago, I built both 2.4.29 and 2.6.10, since I was behind on both branches. 2.4.29 works fine. 2.6.10, alas, is even less stable than 2.6.9 was. On the laptop's very first resume from BIOS suspend after the first 2.6.10 boot, it hung, in the same way I'd been seeing sporadically from 2.6.9: no keyboard lights blinking (so not a kernel "oops"), cpu fan sometimes spinning, and no keyboard response to ctl-alt-Fn or anything else. I suppose the next step is to hook up the "magic sysrq" key and see if it responds to the keyboard at all when in that state.

Tags: linux, debian, net, hotplug
[ 22:06 Mar 02, 2005    More linux | permalink to this entry ]

Giving Up On Debian -- It Damages My Printer!

I've forever struggled with Debian's printing system. A few months ago, Debian unstable introduced a new package called printconf which, once I discovered by accident it required the parallel port to be in EPP mode, actually detected and configured my trusty Epson Photo 700. It was a happy day!

But since then, the printing system has broken again. It wasn't so bad when printing did nothing at all, or printed random garbage characters or postscript instead of a picture. But now (for the past month or so), what it does is print out a centimeter or so of reasonable graphics, after which the printer starts to issue horrible grinding noises and has to be powered off in order to stop the destruction.

I discovered through much fiddling that I could get the printer working again (on a non-Debian system) by powering it off and leaving it that way for quite a while (a few minutes doesn't seem to be enough, but 20 minutes is), then plugging it into the SuSE 9.1 machine and running a series of clean/nozzle test/clean cycles. Eventually, after the second round where the nozzle test prints clean, the printer works normally again from SuSE or Redhat. I still don't know whether all that loud grinding is doing any permanent damage to the printer.

I suspect the actual problem may be something like paper size. In the few months during which printing actually worked, I had lots of problems with mozilla's printouts overrunning the page, which turned out to be due to Xprint having its own idea of paper size (A4) rather than following the system setting (usletter). I never did find a place to configure Xprint's idea of paper size, so I uninstalled Xprint, and mozilla magically became able to print on usletter paper. But it's possible there are other parameters buried in the debian printing system somewhere, perhaps telling the printer to print to paper wider than it's capable of.

I've filed bugs, but they never get any response which might offer a clue how I could help debug this; I suspect Debian's print spooling system is basically orphaned. I've tried installing and uninstalling every combination of the myriad print spooling components I can find. I'd love to uninstall it all and build the whole spooler from source, and then perhaps try to track down the problem and fix it, but there are so many pieces which all work together in undocumented ways that I don't know where to start. (Perhaps by installing exactly the component set that SuSE does?)

I'm reluctantly giving up on Debian for my primary desktop machine. I like almost everything else about Debian, and I've run it for several years on my primary machine; but during that time I've only had a few months here and there where printing briefly worked before breaking again. There must be a distro that can do easy software updates like Debian, yet is still capable of driving a printer without damaging it!

Tags: linux, debian, printing
[ 22:46 Dec 20, 2004    More linux | permalink to this entry ]

Little successes (printing on Debian)

Printing's been broken on my Debian machine forever. For one brief shining moment back in July I briefly got it working, then a week later a dist-upgrade broke it again and it's been broken ever since.

Last week Debian Weekly News mentioned a new package called "printconf" which supposedly autoconfigures usb and parallel printers for CUPS. Now, setting aside for the moment that there's already a package called printconf, which configures a completely different spooler than CUPS, and that it's very confusing of Debian to resurrect an old name for a completely different purpose, of course I wanted to try it.

At apt-get time, it asked me whether I wanted to configure my printers now, and of course I said yes. The package installed, it printed a message about restarting CUPS, and no more details. Did it do anything?

I visited the CUPS configuration url (CUPS is configured via a web browser) and the entry looked like my old printer entry. Just for ducks I clicked "print a test page". Nada. So I removed the entry, went back to my root shell and typed printconf. It printed "Restarting cups ... done." No other info. Back to the web configuration page ... no printer there.

Eventually I discovered the -v option, which at least told me that it wasn't finding any parallel printers. I know this printer can be detected via the parallel port (SuSE and Mandrake both autoconfigure it), so something was wrong. Time to look at the BIOS.

A bunch of reboots later, I finally managed to get into my machine's BIOS screen (hint: repeatedly press DEL during boot. The screen saying DEL is the right key only flashes for a fraction of a second, so there's no hope of ever reading it and I wasted several boot cycles pressing function keys instead) and changed the parallel port from "ECP" to "ECP/EPP". Back into Debian -- and voila! printconf saw the printer, autoconfigured it with some magic the earlier entry hadn't had, and after a year and a half I have a debian printer again!

(Incidentally, the parallel port setting isn't why the printer wasn't working before; it was something about the CUPS configuration. Printing used to work on this machine several years ago and the BIOS settings haven't changed since then.)

All hail printconf! I wonder if it's ever occurred to anyone to mention in the man page that it needs an EPP (or ECP/EPP?) parallel port?

Tags: linux, debian, printing
[ 21:05 Nov 05, 2004    More linux | permalink to this entry ]

Got the external mouse working again

For some reason X on the laptop hasn't been seeing the external USB mouse. But last night I got it working again. Turns out that /dev/input/mouse0 no longer works; I have to use /dev/input/mice because the mouse number changes each time it's plugged in (which I don't think was a problem with earlier kernels). Thanks to Peter S. for helping me track the problem down.

I also learned (unrelated to the mouse issue) about a couple of very useful Debian apps, deborphan and debfoster, for finding orphaned and no longer needed libraries. I'd always wanted something like that to help clean up my crufty debian systems.

Tags: linux, X11, debian
[ 18:39 Jul 31, 2004    More linux | permalink to this entry ]

Printing working on debian, at last

After a year of no printing on sid, I went back to sarge to see if I could still print from there.

When I dist-upgraded my ancient sarge, one of the questions it asked me was whether to replace printers.conf. That sounded suspicious: I saved the old printers.conf, then allowed it to replace it with its new version.

Well, sure enough, with the new printers.conf it didn't know about my Epson, and when I went to the cups admin url to add it, there was no "add printer" button. Just like I'd always seen in sid.

In sid, someone once gave me the direct url to "add a printer", but when I followed it, I didn't get a working setup anyway. I decided to try copying my old printers.conf on top of the new one.

And voila, it worked! Printing works okay from sarge. (It still has the problem of the cups test page outlines not aligning well with the physical printer page, so it may not work for printing labels, but it's a start.)

So I moved over to sid, and tried the same printers.conf. Voila, something came out of the printer, the first I've ever seen that happen from sid! It didn't entirely work: I printed a few lines using lpr, and the printer printed those lines but then didn't eject the page, and I had to wrestle with the printer to get the paper out. So all is not quite well in sid land, but it's much farther along than it was using only the tools available in sid (rather than my two-year-old printers.conf originally configured on a much older sarge).

The other interesting file that upgrade asked me about was epson.conf, which turns out to be for the epson scanner, not the epson printer. Perhaps by using that (I saved the old sarge file) I'll eventually be able to get scanning working on sid! That would be lovely. For now, I'm using sarge a lot more.

Tags: linux, debian, printing
[ 22:09 Jul 20, 2004    More linux | permalink to this entry ]

DRI works after all

Got an account on alioth, akkana-guest.

Discovered that the tuxracer problem I've been having isn't actually Debian sid having broken DRI, but merely some problem with the commercial tuxracer (probably not loading the gl libs properly or something). Free tuxracer still works. Yay.

Tags: linux, debian, X11, games
[ 19:00 Jul 07, 2004    More linux | permalink to this entry ]