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

Tue Nov 1 01:40:31 UTC 2011

On Mon, Oct 31, 2011 at 6:03 PM, Lennart Sorensen
<lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:
> 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.

LSB Init Scripts are for boot ordering. Besides why is it so
convienient to have access to the headers, as you mention below?

How about fine grained control over exit status as one thought?

>
>> 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

Nothing to do with customizing ordering, as in when to initialize udev
in the init process?
When to start it initially to populate a device file system?
When to understand when the devices are connected to their respective
inodes by static and symbolic links?

> 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.

Here's the third comment, all the maintainer said was he was sure the
system was broken in some way, with an if, and it's a pretty big if,
if after rebuilding initramfs it still doesn't work.

"Rebuild the initramfs. If it still does not work then run its scripts
step by step as explained in the man page to find out why udevd is not
being killed when it should be.
But I am quite sure that you broke your system in some way."

But see for me now udevd is being killed correctly. I didn't have to
rebuild anything. I renamed one file.

>
> 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 guy who posted the fix actually said to rename the scripts in two
folders rc2.d and rc3.d

> The package maintainer pointed out this was not the right way to fix it.
>

It was the package maintainer who snipped out the second one in his
reply. That's why I don't like all this snipping of posts, it confuses
things.

> 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.

This hardware is now working as it was before the IO problems, hence
it is right.

Or are you looking at this like the new math I had to learn in the
70's. It doesn't matter that the answer is wrong, as long as the work
is shown to have been done correctly.

>
> 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).

See maybe thats part of the problem, if you are not hot plugging
anything and the static system is working, why bother with udev?

>From what I see udev has some problems with uniformly re-identifying
nodes when the bus is polled on a new trigger. It can take a bit of
work to sort issues out when that happens.  It's easier to figure out
stuff now with udevadm attribute-walk but still, does udev need to run
as a dameon, why not just kickstart it with some other kernel event.

> 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?

So I can deal with udev the way I need to. Remember one person's bug
is another person's feature.

But hey, if you can get your virtual machine built and broken by next
Sunday, I'll be up at buddies trying to explain to him why his real
working computer is so abnormal.

We can compare notes then.

>
> --
> 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
>
--
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