In all fairness, Perrine probably only deserves the blame for the
first chunk of this, not the whole thing, unless she's learned my
root password and has been very naughty in the past few days ...
Okay, so earlier Perrine managed to do something screwy when she
stepped on my keyboard. I started writing a plea for help, before
it dawned on me that I need to be able to type '-' to post using the
LJ client I normally use ... and then my ride to
rehearsal showed up before I managed to post using the web interface
so y'all got the
very abbreviated version via SMS. There were more details in
( the version I typed in but didn't manage to post earlier )
Well, I've got the keyboard working normally again, but other
bits of the Debian box are acting messed up...
When I got home, I tried unplugging the keyboard and plugging
it back in, thinking the problem might be a keyboard firmware command
rather than an OS or WM toggle. No change. ( other stuff
I tried )
Then something I did finally effected a change!
The keyboards stopped working entirely. :-(
Both of them.
Finally, I decided it was time to bite the bullet, close
the gobs of windows open on three of the four virtual desktops,
and shut down the several projects (and, of course, scattered
web surfing) that I'd been in the middle of and hadn't wanted
to lose my place in. Maybe logging out would take care of
Well no, I couldn't type anything in the username box on
the X login screen, either. Nor, at that point, could I even
shut the machine down cleanly. Finally, exasperated, I used
BRS shutdown option (actually it's a wee translucent
pushbutton with a green LED behind it, but I don't think
"WGGB" -- wee green glowing button -- has quite the same
degree of recognition as "BRS") and counted on EXT3 to save
me from an uncomfortable fsck later.
Well here's where this turns from a too-long-for-its-triviality
"I cycled power and it's okay" story, into a full blown
"WTF? + Why Me? +
type of adventure. You see, after I rebooted, I could not
And so began the shaving of the yak. It turned out that
I could log in as root, so I reset my password just
in case it had gotten munged somehow. Nope, still couldn't
log in as myself: enter username, get password prompt, enter
password, get initial login screen again. Feh. So I tried
a bogus password just to check, and waitaminute, that got me
an error message instead of just #blink#ing back to the splash
screen. So, something screwed up in one of those dot-files
in $HOME controlling X sessions, that I'd never bothered to
look at or learn anything about? Well logging in as root
again and running "ls -a ~dglenn | more" did turn up an
interesting-looking filename, .xsession-errors, with a
It was complaining that the X startup script in /etc/gdm/Xsession
(oh! I guess that means I'm using Gnome then -- I'd wondered)
couldn't access /dev/null. WTF?! "Can't access /dev/null??
That doesn't sound at all reasonable..." Sho' 'nuff, /dev/null
was 660, which Looked Wrong to my eye. Very wrong. In case
fatigue was clouding my judgement, I telnetted to a Linux box
downstairs to compare: as I'd thought I'd remembered (and as
really only makes any sense at all), /dev/null over there was
666. Chmod 'dat, try again. Different glitch, and no login
screen; power cycle the puppy agin' and try once more ... and
/dev/null is 660 again ...???? Log in as root, chmod the damned
null device, log in as myself, and fail because there's no
entropy collector. Ask 'man' about "random" and see that
/dev/random and /dev/urandom are supposed to be 644 but they're
660 too. Chmod those, and /dev/hw_random as well on a hunch,
and try <voice tone="whine" pitch-modifier="nasal"
log in as myself ...
*Whew!* A Gnome desktop. BUT...
... but when the very first thing I tried to do -- start
a terminal window -- only half-worked, I feared I might wind
up taking tweezers to the damned yak before the night
ended. The window popped open, but so did an alert box telling
me it couldn't start the child process for the window. I don't
remember where I saw some error message refer to a pty, but
(Wait, wait, can you guess what the Next Problem
turned out to be? Sure you can; it fits the theme. Yeah, that's
right, you got it ...) sure enough, when I looked at /dev/pty*,
the permissions were fucked up there as well.
I wonder: are all these permissions going to be munged again
the next time I reboot? Or just /dev/null? More importantly,
what have I not found yet that's going to bite my
ankles repeatedly in the next several days? [Later Edit: SSH is broken -- when I try to connect to the Suse box as myself, I get "
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory", and if I try to do it from a root prompt it asks me for a password but no password I enter works. SSH was working perfectly fifteen hours ago!]
And what screwed
this up in the first place?
It's conceivable that some malicious cracker has broken into
this computer -- security on my house LAN is not very strong, nowhere
near as strong as I really know it really ought to be (and really
will be, real soon now, when I get around to it) -- but seems
pretty darned unlikely since it's behind a masquerading router.
A worm or virus is much more likely considering that even though
I am immune to malware that propogates via email, I have
picked up malware from a compromised web site.
But I suspect -- purely on a hunch, mind you, with no more
evidence than a nagging distrust left over from the time it
overwrote my kernel -- I suspect that some recent update via
aptitude/apt-get/etc. mangled the permissions on a bunch of
system device files that some upgraded package claimed dominion
over. 'Cause yeah, I did run a couple of updates during the, uh,
[pause to look it up]
month + 1.5 days since the last time I logged off of this
computer (or the last time the power went out or something ...
I don't log off of the bedroom machines often).
Anyone with more current Linux sysadmin skillz and/or who
has had something like this happen to them, care to provide
additional clues? Evaluate my guesses as to the likelihood
of the cause? Suggest where else I should look for related
problems first (before trying to sift the entire file system)?
there any more ideas on what magic chord Perrine struck that
triggered the odd keyboard behaviour
that started this exercise in the first place, and how
to undo it without the involvement of hirsute bovines if she
manages to hit the same magic combination again?
All in all, I'd have to call the yak only half-shaved
considering that I didn't wind up nested three topics deep
in a Google search, or have to suddenly learn All The
Details of X customization and management that I've been
putting off reading up on for too long, but it was still
a rather longer detour than I'd been prepared for when I
decided to reboot the machine.
(Keep saying it: "I love my cat. She didn't mean to do it.
I love my cat. She didn't mean to do it. I love my cat ...")
And in the morning, I get to start figuring out where
I was in various things that got closed when I rebooted.
 I knew I was most likely
using either KDE or Gnome, but a) I hadn't gotten around to
looking closely at both to see what the pros and cons of each
are, b) I got this machine already configured, so all I did
was change the root password and add an account for myself
when I got it, not select all those install-time choices that
would've tipped me off, and c) whenever I try to install
something that says it's a Gnome app it just works, and
whenever I try to install something that says it's a KDE app
it just works, so that didn't seem like much of a clue
either. The result was that yes, I've been using a modern
Linux GUI for something like a year and a half without having
gotten around to figuring out whether I was using Gnome or
KDE until now. When things basically just work
and the interface doesn't piss me off, details
like that seem like things I should know but don't seem
urgent, so the pertinent Round Tuit wasn't being stalked
 If I know how to reliably
turn this mode on and off, it would actually be
kind of useful. I've been saying for years that I wanted
a SHIFT-LOCK button -- like on the manual typewriters I
used to use -- on my computer keyboards somewhere in the same
general area as the CAPS-LOCK key. Caps-lock is usually
more useful than shift-lock, so I wouldn't want to get rid of
it, but I find myself wanting shift-lock just often enough
to fondly remember the dumb terminal I used a long time
ago that had both. (Hey dmk, it was one of
the ones we used at UD,
wasn't it? Do you remember? I think it was one of the
CRTs, but I'm not 100% certain that it wasn't the DecWriter.)
Thing is, I want it just seldom enough to keep forgetting to
look up whether it's easy to switch on and off on various
modern operating systems that might have it as an accessibility
feature. Now that I've been told two invocations I'll
play with that under Windows, but neither seems to have any
effect on this Linux box.
 Which brings up a topic for
a separate entry of its own, when I get around to that.