February 22, 2010:

Debian is becoming increasingly frustrating these days.

First Konqueror instructs me to upgrade the web browser and call tech support to FIX A 404. Yeah. The ACTUAL problem is that Netscape added a not-in-the-RFCs 'Refresh:' header to HTTP and either the remote website is broken for using the stupid refresh extension or Konqueror is broken for not obeying it.

Next, I decide to fix a problem that's been nagging at me for some time. As you know, I'm a size queen - I found a 1680x1050 CRT that some silly person had thrown out just because it weighs as much as a small car and drains almost as much power as a hovercraft made out of hairdryers. I had to do some gymnastics to force it to actually do the desired resolution (or perhaps that was one of its predecessors? It was some time ago, so I don't remember for certain) and that wound up disabling keyboard mode-switching. Some upgrades ago, I noticed control-alt-backspace failing when an X app had somehow hung the system. I cursed and hit the Big Red Button on my dead computer.

So, today I get a bug report that hits when an app scales down to accomodate a smaller-than-default screen. Okay, time to actually fix everything that's been naggingly wrong with my X installation. Close everything, control-alt-backspace (and as I push it, I think 'ah wait, I should be '/etc/init.d/gdm stop'ping instead, but ohwell.) Wait, that's funny, it's not... come to think of it, wasn't it failing before? Control-alt-backspace. CONTROL-ALT-FUCKING-BACKSPACE.

No response. X is working, cursor movements work, I can start new apps, I can switch into TTYs and start and stop GDM. I just cannot control-alt-backspace my way out of a running X session.

Okay, now it's time to edit the config file for real.

Nothing controlling control-alt-backspace in the comments in it. Huh. There is, however, an admonition in the comments at the beginning to 'Type "man /etc/X11/xorg.conf" at the shell prompt.' Which, unsurprisingly, tries to display my xorg.conf as a manpage. *shrug* That's not important, it's just an obvious typo. man xorg.conf works, explains that I need to turn off the DontZap option. The default is 'off'... wait, if it's not in my config, and the default is off, why isn't control-alt-BS working? Maybe someone made a harmless little typo in the man page and by 'the default is off' they meant 'the default is on'.

So I try various arrangements of the DontZap option. None of them enable me to actually Zap. ARGH.

... A websearch finds the answer. Apparently someone was worried that newbies accidentally pressing control-alt-backspace would lose their work. So it's been disabled by . IN XORG. Great. Ya know, I could have lost some work red-buttoning my way out of X hangs that control-alt-backspace SHOULD have gotten me out of - and I seriously doubt that I'm the only one. Oh well, there are pages telling me how to reenable control-alt-backspace, and the instructions are on this link here. *follows link* *watches Lynx explode with a malloc problem*. THAT, at least, goes away when I upgrade Lynx. And I'm tracking testing, so an app crashing isn't completely horrible. Now I can read the instructions!

... which tell me to DontZap to false. Which apparently works great. At least, it did last year for several people who aren't me. Pity I'm me and it's not last year, innit.

(To be exact, the webpage actually tells me to set “DontZap” to “false”. You will note the curly quotes. Using curly quotes instead of real quotes enables me to kill the X server! However, killing the X server with a parse error in xorg.conf doesn't actually meet my requirements. I'm DEMANDING. I want the server to stay unkilled until I tell it to.)

There's more advice, revolving around reconfiguring console-setup (which doesn't actually do anything relevant), installing dontzap (which isn't in Debian), using magic sysrq (... which also seems disabled).

There's something that looks plausible on linuxquestions.org, but the link is an infinite redirect loop on Lynx. I see they're firm believers in the principle of designing against the target audience.

Luckily, google cache gives me access to linuxquestions.org. Turns out that the ACTUAL fix is to run 'setxkbmap -option terminate:ctrl_alt_bksp' at a shell prompt once I've started X. Okay, I'm sure I'll be able to find a place to put it... lessee... /etc/X11/xinit/xinitrc - no. Doesn't do anything. At least, not if I start X with xinit, which one would presume from the comments in the config file would work. OH WAIT, someone decided a few years ago that systemwide config files were unfriendly because changes made to them would affect all users, possibly breaking their customized .xinitrc.

I fiddle around some more. I remove my .xinitrc to see what happens when I run xinit without it. Somewhere in my ten zillion start-stops of X I manage to get the system stuck on a black screen (though control-alt-BS wouldn't have helped with that one, as X wasn't running - luckily, sshing in and 'kbd_mode -a' did fix it).

My .xinitrc now reads

setxkbmap -option terminate:ctrl_alt_bksp
exec /usr/bin/fvwm
This won't, of course, help any other users on my system (and I DO have other user accounts. Most of them are me with a different login so I can fuck around with software I don't trust on my main account for one reason or another, like maybe it's a Windows game that I want to test without exposing all my files to any backdoors, or maybe it's a daemon that I'm writing that I don't really want to discover a remote-shell bug in by having my .bashrc throw me into a dark dream.

But I now have control-alt-BS!

... as long as I start from xinit and not gdm.

Putting the setxkbmap into /etc/X11/Xsession.d/99x11-common_start, though, lets me control-alt-backspace after I've logged in. Which is enough, really - control-alt-BSing a running GDM is pointless even in my opinion.

Closing thoughts:

The fix might have gone faster if I hadn't ranted about how annoying it was while doing it.

It would be a good idea for upgrades that ignore previously-honoured systemwide config files to either delete them or (preferably) move them to, say, /etc/old/(oldpath). That way we wouldn't waste time editing them. Might be an impractical task, though, especially for things that use the something.d/00dofirst, 01dosecond.sh approach.

... oh gods, I still need to fix mode-switching.

 
   
   
 
   

{ Add Comment }