Shallow Thoughts

How to fix usbview and /proc/bus/usb in Ubuntu Hardy

Ah, I so love progress. I was working with powertop to try to make my system more efficient, and kept seeing a USB device I didn't recognize showing up as a frequent source of wakeups. lsusb didn't show it either, so I tried firing up usbview.

Except it didn't work: on Hardy it brings up an error window complaining about not being able to open /proc/bus/usb, which, indeed, is not mounted despite being enabled in my kernel.

A little googling showed this was an oft-reported bug in Ubuntu Hardy: for instance, bug 156085 and bug 151585, both with the charming attitude I so love in open source projects, "No, we won't enable this simple fix that reverts the software to the way it worked in the last release; we'd prefer to keep it completely broken indefinitely until someone happens to get around to fixing it right."

Okay, that's being a little harsh: admittedly, most of the programs broken by this are in the "universe" repository and thus not an official part of Ubuntu. Still, why be rude to users who are just trying to find a way around bustage that was deliberately introduced? Doesn't Ubuntu have any sort of process to assign bugs in universe packages to a maintainer who might care about them?

Anyway, the workaround, in case you need usbview or qemu/kvm or anything else that needs /proc/bus/usb, is to edit the file /etc/init.d/mountdevsubfs.sh and look for the line that says:

# Magic to make /proc/bus/usb work

Uncomment out the lines immediately following that line, then either reboot or run the last command there by hand.

(In case you're wondering, usbview showed that the USB device causing the powertop wakeups was the multi-flash card reader. I'm suspecting hald-addons-storage is involved -- powertop already flagged hal's cdrom polling as the number-one power waster. I don't know why the flash multicard reader shows up in usbview but not in lsusb.)

Tags: ubuntu, usb
[ 20:45 May 31, 2008    More linux | permalink to this entry ]

Fixing scanner permissions on Hardy

Dave needed something scanned. Oh, good! The first use of a scanner under a new distro is always an interesting test. Though the last few Ubuntu releases have been so good about making scanners "just work" that I was beginning to take scanners for granted. "Sure, no problem," I told Dave, taking the sketch he gave me.

Ha! Famous last words. For Hardy, I guess the Ubuntu folks decided that users had had it too easy for a while and it was time to throw us a challenge. Under Hardy, scanning works fine as root, but normal users can't access the scanner. sane-find-scanner sees the scanner, but xsane and the xsane-gimp plug-in can't talk to it (except as root).

It turns out the code for noticing you plugged in a scanner and setting appropriate permissions (like making it group "scanner") has been removed from udev, the obvious place for it ... and moved into hal. Except, you guessed it, whatever hal is supposed to be doing isn't working, so the device's group is never set to "scanner" to make it accessible to non-root users. Lots of people are hitting this and filing bugs (search for scanner permissions), in particular bug 121082 and bug 217571.

Fortunately, the fix is quite easy if you have a copy of your old gutsy install: just copy /etc/udev/rules.d/45-libsane.rules from gutsy to the same place on hardy. (If you don't have your gutsy udev rules handy, I attached the file to the latter of the two bugs I linked above.)

Then udev will handle your scanner just like it used to, and you don't have to wait for the hal developers to figure out what's wrong with the new hal rules.

Tags: linux, ubuntu, scanner, udev, hal
[ 15:56 May 22, 2008    More linux | permalink to this entry ]

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 ]

How often does updatedb really need to run?

Since updating to Hardy, I've been getting mail from Anacron:

/etc/cron.weekly/slocate:
slocate: fatal error: load_file: Could not open file: /etc/updatedb.conf: No such file or directory

That's the script that updates the database for locate, Linux's fast find system. I figured I must have screwed something up when I moved that slocate cron script from cron.daily to cron.weekly (because I hate having my machine slow to a crawl as soon as I boot it in the morning, and it doesn't bother me if the database doesn't necessarily have files added in the last day or two).

But after talking to some other folks and googling for Ubuntu bugs, I discovered I wasn't the only one getting that mail, and there was already a bug covering it. Comparing my setup with another Hardy user's, I found that the file slocate was failing to find, /etc/updatedb.conf, belongs to a different package, mlocate. If mlocate is installed, then slocate's cron script works; otherwise, it doesn't. Sounds like slocate should have a dependency that pulls in mlocate, no?

But wait, what do these two packages do? Let's try a little aptitude search locate:

p   dlocate                         - fast alternative to dpkg -L and dpkg -S   
p   kio-locate                      - kio-slave for the locate command          
i   locate                          - maintain and query an index of a directory
p   mlocate                         - quickly find files on the filesystem based
i   slocate                         - Secure replacement of findutil's locate   

Okay, forget the first two, but we have locate, mlocate, and slocate. How do they relate?

Worse, if I install mlocate (so slocate will work) and then look in my cron directories, it turns out I now have, count 'em, five different cron scripts that run updatedb. They are:

In cron.daily:

locate: 72 lines! but a lot of that is comments and pruning, and a lot of fiddling to figure out what version of the kernel is running to see whether it can pass any advanced flags when it tries to renice the process. In the end it calls updatedb.findutils (note no full path, though it uses a full path when it checks for it earlier in the script).

slocate: A much simpler but unfortunately buggy 20 lines. It checks for /etc/updatedb.conf, runs it if it exists, fiddles with ionice, checks again for /etc/updatedb.conf, and based on whether it finds it, runs either /usr/bin/slocate -u or /usr/bin/slocate -u -f proc. The latter path is what was failing and sending root mail every time the script was run.

mlocate: an even slimmer 12 line script, which checks for /usr/bin/updatedb.mlocate and, if it exists, fiddles ionice then runs /usr/bin/updatedb.mlocate.

In cron.weekly:

Two virtually identical scripts called find.notslocate and find.notslocate.dpkg-new, which differ only in dpkg-new having more elaborate ionice options. They both run updatedb. And which updatedb would that be? Probably /usr/bin/updatedb, which links to /etc/alternatives/updatedb, which probably links to either updatedb.mlocate or updatedb.slocate, whichever you've installed most recently. But in either case, it's hard to see why you'd need this script running weekly if you're already running both flavors of updatedb from other scripts cron.daily. And having two copies of the script is just plain wrong (and there was already a bug filed on it). (As long as you're poking around in cron.daily and cron.weekly, check and see if you have any more of these extra dpkg-new or dpkg-old scripts -- they might be slowing down your machine for no reason.)

Further research reveals that mlocate is a new(ish) package intended to replace slocate. (There was a long discussion of that on ubuntu-devel, leading to the replacement of slocate with mlocate very late in the Hardy development cycle. There was also lots of discussion of "tracker", apparently a GUI fast find tool that can only search in the user's home directory.)

What is this mlocate? The m stands for "merge": the advantage of mlocate is that it can merge new results into its existing database instead of replacing the whole thing every time. Sounds good, right? However, the down side is that mlocate apparently can't to purge its database of old files that no longer exist, and these files will clutter up your locate results. Running locate -e will keep them from being printed -- but there seems to be no way to set this permanently, via an environment variable or .locaterc file, nor to tell updatedb.mlocate to clean up its database. So you'll need to alias locate to locate -e if you want sensible behavior. Or go back to slocate. Sigh.

Cleaning up

The important thing is to get rid of most of those spurious updatedb cron scripts. You might choose to run updatedb daily, weekly, or only when you choose to run it; but you probably don't want five different scripts running two different versions of updatedb at different times. The packages obviously aren't cleaning up after themselves, so let's do a little manual cleanup.

That find.slocate script looks suspicious. In fact, if you run dpkg -S find.notslocate, you find out that it doesn't belong to any package -- not only should the .dpkg-old version not be there, neither should the other one! So out they go.

As for slocate and mlocate, it's important to know that the two packages can coexist: installing mlocate doesn't remove slocate or vice versa. A clean Hardy install should have only mlocate; upgrades from Gutsy are more likely to have a broken slocate.

Having both packages probably isn't what you want. So pick one, and remove or disable the other. If mlocate is what you want, apt-get purge slocate and just make sure that /etc/cron.*/slocate disappears. If you decide you want slocate, it's a little trickier since the slocate package is broken; but you can fix it by creating an empty /etc/updatedb.conf so updatedb.slocate won't fail.

Tags: linux, boot, ubuntu, install
[ 20:48 Apr 29, 2008    More linux/install | permalink to this entry ]

Autologin changes again for Hardy's upstart

Seems like each new Ubuntu release makes a few gratuitous changes to the syntax of system files. Today's change involves autologin, controlled by the "upstart" system (here's what I wrote about the previous syntax for autologin under upstart).

The /usr/bin/loginscript still hasn't changed, and this still works:

#! /bin/sh
/bin/login -f yourusername

But the syntax has changed a little for the getty line in /etc/event.d/tty1: respawn is now on its own line (I don't know if that matters -- I still can't find any documentation on this file's syntax, though I found a new upstart page that links to some blog entries illustrating how upstart can be used to start system daemons like dbus). And the getty now needs an exec before it. Like this:

respawn
exec /sbin/getty -n -l /usr/bin/loginscript 38400 tty1

Tags: linux, ubuntu, boot
[ 14:27 Apr 22, 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 ]

Ubuntu "Hardy Heron"

On a lunchtime bird walk on Monday I saw one blue heron and at least five green herons (very unusuual to see so many of those). Maybe that helped prepare me for installing the latest Ubuntu beta, "Hardy Heron", Monday afternoon.

I was trying the beta primarily in the hope that it would fix a serious video out regression that appeared in Gutsy (the current Ubuntu) in January. My beloved old Vaio SR17 laptop can't switch video signals on the fly like some laptops can; I've always needed to boot it with an external monitor or projector connected. But as long as it saw a monitor at boot time, it would remember that state through many suspend cycles, so I could come out of suspend, plug in to a projector and be ready to go. But beginning some time in late January, somehow Gutsy started doing something that turned off the video signal when suspending. To talk to a projector, I could reboot with the projector connected (I hate making an audience watch that! and besides, it takes away the magic). I also discovered that switching to one of the alternate consoles, then back (ctl-alt-F2 ctl-alt-F7) got a signal going out on the video port -- but I found out the hard way, in front of an audience, that it was only a 640x480 signal, not the 1024x768 signal I expected. Not pretty! I could either go back to Feisty ... or try upgrading to Hardy.

I've already written about the handy debootstrap lightweight install process I used. (I did try the official Hardy "alternate installer" disk first, but after finishing package installation it got into a spin lock trying to configure kernel modules, so I had to pull the plug and try another approach.)

This left me with a system that was very minimal indeed, so I spent the next few hours installing packages, starting with tcsh, vim (Ubuntu's minimal install has something called vim, but it's not actually vim so you tend to get lots of errors about parsing your .vimrc until you install the real vim), acpi and acpi-support (for suspending), and the window system: xorg and friends. To get xorg, I started with:

apt-get install xserver-xorg-video-savage xbase-clients openbox xloadimage xterm

Then there was the usual exercise of aptitude search font and installing everything on that list that seemed relevant to European languages (I don't really need to scroll through dozens of Tamil, Thai, Devanagari and Bangla fonts every time I'm looking for a fancy cursive in GIMP).

But I hit a problem with that pretty early on: turns out most of the fonts I installed weren't actually showing up in xlsfonts, xfontsel, gtkfontsel, or, most important, the little xlib program I'm using for a talk I need to give in a couple weeks. I filed it as bug 212669, but kept working on it, and when a clever person on #ubuntu+1 ("redwhitewaldo") suggested I take a look at the x-ttcidfont-conf README, that gave me enough clue to get me the rest of the way. Turns out there's a Debian bug with the solution, and the workaround is easy until the Ubuntu folks pick up the update.

I hit a few other problems, like the PCMCIA/udev problem I've described elsewhere ... but mostly, my debootstrapped Hardy Heron is working quite well.

And in case you're wondering whether Hardy fixed the video signal problem, I'm happy to say it does. Video out is working just fine.

Tags: linux, ubuntu, install, fonts, vaio
[ 18:31 Apr 07, 2008    More linux/install | permalink to this entry ]

Handling a network card automatically: Calling ifup from udev

I'm experimenting with Ubuntu's "Hardy Heron" beta on the laptop, and one problem I've hit is that it never configures my network card properly.

The card is a cardbus 3Com card that uses the 3c59x driver. When I plug it in, or when I boot or resume after a suspend, the card ends up in a state where it shows up in ifconfig eth0, but it isn't marked UP. ifup eth0 says it's already up; ifdown eth0 complains error: SIOCDELRT: No such process but afterward, I can run ifup eth0 and this time it works. I've made an alias, net, that does sudo ifdown eth0; sudo ifup eth0. That's silly -- I wanted to fix it so it happened automatically.

Unfortunately, there's nothing written anywhere on debugging udev. I fiddled a little with udevmonitor and udevtest /class/net/eth0 and it looked like udev was in fact running the ifup rule in /etc/udev/rules.d/85-ifupdown.rules, which calls: /sbin/start-stop-daemon --start --background --pid file /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE} So I tried running that by hand (with $env{INTERFACE} being eth0) and, indeed, it didn't bring the interface up.

But that suggested a fix: how about adding --force to that ifup line? I don't know why the card is already in a state where ifup doesn't want to handle it, but it is, and maybe --force would fix it. Sure enough: that worked fine, and it even works when resuming after a suspend.

I filed bug 211955 including a description of the fix. Maybe there's some reason for not wanting to use --force in 85-ifupdown (why wouldn't you always want to configure a network card when it's added and is specified as auto and allow-hotplug in /etc/network/interfaces?) but if so, maybe someone will suggest a better fix.

Tags: linux, ubuntu, udev, net
[ 13:41 Apr 04, 2008    More linux | permalink to this entry ]

Gutsy's persistent net rules don't persist

I use wireless so seldom that it seems like each time I need it, it's a brand new adventure finding out what has changed since the last time to make it break in a new and exciting way.

This week's wi-fi adventure involved Ubuntu's current "Gutsy Gibbon" release and my prism54 wireless card. I booted the machine, switched to the right (a href="http://shallowsky.com/linux/networkSchemes.html">network scheme, inserted the card, and ... no lights. ifconfig -a showed the card on eth1 rather than eth0.

After some fiddling, I ejected the card and re-inserted it; now ifconfig -a showed it on eth2. Each time I inserted it, the number incremented by one.

Ah, that's something I remembered from Debian Etch -- a problem with the udev "persistent net rules" file in /etc/udev.

Sure enough, /etc/udev/70-persistent-net.rules had two entries for the card, one on eth1 and the other on eth2. Ejecting and re-inserting added another one for eth3. Since my network scheme is set up to apply to eth0, this obviously wouldn't work.

A comment in that file says it's generated from 75-persistent-net-generator.rules. But unfortunately, the rules uesd by that file are undocumented and opaque -- I've never been able to figure out how to make a change in its behavior. I fiddled around for a bit, then gave up and chose the brute force solution:

• Remove /etc/udev/75-persistent-net-generator.rulesa
• Edit /etc/udev/70-persistent-net.rules to give the device the right name (eth1, eth0 or whatever).

And that worked fine. Without 75-persistent-net-generator.rules getting in the way, the name seen in 70-persistent-net.rules works fine and I'm able to use the network.

The weird thing about this is that I've been using Gutsy with my wired network card (a 3com) for at least a month now without this problem showing up. For some reason, the persistent net generator doesn't work for the Prism54 card though it works fine for the 3com. A scan of the Ubuntu bug repository reveals lots of other people hitting similar problems on an assortment of wireless cards; bug 153727 is a fairly typical report, but the older bug 31502 (marked as fixed) points to a likely reason this is apparently so common on wireless cards -- apparently some of them report the wrong MAC address before the firmware is loaded.

Tags: linux, ubuntu, udev, net
[ 18:02 Dec 23, 2007    More linux | permalink to this entry ]

Bug fixes? Why would we bother to ship bug fixes?

(A culture of regressions, part 2)

I've been running on Ubuntu's latest, "Gutsy gibbon", for maybe a month now. Like any release, it has its problems that I've needed to work around. Like many distros, these problems won't be fixed before the next release. But unlike other distros, it's not just lack of developer time; it turns out Ubuntu's developers point to an official policy as a reason not to fix bugs.

Take the case of the aumix bug. Aumix just plain doesn't work in gutsy. It prints, "aumix: SOUND_MIXER_READ_DEVMASK" and exits.

This turns out to be some error in the way it was compiled. If you apt-get the official ubuntu sources, build the package and install it yourself, it works fine. So somehow they got a glitch during the process of building it, and produced a bad binary.

(Minor digression -- does that make this a GPL violation? Shipping sources that don't match the distributed binary? No telling what sources were used to produce the binary in Gutsy. Not that anyone would actually want the sources for the broken aumix, of course.)

It's an easy fix, right? Just rebuild the binary from the source in the repository, and push it to the servers.

Apparently not. A few days ago, Henrik Nilsen Omma wrote in the bug:

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined. According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. [ ... ] See: https://wiki.ubuntu.com/StableReleaseUpdates.

Of course, I clicked on the link to receive enlightenment. Ubuntu's Stable Release page explains

Users of the official release, in contrast, expect a high degree of stability. They use their Ubuntu system for their day-to-day work, and problems they experience with it can be extremely disruptive. Many of them are less experienced with Ubuntu and with Linux, and expect a reliable system which does not require their intervention.

by way of explaining the official Ubuntu policy on updates:

Stable release updates will, in general, only be issued in order to fix high-impact bugs. Examples of such bugs include:

• Bugs which may, under realistic circumstances, directly cause a security vulnerability
• Bugs which represent severe regressions from the previous release of Ubuntu
• Bugs which may, under realistic circumstances, directly cause a loss of user data

Clearly aumix isn't a security vulnerability or a loss of user data. But I could make a good argument that a package that doesn't work ... ever ... for anyone ... constitutes a severe regression from the previous version of that package.

Ubuntu apparently thinks that users get used to packages not working, and grow to like it. I guess that if you actually fixed packages that you broke, that would be disruptive to users of the stable release.

I'm trying to picture these Ubuntu target users, who embrace regressions and get upset when something that doesn't work at all gets fixed so that it works as it did in past releases. I can't say I've ever actually met a user like that myself. But evidently the Ubuntu Updates Team knows better.

Update: I just have to pass along Dave's comment: "When an organization gets to the point where it spends more energy on institutional processes for justifying not fixing something than on just fixing it -- it's over."

Update: Carla Schroder has also written about this.

Tags: linux, ubuntu, audio
[ 10:21 Dec 07, 2007    More linux | permalink to this entry ]

Backing up a file system

I upgraded my system to the latest Ubuntu, "Gutsy Gibbon", recently. Of course, it's always best to make a backup before doing a major upgrade. In this case, the goal was to back up my root partition to another partition on the same disk and get it working as a bootable Ubuntu, which I could then upgrade, saving the old partition as a working backup. I'll describe here a couple of silly snags I hit, to save you from making the same mistakes.

Linux offers lots of ways to copy filesystems. I've used tar in the past, with a command like (starting in /gutsy): tar --one-file-system -cf - / | tar xvf - > /tmp/backup.out but cp seemed like an easier way, so I want to try it.

I mounted my freshly made backup partition as /gutsy and started a cp -ax /* /gutsy (-a does the right thing for permissions, owner and group, and file type; -x tells it to stay on the original filesystem). Count to ten, then check what's getting copied. Whoops! It clearly wasn't staying on the original filesystem.

It turned out my mistake was that /*. Pretty obvious in hindsight what cp was doing: for each entry in / it did a cp -ax, staying on the filesystem for that entry, not on the filesystem for /. So /home, /boot, /proc, etc. all got copied. The solution was to remove the *: cp -ax / /gutsy.

But it wasn't quite that simple. It looked like it was working -- a long wait, then cp finished and I had what looked like a nice filesystem backup. I adjusted /gutsy/etc/fstab so that it would point to the right root, set up a grub entry, and rebooted. Disaster! The boot hung right after Attached scsi generic sg0 type 0 with no indication of what was wrong.

Rebooting into the old partition told me that what's supposed to happen next is: * Setting preliminary keymap... But the crucial error message was actually several lines earlier: Warning: unable to open an initial console. It hadn't been able to open /dev/console.

Now, in the newly copied filesystem, there was no /dev/console: in fact, /dev was empty. Nothing had been copied because /dev is a virtual file system, created by udev.

But it turns out that the boot process needs some static devices in /dev, before udev has created anything. Of course, once udev's virtual filesystem has been mounted on /dev, you can no longer read whatever was in /dev on the root partition in order to copy it somewhere else. But udev nicely gives you access to it, in /dev/.static/dev. So what I needed to do to get my new partition booting was: cp -ax /dev/.static/dev/ /gutsy/dev/ With that done, I was able to boot into my new filesystem and upgrade to Gutsy.

Tags: linux, ubuntu, backups
[ 22:48 Nov 30, 2007    More linux | permalink to this entry ]

Widescreen Monitor, Intel Graphics on Ubuntu

On a seemingly harmless trip to Fry's, my mother got a look at the 22-inch widescreen LCD monitors and decided she had to have one. (Can't blame her ... I've been feeling the urge myself lately.)

We got the lovely new monitor home, plugged it in, configured X and discovered that the screen showed severe vertical banding. It was beautiful at low resolutions, but whenever we went to the monitor's maximum resolution of 1680x1050, the bands appeared.

After lots of testing, we tentatively pinned the problem down to the motherboard. It turns out ancient machines with 1x AGP motherboards can't drive that many pixels properly, even if the video card is up to the job. Who knew?

Off we trooped to check out new computers. We'd been hinting for quite some time that it might be about time for a new machine, and Mom was ready to take the plunge (especially if it meant not having to return that beautiful monitor).

We were hoping to find something with a relatively efficient Intel Core 2 processor and Intel integrated graphics: I've been told the Intel graphics chip works well with Linux using open source drivers. (Mom, being a person of good taste, prefers Linux, and none of us wanted to wrestle with the proprietary nvidia drivers). We found a likely machine at PC Club. They were even willing to knock $60 off the price since she didn't want Windows.

But that raised a new problem. During our fiddling with her old machine, we'd tried burning a Xubuntu CD, to see if the banding problem was due to the old XFree86 she was running. Installing it hadn't worked: her CD burner claimed it burned correctly, but the resulting CD had errors and didn't pass verification. So we needed a CD burned. We asked PC Club when buying the computer whether we might burn the ISO to CD, but apparently that counts as a "data transfer" and their minimum data transfer charge is $80. A bit much.

No problem -- a friend was coming over for dinner that night, and he was kind enough to bring his Mac laptop ... and after a half hour of fiddling, we determined that his burner didn't work either (it gave a checksum error before starting the burn). He'd never tried burning a CD on that laptop.

What about Kinko's? They have lots of data services, right? Maybe they can burn an ISO. So we stopped at Kinko's after dinner. They, of course, had never heard of an ISO image and had no idea how to burn one on their Windows box. Fearing getting a disk with a filesystem containing one file named "xubuntu-7.04-alternate-i386.iso", we asked if they had a mac, since we knew how to burn an ISO there. They did, though they said sometimes the CD burner was flaky. We decided to take the risk.

Burning an ISO on a mac isn't straightforward -- you have to do things in exactly the right order. It took some fast talking to persuade them of the steps ("No, it really won't work if you insert the blank CD first. Yes, we're quite sure") and we had to wait a long time for Kinko's antivirus software to decide that Xubuntu wasn't malware, but 45 minutes and $10 later, we had a disc.

And it worked! We first set up the machine in the living room, away from the network, so we had to kill aptitude update when the install hung installing "xubuntu-desktop" at 85% (thank goodness for alternate consoles on ctl-alt-F2) but otherwise the install went just fine. We rebooted, and Xubuntu came up ... at 1280x1024, totally wrong. Fiddling with the resolution in xorg.conf didn't help; trying to autodetect the monitor with dpkg-reconfigure xorg crashed the machine and we had to power cycle.

Back to the web ... turns out that Ubuntu "Feisty" ships with a bad Intel driver. Lots of people have hit the problem, and we found a few elaborate workarounds involving installing X drivers from various places, but nothing simple. Well, we hadn't come this far to take all the hardware back now.

First we moved the machine into the computer room, hooked up networking and reinstalled xubuntu with a full network, just in case. The resolution was still wrong. Then, with Dave in the living room calling out steps off a web page he'd found, we began the long workaround process.

"First," Dave suggested, reading, "check the version of xserver-xorg-video-intel. Let's make sure we're starting with the same version this guy is."

dpkg -l xserver-xorg-video-intel ... "Uh, it isn't installed," I reported. I tried installing it. "It wants to remove xserver-xorg-video-i810." Hmm! We decided we'd better do it, since the rest of the instructions depended on having the intel, not i810, driver.

And that was all it needed! The intel driver autodetected the monitor and worked fine at 1680x1050.

So forget the elaborate instructions for trying X drivers from various sources. The problem was that xubuntu installed the wrong driver: the i810 driver instead of the more generic intel driver. (Apparently that bug is fixed for the next Ubuntu release.)

With that fix, it was only a few more minutes before Mom was happily using her new system, widescreen monitor and all.

Tags: linux, X11, ubuntu
[ 13:23 Aug 25, 2007    More linux | 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 ]

A Quartet of Workarounds

I upgraded my laptop's Ubuntu partition from Edgy to Feisty. Debian Etch works well, but it's just too old and I can't build software like GIMP that insists on depending on cutting-edge libraries.

But Feisty is cutting edge in other ways, so it's been a week of workarounds, in two areas: Firefox and the kernel. I'll start with Firefox.

Firefox crashes playing flash

First, the way Ubuntu's Firefox crashes when running Flash. I run flashblock, fortunately, so I've been able to browse the web just fine as long as I don't click on a flashblock button. But I like being able to view the occasional youtube video, and flash 7 has worked fine for me on every distro except Ubuntu. I first saw the problem on Edgy, and upgrading to Feisty didn't cure the problem.

But it wasn't their Firefox build; my own "kitfox" firefox build crashed as well. And it wasn't their flash installation; I've never had any luck with either their adobe flash installer nor their opensource libswfdec, so I'm running the same old flash 7 plug-in that I've used all along for other distros.

To find out what was really happening, I ran Firefox from the commandline, then went to a flash page. It turned out it was triggering an X error:

The error was: 'BadMatch (invalid parameter attributes)'.
(Details: serial 104 error_code 8 request_code 145 minor_code 3)

That gave me something to search for. It turns out there's a longstanding Ubuntu bug, 14911 filed on this issue, with several workarounds. Setting the environment variable XLIB_SKIP_ARGB_VISUALS to 1 fixed the problem, but, reading farther in the bug, I saw that the real problem was that Ubuntu's installer had, for some strange reason, configured my X to use 16 bit color instead of 24. Apparently this is pretty common, and due to some bug involving X's and Mozilla's or Flash's handling of transparency, this causes flash to crash Mozilla.

So the solution is very simple. Edit /etc/X11/xorg.conf, look for the DefaultDepth line, and if it's 16, that's your problem. Change it to 24, restart X and see if flash works. It worked for me!

Eliminating Firefox's saved session pester dialog

While I was fiddling with Firefox, Dave started swearing. "Why does Firefox always make me go through this dialog about restoring the last session? Is there a way to turn that off?"

Sure enough, there's no exposed preference for this, so I poked around about:config, searched for browser and found browser.sessionstore.resume_from_crash. Doubleclick that line to change it to false and you'll have no more pesky dialog.

For more options related to session store, check the Mozillazine Session Restore page.

Kernel: runaway kacpid

Alas, having upgraded to Feisty expressly so that I could build cutting-edge programs like GIMP, I discovered that I couldn't build anything at all. Anything that uses heavy CPU for more than a minute or two triggers a kernel daemon, kacpid, to grab most of the CPU for itself. Being part of the kernel (even though it has a process ID), kacpi is unkillable, and prevents the machine from shutting down, so once this happens the only solution is to pull the power plug.

This has actually been a longstanding Ubuntu problem (bug 75174) but it used to be that disabling acpid would stop kacpid from running away, and with feisty, that no longer helps. The bug is also kernel.org bug 8274.

The Ubuntu bug suggested that disabling cpufreq solved it for one person. Apparently the only way to do that is to build a new kernel. There followed a long session of attempted kernel building. It was tricky because of course I couldn't build on the target machine (inability to build being the problem I was trying to solve), and even if I built on my desktop machine, a large rsync of the modules directory would trigger a runaway kacpi. In the end, building a standalone kernel with no modules was the only option.

But turning off cpufreq didn't help, nor did any of the other obvious acpi options. The only option which stops kacpid is to disable acpi altogether, and use apm. I'm sorry to lose hibernate, and temperature monitoring, but that appears to be my only option with modern kernels. Sigh.

Kernel: Hangs for 2 minutes at boot time initializing sound card

While Dave and I were madly trying to find a set of config options to build a 2.6.21 that would boot on a Vaio (he was helping out with his SR33 laptop, starting from a different set of config options) we both hit, at about the same time, an odd bug: partway through boot, the kernel would initialize the USB memory stick reader:

sd 0:0:0:0: Attached scsi removable disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0

and then it would hang, for a long time. Two minutes, as it turned out. And the messages after that were pretty random: sometimes related to the sound card, sometimes to the network, sometimes ... GConf?! (What on earth is GConf doing in a kernel boot sequence?) We tried disabling various options to try to pin down the culprit: what was causing that two minute hang?

We eventually narrowed the blame to the sound card (which is a Yamaha, using the ymfpci driver). And that was enough information for google to find this Linux Kernel Mailing List thread. Apparently the sound maintainer decided, for some reason, to make the ymfpci driver depend on an external firmware file ... and then didn't include the firmware file, nor is it included in the alsa-firmware package he references in that message. Lovely. I'm still a little puzzled about the timeout: the post does not explain why, if a firmware file isn't found on the disk, waiting for two minutes is likely to make one magically appear.

Apparently it will be fixed in 2.6.22, which isn't much help for anyone who's trying to run a kernel on any of the 2.6.21.* series in the meantime. (Isn't it a serious enough regression to fix in 2.6.21.*?) And he didn't suggest a workaround, except that alsa-firmware package which doesn't actually contain the firmware for that card. Looks like it's left to the user to make things work.

So here's what to do: it turns out that if you take a 2.6.21 kernel, and substitute the whole sound/pci/ymfpci directory from a 2.6.20 kernel source tree, it builds and boots just fine. And I'm off and running with a standalone apm kernel with no acpi; sound works, and I can finally build GIMP again.

So it's been quite a week of workarounds. You know, I used to argue with all those annoying "Linux is not ready for the desktop" people. But sometimes I feel like Linux usability is moving in the wrong direction. I try to imagine explaining to my mac-using friends why they should have to edit /etc/X11/xorg.conf because their distro set up a configuration that makes Firefox crash, or why they need to build a new kernel because the distributed ones all crash or hang ... I love Linux and don't regret using it, but I seem to need workarounds like this more often now than I did a few years ago. Sometimes it really does seem like the open source world is moving backward, not forward.

Tags: linux, ubuntu, mozilla, firefox, kernel, audio
[ 22:24 Jun 28, 2007    More linux | permalink to this entry ]

Feisty Fawn Versus Apache

In the last installment, I got the Visor driver working. My sitescooper process also requires that I have a local web server (long story), so I needed Apache. It was already there and running (curiously, Apache 1.3.34, not Apache 2), and it was no problem to point the DocumentRoot to the right place.

But when I tested my local site, I discovered that although I could see the text on my website, I couldn't see any of the images. Furthermore, if I right-clicked on any of those images and tried "View image", the link was pointing to the right place (http://localhost/images/foo.jpg). The file (/path/to/mysite/images/foo.jpg) existed with all the right permissions. What was going on?

/var/log/apache/error.log gave me the clue. When I was trying to view http://localhost/images/foo.jpg, apache was throwing this error:

 [error] [client 127.0.0.1] File does not exist: /usr/share/images/foo.jpg

/usr/share/images? Huh?

Searching for usr/share/images in /etc/apache/httpd.conf gave the answer. It turns out that Ubuntu, in their infinite wisdom, has decided that no one would ever want a directory called images in their webspace. Instead, they set up an alias so that any reference to /images gets redirected to /usr/share/images.

WTF?

Anyway, the solution is to comment out that stanza of httpd.conf:

<IfModule mod_alias.c>
#    Alias /icons/ /usr/share/apache/icons/
#
#    <Directory /usr/share/apache/icons>
#         Options Indexes MultiViews
#         AllowOverride None
#         Order allow,deny
#         Allow from all
#    </Directory>
#
#    Alias /images/ /usr/share/images/
#
#    <Directory /usr/share/images>
#         Options MultiViews
#         AllowOverride None
#         Order allow,deny
#         Allow from all
#    </Directory>
</IfModule>

I suppose it's nice that they provided an example for how to use mod_alias. But at the cost of breaking any site that has directories named /images or /icons? Is it just me, or is that a bit crazy?

Tags: linux, ubuntu, web
[ 21:55 May 13, 2007    More linux | permalink to this entry ]

Feisty Fawn: The Adventure Continues, with the Visor Driver

When we left off, I had just found a workaround for my Feisty Fawn installer problems and had gotten the system up and running.

By now, it was late in the day, time for my daily Sitescooper run to grab some news to read on my Treo PDA. The process starts with making a backup (pilot-xfer -s). But pilot-xfer failed because it couldn't find the device, /dev/ttyUSB1. The system was seeing the device connection -- dmesg said

[ 1424.598770] usb 5-2.3: new full speed USB device using ehci_hcd and address 4
[ 1424.690951] usb 5-2.3: configuration #1 chosen from 1 choice

"configuration #1"? What does that mean? I poked around /etc/udev a bit and found this rule in rules.d/60-symlinks.rules:

# Create /dev/pilot symlink for Palm Pilots
KERNEL=="ttyUSB*", ATTRS{product}=="Palm Handheld*|Handspring *|palmOne Handheld", \
             SYMLINK+="pilot"

Oh, maybe they were calling it /dev/pilot1? But no, there was nothing matching /dev/*pilot*, just as there was nothing matching /dev/ttyUSB*.

But this time googling led me right to the bug, bug 108512. Turns out that for some reason (which no one has investigated yet), feisty doesn't autoload the visor module when you plug in a USB palm device the way other distros always have. The temporary workaround is sudo modprobe visor; the long-term workaround is to add visor to /etc/modules.

On the subject of Feisty's USB support, though, I do have some good news to report.

My biggest motivation for upgrading from edgy was because USB2 had stopped working a few months ago -- bug 54419. I hoped that the newer kernel in Feisty might fix the problem.

So once I had the system up and running, I plugged my trusty hated-by-edgy MP3 player into the USB2 hub, and checked dmesg. It wasn't working -- but the error message was actually useful. Rather than obscure complaints like end_request: I/O error, dev sde, sector 2033440 or device descriptor read/64, error -110 or 3:0:0:0: rejecting I/O to dead device it had a message (which I've since lost) about "insufficient power". Now that's something I might be able to do something about!

So I dug into my bag o' cables and found a PS/2 power adaptor that fit my USB2 hub, plugged it in, plugged the MP3 player into the hub, and voila! it was talking on USB2 again.

Tags: linux, ubuntu, udev, palm, pda, usb
[ 20:10 May 13, 2007    More linux | permalink to this entry ]

Installing "Feisty Fawn"

I finally found some time to try the latest Ubuntu, "Feisty Fawn", on my desktop machine.

I used a xubuntu alternate installer disk, since I don't need the gnome desktop, and haven't had much luck booting from the Ubuntu live CDs lately. (I should try the latest, but my husband had already downloaded and burned the alternate disk and I couldn't work up the incentive to download another disk image.

The early portions of the install were typical ubuntu installer: choose a few language options, choose manual disk partitioning, spend forever up- and down-arrowing through the partitioner trying to persuade it not to automount every partition on the disk (after about the sixth time through I gave up and just let it mount the partitions; I'll edit /etc/fstab later) then begin the install.

Cannot find /lib/modules/2.6.20-15-generic
update-initramfs: failed for /boot/initrd.img-2.6.0-15-generic

Couldn't install grub, and warning direly, "This is a fatal error".

But then popcorn on #linuxchix found Ubuntu bug 37527. Turns out the problem is due to using an existing /boot partition, which has other kernels installed. Basically, Ubuntu's new installer can't handle this properly. The workaround is to go through the installer without a separate /boot partition, let it install its kernels to /boot on the root partition (but don't let it install grub, even though it's fairly insistent about it), then reboot into an old distro and copy the files from the newly-installed feisty partition to the real /boot. That worked fine.

The rest of the installation was smooth, and soon I was up and running. I made some of my usual tweaks (uninstall gdm, install tcsh, add myself to /etc/password with my preferred UID, install fvwm and xloadimage, install build-essentials and the zillion other packages needed to compile anything useful) and I had a desktop.

Of course, the adventure wasn't over. There was more fun yet to come! But I'll post about that separately.

Tags: linux, ubuntu
[ 19:36 May 12, 2007    More linux | permalink to this entry ]

Desktop Suspend!

My laptop has always been able to sleep (suspend to RAM), one way or another, but I had never managed it on a desktop machine. Every time I tried running something like apm -s, apm -S, echo 3 >/sys/power/state, or Ubuntu's /etc/acpi/sleep.sh, the machine would sleep nicely, then when I resumed it would come up partway then hang, or would simply boot rather than resuming.

Dave was annoyed by it too: his Mac G4 sleeps just fine, but none of his Linux desktops could. And finally he got annoyed enough to spend half a day playing with different options. With what he learned, both he and I now have desktops that can suspend to RAM (his under Debian Sarge, mine under Ubuntu Edgy).

One step was to install hibernate (available as a deb package in both Sarge and Edgy, but distros which don't offer it can probably get it from somewhere on suspend2.net). The hibernate program suspends to disk by default (which is what its parent project, suspend2, is all about) but it can also suspend to RAM, with the following set of arcane arguments:

hibernate -v 4 -F /etc/hibernate/ram.conf

(the -v 4 adds a lot of debugging output; remove it once you have things working).

Though actually, in retrospect I suspect I didn't need to install hibernate at all, and Ubuntu's /etc/acpi/sleep.sh script would have done just as well, once I'd finished the other step:

Fiddle with BIOS options. Most BIOSes have a submenu named something like "Power Management Options", and they're almost always set wrong by default (if you want suspend to work). Which ones are wrong depends on your BIOS, of course. On Dave's old PIII system, the key was to change "Sleep States" to include S3 (S3 is the ACPI suspend-to-RAM state). He also enabled APM sleep, which was disabled by default but which works better with the older Linux kernels he uses under Sarge.

On my much newer AMD64 system, the key was an option to "Run VGABIOS if S3 Resume", which was turned off by default. So I guess it wasn't re-enabling the video when I resumed. (You might think this would mean the machine comes up but doesn't have video, but it's never as simple as that -- the machine came up with its disk light solid red and no network access, so it wasn't just the screen that was futzed.)

Such a simple fix! I should have fiddled with BIOS settings long ago. It's lovely to be able to suspend my machine when I go away for a while. Power consumption as measured on the Kill-a-Watt goes down to 5 watts, versus 3 when the machine is "off" (desktop machines never actually power off, they're always sitting there on standby waiting for you to press the power button) and about 75 watts when the machine is up and running.

Now I just have to tweak the suspend scripts so that it gives me a new desktop background when I resume, since I've been having so much fun with my random wallpaper script.

Later update: Alas, I was too optimistic. Turns out it actually only works about one time out of three. The other two times, it hangs after X comes up, or else it initially reboots instead of resuming. Bummer!

Tags: linux, laptops, suspend, ubuntu
[ 10:07 Apr 12, 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 ]

Autologin under Upstart

The simple auto-login without gdm which I described a year ago stopped working when I upgradeded to "Edgy Eft". As part of Ubuntu's new "Upstart" boot system, they've replaced /etc/inittab with a new system that uses the directory /etc/event.d.

There's a little bit of documentation available, but in the end it just came down to fiddling. Here's how it works:

First, use the same /usr/bin/loginscript you used for the old setup, which contains something like this:

#! /bin/sh
/bin/login -f yourusername

Then edit /etc/event.d/tty1 and find the getty line: probably the last line of the file, looking like

respawn /sbin/getty 38400 tty1

Change that to:

respawn /sbin/getty -n -l /usr/bin/loginscript 38400 tty1

That's it! If you want to run X (or anything else) automatically, that works the same way as always.

Update: This changed again in Hardy. Here are the details.

Tags: linux, ubuntu, boot
[ 12:37 Feb 17, 2007    More linux | permalink to this entry ]

Getting a Wacom Tablet Working under Edgy

Another person popped into #gimp today trying to get a Wacom tablet working (this happens every few weeks). But this time it was someone using Ubuntu's new release, "Edgy Eft", and I just happened to have a shiny new Edgy install on my laptop (as well as a Wacom Graphire 2 gathering dust in the closet because I can never get it working under Linux), so I dug out the Graphire and did some experimenting.

And got it working! It sees pressure changes and everything. It actually wasn't that hard, but it did require some changes. Here's what I had to do:

1. Install wacom-tools and xinput
2. Edit /etc/X11/xorg.conf and comment out those ForceDevice lines that say "Tablet PC ONLY".
3. Reconcile the difference between udev creating /dev/input/wacom and xorg.conf using /dev/wacom: you can either change xorg.conf, change /etc/udev/rules.d/65-wacom.rules, or symlink /dev/input/wacom to /dev/wacom (that's what I did for testing, but it won't survive a reboot, so I'll have to pick a device name and make udev and X consistent).

A useful tool for testing is /usr/X11R6/bin/xinput list (part of the xinput package). That's a lot faster than going through GIMP's input device preference panel every time.

I added some comments to Ubuntu's bug 73160, where people had already described some of the errors but nobody had posted the steps to work around the problems.

While I was fiddling with GIMP on the laptop, I decided to install the packages I needed to build the latest CVS GIMP there. It needed a few small tweaks from the list I used on Dapper. I've updated the package list on my GIMP Building page accordingly.

Tags: linux, X11, imaging, gimp, ubuntu
[ 15:12 Dec 09, 2006    More linux | permalink to this entry ]

Ubuntu "Edgy Eft" Installation Pitfalls

I just tried Ubuntu's newest release, "Edgy Eft", on the laptop (my trusty if aging Vaio SR17). I used the "xubuntu" variant, in order to try out their lighter weight xfce-based desktop.

So far it looks quite good. But the installation process involved quite a few snags: here follows an account of the various workarounds I needed to get it up and running.

Live CD Problems

First, I tried to use the live CD, since I've heard it has a nice installer. But it failed during the process of bringing up X, and dumped me into me a console screen with an (initramfs) prompt. I thought I had pretty good Linux creds, but I have to confess I don't know what to do with an (initramfs) prompt; so I gave up and switched to the install CD. Too bad! I was so impressed with Ubuntu's previous live CDs, which worked well on this machine.

Guessing Keyboard Layout

Early on, the installer gives you the option to let it guess your keyboard layout. Don't let it! What this does is subject you to a seemingly infinite list of questions like:

Does your keyboard have a squiggle key?

where each squiggle is a different garbled, completely illegible character further mangled by the fact that the installer is running at a resolution not native to the current LCD display. After about 15 of these you just give up and start hitting return hoping it will end soon -- but it doesn't, so eventually you give up and try ctl-alt-del. But that doesn't work either. Pulling the power cord and starting over seems to be the only answer. Everyone I've talked to who's installed Edgy has gone through this exact experience and we all had a good laugh about it. Come to think of it, go ahead and say yes to the keyboard guesser, just so you can chuckle about it with the rest of us.

Once I rebooted and said no to the keyboard guesser, it asked three or four very straightforward questions about language, and the rest of the installation went smoothly. Of course it whined about not seeing a network, and it whined about my not wanting it to overwrite my existing /boot, and it whined about something to do with free space on my ext3 partitions (set up by a previous breezy install), but it made it through.

X Hangs on the Savage

On the first reboot after installation, it hung while trying to start X -- blank screen, no keyboard response, and I needed to pull the plug. I was prepared for that (longstanding bug 41340) so I immediately suspected dri. I booted from another partition and removed the dri lines from /etc/X11/xorg.conf, which fixed the problem.

Configuring the Network

Now I was up and running on Xubuntu Edgy. Next I needed to configure the network (since the installer won't do it: this machine only has one pcmcia slot, so it can't have a CDROM drive and a network card installed at the same time). I popped in the network card (a 3com 3c59x cardbus card) and waited expectantly for something to happen.

Nada. So I poked around and found the network configuration tool in the menus, set up my IP and DNS and all that, and looked in vain for a "start network" or "enable card" or some similar button that would perform an ifup eth0.

Nada again. Eventually I gave up, called up a terminal, and ran ifup eth0, which worked fine.

Which leads me to ask:

Given that Ubuntu is so committed to automatic hardware detection that it forces you to run hal, which spawns large numbers of daemons that poll all your disks a couple of times a second -- why can't it notice the insertion of a cardbus networking card? And configure it in some easy way without requiring the user to know about terminals and networking commands?

Ubuntu Still Wins for Suspend and Hibernate

Around this point I tested suspend and hibernate. They both worked beautifully out of the box, with no additional twiddling needed. Ubuntu is still the leader in suspending.

sudo: Timestamp Woes

Somewhere during these package management games, I lost the ability to sudo: it complained "Timestamp too far in the future", without telling me which file's timestamp was wrong so that I could fix it. Googling showed that lots of other people were having the same problem with Edgy, and found an answer: use the GUI Time and Date tool to set the time to something farther in the future than the timestamp sudo was complaining about, then run sudo -k to do some magic that resets the timestamp. Then you can set the time back to where it belongs. Why does this happen? No one seems to know, but that's the fix. (I found some discussion in bug 43233.)

vim isn't vim?

I restored my normal user account, logged in as myself with my normal fvwm environment, and went to edit (with vim) a few files. Every time, vim complained:

"E319: Sorry, the command is not available in this version: syntax on"

after which I could edit the file normally. Eventually I googled to the answer, which is très bizarre: by default, vim-common is installed but vim is not. There's a binary named vim, and a package which seems to be vim, but it isn't vim. Installing the package named vim gives you a vim that understands "syntax on" without complaining.

Conclusion

That's the list. Edgy is up and running now, and looks pretty good. The installer definitely has some rough edges, and I hope my workarounds are helpful to someone ... but the installer is only a tiny part of the OS, something you run only once or twice. So don't let the rough installer stop you from installing Edgy and trying it out. I know I look forward to using it.

Tags: linux, ubuntu
[ 19:30 Nov 20, 2006    More linux | permalink to this entry ]

A Week of Linux Get-Togethers

It's been a week jam-packed with Linuxy stuff.

Wednesday I made my annual one-day trip to Linuxworld in San Francisco. There wasn't much of great interest at the conference this year: the usual collection of corporate booths (minus Redhat, notably absent this year), virtualization as a hot keyword (but perhaps less than the last two years) and a fair selection of sysadmin tools, not much desktop Linux (two laptop vendors), and a somewhat light "Dot Org" area compared to the last few years.

I was happy to notice that most of the big corporate booths were running Linux on a majority of show machines, a nice contrast from earlier years. (Dell was the exception, with more Windows than Linux, but even they weren't all Windows.)

Linuxworld supposedly offers a wireless network but I never managed to get it to work, either in the exhibit hall or in the building where the BOFs were held.

Wednesday afternoon's BOF list didn't offer much that immediately grabbed me, but in the end I chose one on introducing desktop Linux to corporate environments. Run by a couple of IBM Linux advocates, the BOF turned out to be interesting and well presented, offering lots of sensible advice (base your arguments to management on business advantages, like money saved or increased ability to get the job done, not on promises of cool features; don't aim for a wholesale switch to Linux, merely for a policy which allows employees to choose; argue for standards-based corporate infrastructure since that allows for more choice and avoids lock-in). There was plenty of discussion between the audience and the folks leading the BOF, and I think most attendees got something out of it.

More interesting than Linuxworld was Friday's Ubucon, a free Ubuntu conference held at Google (and spilling over into Saturday morning). Despite a lack of advertising, the Ubucon was very well attended. There were two tracks, ostensibly "beginner" and "expert", but even aside from my own GIMP talk being a "beginner" topic, I ended up hanging out in the "beginner" room for the whole day, for topics like "Power Management", "How to Get Involved", and "What Do Non Geeks Need?" (the last topic dovetailing into the concluding session Linux corporate desktops).

All of the sessions were quite interactive with lots of discussion and questions from the audience. Everyone looked like they were having a good time, and I'm sure several of us are motivated to get more deeply involved with Ubuntu.

Ubucon was a great example of a low-key, fun, somewhat technical conference on a shoestring budget and I'd love to see more conferences like this in the bay area.

Finally, the week wrapped up with the annual Linux Picnic in Sunnyvale, a Silicon Valley tradition for many years and always a good time. There were some organizational glitches this year ... but it's hard to complain much about a free geek picnic in perfect weather complete with t-shirts, an installfest, a raffle and even (by mid-afternoon) a wireless network. Fun stuff!

Tags: linux, conferences, linuxworld, ubucon, ubuntu
[ 19:52 Aug 19, 2006    More linux | permalink to this entry ]

Getting rid of all those .serverauth.???? files

Dave has been complaining for a long time about the proliferation of files named .serverauth.???? (where ???? is various four-digit numbers) in his home directory under Ubuntu. I never saw them under Hoary, but now under Breezy and Dapper I'm seeing the same problem.

I spent some time investigating, with the help of some IRC friends. In fact, Carla Schroder, author of O'Reilly's Linux Cookbook, was the one who pinned down the creation of the files to the script /usr/bin/startx.

Here's the deal: if you use gdm, kdm, or xdm, you'll never see this. But for some reason, Ubuntu's startx uses a program called xauth which creates a file containing an "MIT-MAGIC-COOKIE". (Don't ask.) Under most Linux distributions, the magic cookie goes into a file called .Xauthority. The startx script checks an environment variable called XENVIRONMENT for the filename; if it's not set to something else, it defaults to $HOME/.Xenvironment.

Ubuntu's version is a little different. It still has the block of code where it checks XENVIRONMENT and sets it to $HOME/.Xenvironment if it isn't already set. But a few lines later, it proceeds to create the file under another, hardwired, name: you guessed it, $HOME/.serverauth.$$. The XENVIRONMENT variable which was checked and set is never actually used.

Programmers take note! When adding a feature to a script, please take a moment and think about what the script does, and check to see whether it already does something like what you're adding. If so, it's okay -- really -- to remove the old code, rather than leaving redundant and obsolete code blocks in place.

Okay, so why is the current code a problem? Because startx creates the file, calls xinit, then removes the file. In other words, it relies on xinit (and the X server) exiting gracefully. If anything else happens -- for example, if you shut your machine down from within X -- the startx script (which does not catch signals) can die without ever getting to the code that removes the file. So if you habitually shut down your machine from within X, you will have a .serverauth.???? file from each X session you ever shut down that way.

Note that the old setup didn't remove the file either, but at least it was always the same file. So you always have a single .Xauthority file in your home directory whether or not it's currently in use. Not much of a problem.

I wasn't seeing this under Hoary because under Hoary I ran gdm, while with Dapper, gdm would no longer log me in automatically so I had to find another approach to auto-login.

For Ubuntu users who wish to go back to the old one-file XAUTHORITY setup, there's a very simple fix: edit /usr/bin/startx (as root, of course) and change the line:

xserverauthfile=$HOME/.serverauth.$$

to read instead

xserverauthfile=$XAUTHORITY

If you want to track this issue, it's bug bug 35758.

Tags: linux, X11, ubuntu
[ 20:24 Mar 20, 2006    More linux | permalink to this entry ]

The Amazing Disappearing Nameservers

I updated my Ubuntu "dapper" yesterday. When I booted this morning, I couldn't get to any outside sites: no DNS. A quick look at /etc/resolv.conf revealed that it was empty -- my normal static nameservers were missing -- except for a comment indicating that the file is prone to be overwritten at any moment by a program called resolvconf.

man resolvconf provided no enlightenment. Clearly it's intended to work with packages such as PPP which get dynamic network information, but that offered no clue as to why it should be operating on a system with a static IP address and static nameservers.

The closest Ubuntu bug I found was bug 31057. The Ubuntu developer commenting in the bug asserts that resolvconf is indeed the program at fault. The bug reporter disputes this, saying that resolvconf isn't even installed on the machine. So the cause is still a mystery.

After editing /etc/resolv.conf to restore my nameservers, I uninstalled resolvconf along with some other packages that I clearly don't need on this machine, hoping to prevent the problem from happening again:

aptitude purge resolvconf ppp pppconfig pppoeconf ubuntu-standard wvdial

Meanwhile, I did some reading. It turns out that resolvconf depends on an undocumented bit of information added to the /etc/network/interfaces file: lines like

dns-nameservers 192.168.1.1 192.168.1.2

This is not documented under man interfaces, nor under man resolvconf; it turns out that you're supposed to find out about it from /usr/share/doc/resolvconf/README.gz. But of course, since it isn't a standard part of /etc/network/interfaces, no automatic configuration programs will add the DNS lines there for you. Hope you read the README!

resolvconf isn't inherently a bad idea, actually; it's supposed to replace any old "up" commands in interfaces that copy resolv.conf files into place. Having all the information in the interfaces file would be a better solution, if it were documented and supported.

Meanwhile, be careful about resolvconf, which you may have even if you never intentionally installed it. This thread on a Debian list discusses the problem briefly, and this reply quotes the relevant parts of the resolvconf README (in case you're curious but have already removed resolvconf in a fit of pique).

Tags: linux, ubuntu, net
[ 14:22 Mar 15, 2006    More linux | permalink to this entry ]

Auto-Login, and X Without gdm

I've been unable to persuade Ubuntu's "Dapper Drake" to log me in automatically via gdm. My desktop background flashes briefly during the login process, then vanishes; it appears that it actually is logging me in briefly, then immediately logging me out and presenting me with the normal gdm login screen.

I never liked gdm much anyway. It's heavyweight and it interferes with seeing shutdown messages. The only reason I was using it on Hoary was for autologin, and with that reason gone, I uninstalled it.

But that presented an interesting problem: it turns out that Dapper doesn't actually allow users to run X. The error message is:

Unable to open wrapper config file /etc/X11/Xwrapper.config
X: user not authorized to run the X server, aborting.

The fix turned out to be trivial: make the X server setuid and setgid (chmod 6755 /usr/bin/X). Mode 4755 (setuid only, no setgid) also works, but other Debian systems seem to set both bits.

The next question was how to implement auto-login without gdm or kdm. I had already found a useful Linux Gazette article on the subject. The gist is that you compile a short C program that calls login with your username, then you call getty with your new program as the "alternate login program". Now, I have nothing against C, but wouldn't a script be easier?

It turns out a script works too. Replace the tty1 line in /etc/inittab with a line like:

1:2345:respawn:/sbin/getty -n -l /usr/bin/myloginscript 38400 tty1

where the script in question looks like:

#! /bin/sh
/bin/login -f username

At first, I tried an even simpler approach:

1:2345:respawn:/bin/login -f username

That logged me in, but I ended up on /dev/console instead of /dev/tty1, with a message that I had no access to the tty and therefore wouldn't be able to use job control. X didn't work either. The getty is needed in order to switch control from /dev/console to a real virtual terminal like /dev/tty1.

Of course, running X automatically once you're logged in is trivial, just a line or three added to .login or .profile (see the Linux Gazette article referenced above for an example).

It works great, it's very fast, plus I can watch shutdown messages again. Nice!

Update 9/9/2006: the Linux Gazette article isn't accessible any more (apparently Linux Journal bought them and made the old articles inaccessible). But here's an example of what I do in my .login on Dapper -- this is for tcsh, so bash users subtitute "fi" for "endif":

    if ($tty == tty1) then
        startx
    endif

Tags: linux, ubuntu, boot
[ 10:53 Feb 05, 2006    More linux | permalink to this entry ]

Ubuntu "Dapper Drake"

I've been meaning to upgrade my desktop machine from Ubuntu's "Hoary Hedgehog" release for some time -- most notably so that I can get the various packages needed to run GTK 2.8, which is now required to build the most current GIMP.

Although I'm having good success with "Breezy Badger", the stable Ubuntu successor to "Hoary", on my laptop, Breezy is already borderline as far as GIMP requirements, and that can only get worse. Since I do more development on the desktop, I figured it was worth trying one of the pre-released versions of Ubuntu's next release, "Dapper Drake".

Wins over hoary and breezy: it handles my multiple flash card reader automatically (on hoary and breezy I had to hack the udev configuration file to make it work).

I've had a few glitches, starting with the first auto-update wanting to install a bunch of packages that didn't actually exist on the server. This persisted for about a week, during which I got a list of 404s and "packages held back" warnings every time I updated or installed anything. It didn't seem to hurt anything -- just a minor irritant -- and it did eventually get fixed. That's life with an unstable distribution.

Dapper has the same problem that hoary and breezy have with hald polling the hard disk every few seconds (bug 27323). In addition, hald seems to spawn a rather large number of hald-addon-storage processes (probably to handle the built-in multi flash card reader). (Uncommenting the storage.automount_enabled_hint in /etc/hal/fdi/policy/preferences.fdi didn't help.) Killing hald (and nuking /usr/sbin/hald so it won't restart) solves both these problems, but it also stops hotplugged USB devices from working: apparently Dapper has switched to using hal instead of hotplug for USB. Ouch! In any case, hald came back on a dist-upgrade so it looks like I'll have to find a more creative solution.

The printing packages have problems. I tried to add my printer via the CUPS web interface, but apparently it didn't install any printer drivers by default, and it's not at all obvious where to get them. The drivers are there, in /usr/share/cups/model/gutenprint/5.0/en, but dapper's cups apparently isn't looking there. I eventually got around the problem by uncompressing the ppd file and pointing CUPS directly at /usr/share/cups/model/gutenprint/5.0/en/stp-escp2-c86.5.0.ppd. (Filed bug 30178.)

Dapper's ImageMagick has a bug in the composite command: basically, you can't combine two images at all. So I have to generate web page thumbnails on another machine until that's fixed.

gdm refuses to set up my user for auto-login, and I hit an interesting localization issue involving GIMP (I'll report on those issues separately).

Most other things work pretty well. Dapper has a decent set of multimedia apps and codecs, and its kernel and udev setup seem to work fine (it can't suspend my desktop machine, but neither can any other distro, and I don't really need that anyway). Except for the hald problem, Dapper looks like a very usable system.

Tags: linux, ubuntu
[ 18:27 Feb 04, 2006    More linux | permalink to this entry ]

Ubuntu "Breezy Badger"

I installed the latest Ubuntu Linux, called "Breezy Badger", just before leaving to visit family over the holidays. My previous Ubuntu attempt on this machine had been rather unstable (probably not Ubuntu's fault -- 2.6 kernels and this laptop don't get along very well) but Ubuntu seems to have some very sharp kernel developers, so I was curious to see whether there'd been progress.

Installation: Didn't go well. I had most of the same problems I'd had installing Hoary to this laptop (mostly due to the installer assuming that a CDROM and network must remain connected throughout the install, something that's impossible on a laptop where both of those functions require sharing the single PCMCIA port). The Breezy installer has the additional "feature" that it tends to hang if you change things like the CDROM while the install is in progress, trashing everything and forcing you to restart from the beginning. (Filed bug 20443.)

Networking: But eventually I found a sequence that let me get a network-less Breezy onto the laptop, and I'm happy to report that Breezy's built-in networking tools were able to add networking after the first boot (something that hadn't worked in Hoary). Well, admittedly I did have to add a script, /etc/hotplug/pci/3c59x, to call ifup when my cardbus network card is plugged in; but every other distro needs that too, and Breezy is the first 2.6-based distro which correctly calls the script every time.

Suspend: Once up and running, Breezy shows impressive laptop savvy. Like Hoary, it can suspend either to disk or to RAM; unlike Hoary, it can do this without my needing to hack any config files except to uncomment the line enabling suspend to RAM in /etc/default/acpi-support. It does print various error messages on stdout when it resumes from sleep or hibernate, but that's a minor issue.

Not only that, but it restores both network and usb when resuming from suspend (on hoary I had to hack some of the suspend scripts to make that work).

(Kernel flakiness: Well, mostly it suspends fine. Unplugging a usb mouse at the wrong time still causes a kernel hang. That's a 2.6 bug, not an Ubuntu-specific problem. And the system also tends to hang and need to be power cycled about one time out of five when exiting X; perhaps it's an Xorg bug.)

Ironically, my "safe" partition on this laptop (a much- modified Debian sarge) mysteriously stopped seeing PCMCIA on the first day away from home, so I ended up using Breezy for the whole trip and giving it a good workout.

Hal: One problem Breezy shares with Hoary is that every few seconds, the hald daemon makes the hard drive beep and whir. Unlike Hoary, which had an easy solution, Breezy ignores the storage_media_check_enabled and storage_automount_enabled hints. The only way I found to disable the beeping was to kill hald entirely by renaming /usr/sbin/hald (it's not called from /etc/init.d, and I never did find out who was starting it so I could disable it). Removing hald seems to have caused no ill effects; at least, hotplug of pcmcia and usb still works, as do udev rules. (Filed bug 21238.

Udev: Oh, about those udev rules! Regular readers may recall that I had some trouble with Hoary regarding udev choking on multiple flash card readers which I solved on my desktop machine with a udev rule that renames the four fixed, always present devices. But with a laptop, I don't have fixed devices; I wanted a setup that would work regardless of what I plugged in. That required a new udev rule. Here's the rule that worked for me: in /etc/udev/permissions.rules, change

BUS=="scsi", KERNEL=="sd[a-z]*", PROGRAM="/etc/udev/scripts/removable.sh %k 'usb ieee1394'", RESULT="1", MODE="0640", GROUP="plugdev"

to

BUS=="scsi", KERNEL=="sd[a-z]*", NAME{all_partitions}="%k", MODE="0640", GROUP="plugdev"

Note that this means that whatever scripts/removable.sh does, it's not happening any more. That doesn't seem to have caused any problem, though. (Filed bug 21662 on that problem.)

Conclusion: Overall, Breezy is quite impressive and required very little tweaking before it was usable. It was my primary distro for two weeks while travelling; I may switch to it on the desktop once I find a workaround for bug 352358 in GTK 2.8 (which has been fixed in gnome cvs, but that doesn't make it any less maddening when using the buggy version).

Tags: linux, ubuntu, laptops
[ 21:43 Jan 04, 2006    More linux | permalink to this entry ]

Edit sources.list To Get Ubuntu Security Updates

I bet I'm not the only one who uses Ubuntu (Hoary Hedgehog) and didn't realize that it doesn't automatically put the security sources in /etc/apt/sources.list, so apt-get and aptitude don't pick up any of the security updates without extra help.

After about a month with no security updates on any ubuntu machines (during which time I know there were security alerts in Debian for packages I use), I finally tracked down the answer.

It turns out that if you use synaptic, click on "Mark All Upgrades", then click on Apply, synaptic will pull in security updates. However, if you use the "Ubuntu Upgrade Manager" in the System->Administration menu, or if you use commands like apt-get -f dist-upgrade or aptitude -f dist-upgrade, then the sources which synaptic wrote into sources.list are not sufficient to get the security updates. (Where synaptic keeps its extra sources, I still don't know.)

When I asked about this on #ubuntu, I was pointed to a page on the Ubuntu wiki which walks you through selecting sources in synaptic. Unfortunately, the screenshots on the wiki show lots of sources that none of my Ubuntu machines show, and the wiki doesn't give you the sources.list lines or tell you what to do if synaptic doesn't automagically show the security sources.

The solution: to edit /etc/apt/sources.list and make sure the following lines are there (which some of the people on the IRC channel were kind enough to paste for me):

## All officially supported packages, including security- and other updates
deb http://archive.ubuntu.com/ubuntu hoary main restricted
deb http://security.ubuntu.com/ubuntu hoary-security main restricted
deb http://archive.ubuntu.com/ubuntu hoary-updates main restricted

In addition, if you use "universe" and "multiverse", you probably also want these lines:

deb http://archive.ubuntu.com/ubuntu hoary universe multiverse
deb http://security.ubuntu.com/ubuntu hoary-security universe multiverse
deb http://archive.ubuntu.com/ubuntu hoary-updates universe multiverse

Tags: linux, ubuntu, security
[ 21:49 Aug 14, 2005    More linux | permalink to this entry ]

Ubuntu "Hoary Hedgehog" on a Vaio SR17 Laptop

I've been experimenting with Ubuntu's second release, "Hoary Hedgehog" off and on since just before it was released.

Overall, I'm very impressed. It's quite usable on a desktop machine; but more important, I'm blown away by the fact that Ubuntu's kernel team has made a 2.6 acpi kernel that actually works on my aging but still beloved little Vaio SR17 laptop. It can suspend to RAM (if I uncomment ACPI_SLEEP in /etc/defaults/acpi-support), it can suspend to disk, it gets power button events (which are easily customizable: by default it shuts the machine down, but if I replace powerbtn.sh with a single line calling sleep.sh, it suspends), it can read the CPU temperature. Very cool.

One thing didn't work: USB stopped working when resuming after a suspend to RAM. It turned out this was a hotplug problem, not a kernel problem: the solution was to add calls to /etc/init.d/hotplug stop and /etc/init.d/hotplug start in the /etc/acpi/sleep.sh script. Problem solved (except now resuming takes forever, as does booting; I need to tune that hotplug startup script and get rid of whatever is taking so long).

Sonypi (the jogdial driver) also works. It isn't automatically loaded (I've added it to /etc/modules), and it disables the power button (so much for changing the script to call sleep.sh), a minor annoyance. But when loaded, it automatically creates /dev/sonypi, so I don't have to play the usual guessing game about which minor number it wanted this time.

Oh, did I mention that the Hoary live CD also works on the Vaio? It's the first live linux CD which has ever worked on this machine (all the others, including rescue disks like the Bootable Business Card and SuperRescue, have problems with the Sony PCMCIA-emulating-IDE CD drive). It's too slow to use for real work, but the fact that it works at all is amazing.

I have to balance this by saying that Ubuntu's not perfect. The installer, which is apparently the Debian Sarge installer dumbed down to reduce the number of choices, is inconsistent, difficult, and can't deal with a networkless install (which, on a laptop which can't have a CD drive and networking at the same time because they both use the single PCMCIA slot, makes installation quite tricky). The only way I found was to boot into expert mode, skip the network installation step, then, after the system was up and running (and I'd several times dismissed irritating warnings about how it couldn't find the network, therefore "some things" in gnome wouldn't work properly, and did I want to log in anyway?) I manually edited /etc/network/interfaces to configure my card (none of Ubuntu's built-in hardware or network configuration tools would let me configure my vanilla 3Com card; presumably they depend on something that would have been done at install time if I'd been allowed to configure networking then). (Bug 2835.)

About that expert mode: I needed that even for the desktop, because hoary's normal installer doesn't offer an option for a static IP address. But on both desktop and laptop this causes a problem. You see, hoary's normal mode of operation is to add the first-created user to the sudoers list, and then not create a root account at all. All of their system administration tools depend on the user being in the sudoers file. Fine. But someone at ubuntu apparently decided that anyone installing in expert mode probably wants a root account (no argument so far) and therefore doesn't need to be in the sudoers file. Which means that after the install, none of the admin tools work; they just pop up variants on a permission denied dialog. The solution is to use visudo to add yourself to /etc/sudoers. (Bugs 7636 and 9832.)

Expert mode also has some other bugs, like prompting over and over for additional kernel modules (bug 5999).

Okay, so nothing's perfect. I'm not very impressed with Hoary's installer, though most of its problems are inherited from Sarge. But once it's on the machine, Hoary works great. It's a modern Debian-based Linux that gets security upgrades (something Debian hasn't been able to do, though they keep making noises about finally releasing Sarge). And there's that amazing kernel. Now that I have the hotplug-on-resume problem fixed, I'm going to try using it as the primary OS on the laptop for a while, and see how it goes.

Tags: linux, ubuntu, laptops, vaio
[ 16:29 Jun 03, 2005    More linux | permalink to this entry ]

SuSE 9.1 vs. Ubuntu "Warty"

I took a break from housepainting yesterday to try out a couple of new linux distros on my spare machine, "imbrium", which is mostly used as a print server since Debian's CUPS can't talk to an Epson Photo 700 any more.

The machine is currently running the venerable Redhat 7.3 -- ancient but very solid. But I wanted a more modern distro, something capable of running graphics apps like GIMP 2 and gLabels 2. I considered Fedora, but FC2 is getting old by now and I would rather wait for FC3.

First I tried SuSE 9.1. It was very impressive. The installer whizzed through without a hitch, giving me lots of warning before doing anything destructive. It auto-configured just about everything: video card, ethernet, sound card, and even the printer. It missed my LCD monitor; X worked fine and it got the resolution right, but when I went in to YaST to enable 3D support (which was off by default) it kept whining about the monitor until I configured it by hand (which was easy). It defaulted networking to DHCP, but made it clear that it had done so, which made it easy to change it to my normal configuration.

SuSE still uses kde by default, which is fine. The default desktop is pretty and functional, and not too slow. I'll be switching to something lighter weight, like icewm or openbox, but SuSE's default looks fine for a first-time user.

I hit a small hitch in specifying a password: it has a limited set of characters it will accept, so several of the passwords I wanted to use were not acceptable. Finally I gave up and used a simple string, figuring I'd change it later, and then it whined about it being all lower case. Why not just accept the full character set, then? (At least full printable ascii.)

Another minor hitch involved the default mirror (LA) being down when it got to the update stage. Another SuSE user told me that mirror is always down. Choosing another mirror solved that problem.

Oh, and the printer? Flawless. The installer auto-detected it and configured it to use gimp-print drivers. (from gimp-print) worked fine in a full "test page with photo", and subsequent prints (via kprinter) from Open Office also worked. Good job, SuSE!

The experience with Ubuntu Warty wasn't quite so positive. The installer is a near-standard Debian installer, with the usual awkward curses UI (I have nothing against curses UIs; it's the debian installer UI specifically which I find hard to use, since it does none of the "move the focus to where you need to be next" that modern UI design calls for, and there's a lot of "Arrow down over empty space that couldn't possibly be selectable" or "Arrow down to somewhere where you can hit tab to change the button so you can hit return". It's reminiscent of DOS text editors from the early eighties. But okay, that's not Ubuntu's fault -- they got that from Debian.

The first step in the install, of course, is partitioning. My disk was already partitioned, so I just needed to select / to be formatted, /boot to be re-used (since it's being shared with the other distros on this machine), and swap. Seemed easy, it accepted my choices, made a reiserfs filesystem on my chosen root partition -- then spit out a parted error screen telling me that due to an inconsistent ext2 filesystem, it was unable to resize the /boot partition.

Attempting to resize an existing partition without confirming it is not cool. Fortunately, parted, for whatever reason, decided it couldn't resize, and after a few confirmation screens I persuaded it to continue with the install without changing /boot.

The rest of the install went smoothly, including software update from the net, and I found myself in a nice looking gnome screen (with, unfortunately the usual proliferation of taskbars gnome uses as a default).

Of course, the first thing I wanted to try was the printer. I poked through various menus (several semi-redundant sets) and eventually found one for printer configuration. Auto-detect didn't detect my printer (apparently it can't detect over the parallel port like SuSE can) so I specified Parallel Port 1 (via an option menu that still has the gtk bug where the top half of the menu is just blank space), selected epson, and looked ... and discovered that they don't have any driver at all for the Photo 700. I tried the Photo 720 driver, which printed a mangled test page, and the generic Epson Photo driver, which printed nothing at all. So I checked Ubuntu's Bugzilla, where I found a bug filed requesting a driver for the Epson C80 (one of the most popular printers in the linux community, as far as I can tell). Looks like Ubuntu just doesn't include any of the gimp-print drivers right now; I signed up for a bugzilla account and added a comment about the Photo 700, and filed one about the partitioning error while I was there, which was quickly duped to a more general bug about parted and ext2 partitions.

I don't mean to sound down on Ubuntu. It's a nice looking distro, it's still in beta and hasn't yet had an official release, and my printer is rather old (though quite well supported by most non-debian distros). I'm looking forward to seeing more. But for the time being, imbrium's going to be a SuSE machine.

Tags: linux, ubuntu, suse
[ 18:15 Oct 13, 2004    More linux | permalink to this entry ]