Solved Debian update - keyboard responsive, Lennart Sorrenson not so much

[Lennart Sorensen]

On Mon, Oct 31, 2011 at 04:18:56PM -0400, Russell Reiter wrote:
> Ok Lennart even though I've been told you can't pour more water into a
> full glass, still I'm going to try.

Well you keep talking about LSB even though it has nothing to do with
this.

> Debian is an organization made up of humans. Package maintainers are
> humans, although some might argue differently. The organization Debian
> realized that there are problems developing and maintaining packages
> in the current manner.
> 
> Dealing with an event driven kernel requires some elegance in a
> solution, elegance and and a modicum of recycling of code, at least in
> transition.
> 
> This is part of that decision process in terms of when and how to
> inject and monitor commands in the  initialization of the OS.

Sure.  I know what the LSB headers do.  Nothing to do with this.  I know
how sysvinit works, and how insserv works (which is what Debian uses now).

The point of insserv is to speed up booting by starting services in
parallel when possible and to start things in the right order, which
was tricky to arrange using sysvinit's numerical ordering only.

[snip more irrelevant LSB stuff]

> You were the one that warned about not taking the advice of people who
> don't know what they are doing.

Well the bug report you orriginally posted a "fix" from, was one such
person.  And the package maintainer said so in the 3rd comment.
Ths "workaround" was wrong and should not be followed.

A proper workaround would likely have been "insserv -d udev".  Simply
reset the start/stop state of udev to the defaults as specified in it's
LSB header (rather convinient to have such defaults there).  The renaming
workaround did not do that.  Far from it.

> Is this you admitting you didn't really have an idea, oh my god
> Lennart, get a grip on things.

I did not get involved in trying to fix the odd keyboard behaviour,
since I had nothing to contribute to it.  On the other hand when someone
says they found a solution that is clearly a bad idea, that I do have
something to contribute to.  Having archives of problems out there with
incorrect solutions listed as "the fix" without someone pointing out
that is it wrong is not productive.

> What was the right solution you speak of? This is what I got from that thread.
> 
> "It seems that this bug is still not understood, and not readily
> reproducible, so I don't think we should delay squeeze for it.  If/when
> a fix becomes available it can still be considered, either before the
> release or for a point update."

>From having read the bug report the state was:

The cause of keyboard issues was trying to start udev twice.

The udev package itself could never have caused this to happen.

Someone had managed to make gnome's service manager create such an
incorrect duplicate symlink file that caused the problem.  Whether this
was the only way it could happen is unknown.

The original bug reporter suggested a work around involving renaming
one of the runlevel symlink files, which certainly stopped udev from
trying to start twice, but unfortunately should cause it to stop instead.
The package maintainer pointed out this was not the right way to fix it.

So the attempt at starting udev twice caused the problem.  What caused
the extra start script for udev was unclear.

So the correct solution is to remove the incorrect link for udev in
runlevels 2, 3, 4 and 5.  The wrong solution is renaming the wrong link
to a stop link from a start link.  The udev package never created those
links and does not work with them, so removing them makes sense.

It doesn't solve how the wrong link came to be unfortunately, which is
what the bug report seems to be stuck at.

> You see from my point of view, in all this there is no right or wrong,
> only functional and non-functional.

On current debian systems, udev is by design supposed to start in runlevel
S (startup), and stay running.  By renaming the extra start script in
runlevel 2 to a stop script, the setup now says to start udev in runlevel
S and then stop it when moving to runlevel 2.  Clearly that is not how
the system was designed to run, so it is wrong.  It would seem in this
case that perhaps that isn't what turns out to happen, but it is what
that configuration should cause to happen.  So the configuration doesn't
match what should happen, hence it is wrong.

I am tempted to create a virtual machine and go create the extra link
for udev and then rename it to try and figure out why it isn't doing
what is should be doing.  It could be another bug after all, which if
fixed would turn the "bad" workaround into a broken system again.

> Since both keyboards and mice work when they are plugged in, hot or on
> boot, as well as the other usb device's I had to fool with at the
> time, the usb Multi Function Unit and various usb dongles, what's
> broken here?

The only thing broken seems to be the config and the fact that the
system appears to not be entirely following it.  Clearly the keyboard
is working.  Certainly the renaming work around does not put the system
back into the state a freshly installed system would be (which would only
have the udev links in rcS.d since udev never stops on normal systems).
It would not have any S or K scripts for udev in any other runlevel.

lennartsorensen:~# ls -l /etc/*/*udev
-rwxr-xr-x 1 root root 8047 Jun  4 20:35 /etc/init.d/udev
lrwxrwxrwx 1 root root   14 May 13  2010 /etc/rcS.d/S02udev -> ../init.d/udev

That's all I see on a normal install.

> I can't tell from the hardware and neither can you from your theories.
> Yet you pontificate on the right solution, when you still don't
> understand the problem.
> 
> That's what's broken here Lennart, you don't understand the problem.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208010

What does LSB init scripts have to do with whether something creates an
extra link to udev's init script breaks things?

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists