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

[Lennart Sorensen]

On Mon, Oct 31, 2011 at 09:40:31PM -0400, Russell Reiter wrote:
> LSB Init Scripts are for boot ordering. Besides why is it so
> convienient to have access to the headers, as you mention below?

Certainly handles ordering.  It does not handle whether something should
or should not be started, only what order it should happen if it should.

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

The exit status might be handy at times.  Not sure it is that major
an improvement.

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

The LSB headers control when to do things within a given runlevel if asked
to do something.  So it controls when udev starts in runlevel S at startup
relative to other things being started and stopped.  It also controls
when it starts/stops in runlevel 2 if (incorrectly) asked to do so.
The only thing it doesn't control is if something should be started or
stopped.  The symlinks are still used for that.  The numerical ordering
of the symlinks in the runlevels no longer get used.

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

Yeah this was before it was determined that the initramfs had nothing
to do with it, but rather the errant symlink in rc2.d (and rc3.d) was
the problem.

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

The initramfs idea was an unfortunate wrong direction.  It did make sense
though since initramfs runs udev, then stops it, and then rcS.d runs udev,
so if initramfs failed to stop udev, that could explain it starting twice.
When it was discovered that there was another start script in rc2.d though
that explained the second start attempt instead of the initramfs idea.

So the initramfs was killing udev correctly, and rcS.d was starting
it correctly.  The unexplained link in rc2.d though that was trying to
start it a second time was the problem.  There was no need to kill udev,
only a need to not try to start it again.

> The guy who posted the fix actually said to rename the scripts in two
> folders rc2.d and rc3.d

It was probably in 4 and 5 as well then.  Either way, renaming it to a
stop script isn't the right way to go.  Removing it when it shouldn't
be there is.  Asking insserv to reset the udev scripts to the default
state would probably be an even safer 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.

Well it is standard operating procedure on mailing lists and avoids
messages getting overly huge and unmanageable.

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

That is a rather simplistic and wrong way to look at things.

So if your car drives, it is in perfect condition even if you have a
flat tire or at least a very underinflated tire.  Just because you don't
see a problem doesn't mean there isn't any.

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

Well if the work was done correctly at every step, the answer can't
be wrong.  Some step has to be done wrong to get the wrong answer.

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

Feel free to uninstall it if you don't think it is useful.  Systems used
to run fine without it, although there was some management of device
nodes and module loading to be done.

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

To some extent the kernel could be made to kick things, but on the other
hand the kernel developers do seem to like pushing decision making to
user space whenever possible.  It may also be more efficient to not have
to load and initialize udev for every event.

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

I am installing a VM right now.  I will have to go see about setting up
a USB keyboard in KVM since I think the default is an AT or PS/2 keyboard
which might not break the same way a USB keyboard would.

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