Linux/Ubuntu

I really want to run Ubuntu, but it shouldn’t be this hard. Plugging in an SD card reader that I picked up from Best Buy shouldn’t cause a hard freeze of my system (on both Gutsy Gibbon and Intrepid Ibex):

The card reader works fine in Windows. At this point, I’m honestly thinking about crashing the Ubuntu Developer Summit that will be held in December at the Googleplex in Mountain View, CA to pick peoples’ brains.

Okay, so Ubuntu freezes hard when you plug in the card reader (sometimes). Unless you report that bug, no one will know to fix it. So I’m trying to follow these instructions for debugging removable devices to do a good Ubuntu bug report, and finding that the instructions are pretty out-of-date.

For example, you’re supposed to kill, then start gnome-volume-manager in a foreground mode to see debugging messages. Except that the latest version of Ubuntu (Intrepid Ibex) doesn’t even install gnome-volume-manager. Oh, you can install it (and you’ll get the sound-juicer package with it). But when you try to run it, you’ll get this helpful message:

$ /usr/lib/gnome-volume-manager/gnome-volume-manager -n
manager.c/685: setting[0]: string: filemanager = nautilus -n --no-desktop %m
manager.c/690: setting[1]: bool: autophoto = 0
manager.c/685: setting[2]: string: autophoto_command = f-spot-import
manager.c/690: setting[3]: bool: autovideocam = 0
manager.c/685: setting[4]: string: autovideocam_command =
manager.c/690: setting[5]: bool: autowebcam = 0
manager.c/685: setting[6]: string: autowebcam_command = cheese --hal-device=%h
manager.c/690: setting[7]: bool: autopalmsync = 0
manager.c/685: setting[8]: string: autopalmsync_command = gpilotd-control-applet
manager.c/690: setting[9]: bool: autopocketpc = 0
manager.c/685: setting[10]: string: autopocketpc_command = multisync
manager.c/690: setting[11]: bool: autoprinter = 0
manager.c/685: setting[12]: string: autoprinter_command =
manager.c/690: setting[13]: bool: autoscanner = 0
manager.c/685: setting[14]: string: autoscanner_command = xsane
manager.c/690: setting[15]: bool: autokeyboard = 0
manager.c/685: setting[16]: string: autokeyboard_command =
manager.c/690: setting[17]: bool: automouse = 0
manager.c/685: setting[18]: string: automouse_command =
manager.c/690: setting[19]: bool: autotablet = 0
manager.c/685: setting[20]: string: autotablet_command =
manager.c/699: settings[21]: float: percent_threshold = 0.050000
manager.c/699: settings[22]: float: percent_used = 0.010000
manager.c/664: daemon exit: live and let die

It’s easy to find the source code of gnome-volume-manager online, but the relevant function is more cute than informative. Searching for ["live and let die" gnome-volume-manager] finds this post where someone tries to guess what the message means:

Fedora no longer uses gnome-volume-manager to auto-mount removable media — it’s now built into Nautilus. I am guessing that “live and let die” means “hey, someone else is already managing this” but that is pure speculation on my part. So if you get that error message it just means that you shouldn’t have been running it in the first place.

With that clue, you can go back and find this thread where Ubuntu developer wgrant helpfully lets someone know “gnome-volume-manager is no longer necessary either – nautilus does the mounting now.” It is good to find an Ubuntu developer posting answers online. But now I’m not sure how to generate Nautilus debugging logs akin to the gnome-volume-manager logs that fellow Ubuntu folks could use to debug the hard freeze. At least I do know how to generate udevmonitor logs using the new udevadm program.

Please pardon the melancholy tone. It’s just frustrating that plugging in an SD card reader can cause sporadic freezes on my Ubuntu computer. And if you plug in the SD card reader often enough, you may corrupt your system. I do see progress from Hardy Heron to Intrepid Ibex with several annoyances fixed, but there’s still a way to go.

Update: If any Linux/Ubuntu folks want to dig into it, I put all the log files I could think of at http://www.mattcutts.com/files/sandisk/ for folks that want to check it out.

{ 33 comments }

In case you’re looking for the “udevmonitor” program on the Intrepid Ibex version of Ubuntu, it’s changed; use “udevadm monitor” now:

$ udevadm help
Usage: udevadm COMMAND [OPTIONS]
info query sysfs or the udev database
trigger request events from the kernel
settle wait for the event queue to finish
control control the udev daemon
monitor listen to kernel and udev events
test simulation run
version print the version number
help print this help text

It looks like udevmonitor was a symlink, and around April 2008, that symlink was removed. Someone asked about it on the Linux kernel mailing list and received this reply:

All udev tools are in one single binary called “udevadm”, which is
always in /sbin, and not like the old tools spread around in /sbin,
/usr/bin, /usr/sbin. See “man udev” for the reference to udevadm, and
“man udevadm” for the commands, which have been the individual tools
before.

So if you have a USB device that causes a hard freeze of your Linux computer when you plug it in, and you want to run udevmonitor to debug it, use udevadm monitor instead.

{ 2 comments }

(This is a boring post that I’m writing for people that have this same problem in the future. Just skip it.)

Every good Linux user knows that if you want to drop from X down into a text-based virtual terminal, you can press control-alt-F1 (or any other key up to F6), and control-alt-F7 returns you to the graphical mode. But what if that doesn’t work? In my case, it turned out to be my keyboard. My Microsoft Natural Ergonomic Keyboard 4000 has a key marked “F Lock” and unless that FLock key is activated (the “F” LED should be on), the wrong keystrokes were being sent to my Linux Ubuntu version of Intrepid Ibex. How can you debug this? Well, it took me a while.

After some Googling, here’s how I’d write the flowchart:

- Try running “chvt 1″ to switch your console to virtual terminal 1.
- If “chvt 1″ does not work, you might get the message “Couldnt get a file descriptor referring to the console”. You probably need to be superroot. Once you run as root, that command should work.
- Maybe “chvt 1″ fails in some other way. Dude, you’re outside my area of expertise. You could try typing “sudo modprobe vga16fb; sudo modprobe fbcon” . Or you could try typing the command “setupcon” to set up the font and keyboard on the Linux console. Or it’s possible that you need to edit /boot/grub/menu.lst and tweak the vga= setting or remove the “splash” parameter. Or you might want to check your /etc/gdm/gdm.conf file.

- Quick check: you might have the “DontVTSwitch” option set in your /etc/X11/xorg.conf file, which would disable virtual terminal switching.

- If running “chvt 1″ as superroot does work, then you probably have an issue with your keyboard mappings somehow.
- If you have a Microsoft Natural Ergonomic Keyboard 4000, make sure that the “F-Lock” key near the top-right of the main part of the keyboard is properly engaged. The “F” LED below the keyboard should be on.
- Next, run xev (possibly as root) to see raw xevents as you press keys. This thread helped, where the person said

Recently I tried to switch to VT (console) and I couldn’t – Ctrl+Alt+F1 didn’t work (and they used to couple of weeks ago). I don’t even know where to look for the problem; xev detects KeyRelease XF86_Switch_VT_1 event, /etc/inittab contain getty respawns.

When I ran xev myself, and pressed control-alt-F1, I saw an event like

KeyPress event, serial 38, synthetic NO, window 0×3400001,
root 0×1a6, subw 0×3400002, time 1848943, (42,37), root:(1751,59),
state 0×0, keycode 146 (keysym 0xff6a, Help), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

The fact that I saw a “Help” event rather than “XF86_Switch_VT_1″ was what made me suspicious. Sure enough, activating the “F-Lock” key then triggered this event:

KeyRelease event, serial 34, synthetic NO, window 0×3400001,
root 0×1a6, subw 0×3400002, time 2873229, (38,51), root:(1747,73),
state 0xc, keycode 67 (keysym 0×1008fe01, XF86_Switch_VT_1), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

and life was good. You might also consider tweaking xmodmap to return the values you expect. Or you might have a strange XkbModel or XkbLayout setting where switching your keyboard language or layout (e.g. from pc105 to pc104) might help.

{ 0 comments }

A new version of Ubuntu (Intrepid Ibex) is coming out this week, so I’m trying out the release candidate. Here’s an annoyance I hit and how to solve it. I keep a list of steps to perform after installing Ubuntu, and one of my steps is

Drag the bottommost taskbar/panel to the right and the topmost taskbar/panel to the bottom.

I like my “start menu” at the bottom of the screen like Windows does rather than at the top of the screen like Apple’s Mac OS X does. Dragging the bottom panel to the right works fine, but dragging the top panel to the bottom of the screen didn’t work! So I do what any GNOME user would do: I right-click the panel, select “Properties,” and try to set the Orientation from “Top” to “Bottom” in the General tab. Except I can’t.

Instead, I see the message “Some of these properties are locked down”. So I do a Google search for that exact phrase. There’s not many pages that match that phrase, and most of them are translation pages. Grr. That means that not many people have encountered this problem before. After a little query rejiggering, I search for [gnome panel properties locked down] and find this Ubuntu forum thread in which the person says

It sounds like your gnome-panel is locked down. You can remedy this from gconf-editor. Start it from the quick launch dialogue (ALT+F2) or from the terminal: [with the command] gconf-editor

Once the editor has opened, navigate to “apps” > “panel” > “global”, and uncheck the key called “locked_down”.

Great! That sounds easy. I fire up gconf-editor and navigate to that spot, only to find that apps/panel/global isn’t set to locked_down. Hmm. Maybe there’s another locked_down value that is superseding things somewhere else? I search for locked_down anywhere else in gconf-editor and find something at /schemas/apps/panel/global/locked_down, but the value for that is a “<schema>”, and when I try to edit that, gconf-editor helpfully tells me that “Currently pairs and schemas can’t be edited. This will be changed in a later version.” Grrr. So that schema might be affecting my locked-down panel, but I can’t edit it? This is roughly where I start cursing in my head.

But that’s okay, because I’m a computer science geek. If I have to find a “locked_down” text string in the underlying filesystem, I can do that. I search in all the delightful dot directories in my home directory, and I don’t find any mention of that string. Quick pop quiz: would it be in .dbus, .local, .config, .cache, .gconf, .gconfd, .gnome2, or .gnome2_private? Hey Ubuntu/GNOME developers, do I really need 29 (really!) dot directories after a fresh install?

By the time that I’ve sudo’ed to a root shell and I’m in /etc running “find .* type -f | xargs -i{} grep -i locked_down {}” that’s when I’m cussing out loud. So I take a deep breath, metaphorically step back, and head to the Google again. This time I search for [gnome lock top panel] and the #1 result is this Ubuntu bug which leads me to this GNOME bug.

Browsing those bugs makes it clear what happened. Some non-savvy users with really sensitive touch pads were accidentally dragging their panels all over. The solution was to lock the top panel. I can understand why that decision got made. The discussion on the thread didn’t contain the answer (they were talking about making ALT+drag move the panel and mentioned another discussion about this issue), but it made me rethink what I was doing. GNOME/Ubuntu people were shooting to make accidental drags impossible, but they must have made it possible to drag the panel somehow. So I go back to the panel, right-click on it, and carefully read through the options. Sure enough, there’s an option under the right-click menu: “Allow Panel to be Moved“.

I understand why GNOME or Ubuntu folks decided to lock the top panel: they wanted to avoid accidental click-and-dragging by novice users. And maybe it’s my responsibility to carefully study every new menu when I install a fresh version of Ubuntu, instead of just quickly working through the instructions that I’ve written for myself without scouting out every new option. But if I right-click on a panel and select Properties, it’s pretty utterly useless to tell me “Some of these properties are locked down” without giving me any help on where to unlock the properties. There has got to be some user interface principle that says “Giving people an error message without any pointer on how to fix the error is frustrating.”

Is Intrepid Ibex better in some ways? Absolutely. It identified my display resolution correctly on my Wal-Mart PC that I use as my canary for test driving before I install Ubuntu on an important computer. That’s a first. But for everything that works better in recent versions of Ubuntu, I worry that something else will break. That’s why I predicted that Apple would approach 20% market share this year and not Ubuntu. I still root for Ubuntu and want it to do well, so I’ll keep you posted on what I find as I play with Intrepid Ibex.

{ 23 comments }