I finally found the cause of this pesky bug!
At some point, an "aptitude full-upgrade" seemed to fix this problem.
But not always.
The problem is that I could never come up with a consistent failure
scenario. Well, today, I finally did. It turns out
that, for me, the failure only occurs when usi
Stephen Powell wrote:
> I finally found the cause of this pesky bug!
> At some point, an "aptitude full-upgrade" seemed to fix this problem.
That was probably at times that sysconfig-hardware was broken... A next
fixed version of that package would have reintroduced your "problem".
> The problem
On Wed, 3 Feb 2010 11:53:47 -0500 (EST), Frans Pop wrote:
> They are not mystery files at all. They are part of sysconfig-hardware and
> their exact purpose is to bring up devices during system boot!
I'm sure that they are no mystery to you, but they *were* a mystery
to me until you explained the
Stephen Powell wrote:
> So whenever a dynamically linked device showed up using one of the
> device numbers 0400-0403, sysconfig-hardware was convinced it needed
> to be brought online immediately! What I don't understand is why,
> when it is *manually* varied offline *after* being brought online
On Wed, 3 Feb 2010 14:14:51 -0500 (EST), Frans Pop wrote:
> Because sysconfig-hardware gets triggered by udev when the kernel tells
> udev there's a new device...
> When you dynamically add hardware that way I guess it's a new device for
> the kernel, just like inserting/removing/reinserting a US
> It may not be a bug in sysconfig-hardware. It may be a bug in udev, I
> don't know. Nevertheless, I still think there's a bug *somewhere*.
I'm fairly certain that it's not a bug in sysconfig-hardware, nor in
s390-tools, and probably also not in udev. *If* there is a bug (as opposed
to due to
6 matches
Mail list logo
