well, i don't think it's a matter of paralelized init scripts. this particular bug is a clear race, but in general the init system needs to be replaced by something that knows about dependencies.On Oct 28, Steve Langasek <[EMAIL PROTECTED]> wrote: > > On Oct 28, Dominik Sauer <[EMAIL PROTECTED]> wrote: > > > > when I change the timeout to higher value (26 on my machine, but your > > Which POS hardware are you using? This is a bit uncommon... > ... so race conditions are ok if they're only known to affect uncommon > hardware? I am still trying to understand which default value is appropriate. If too long, then time will be wasted if there is a deadlock (which so far appears to be a less important problem, so I will probably raise the timeout in the future). Anyway it's not yet sure if/how much this will be needed, it's only an hack I need to use because Debian does not have parallelised init scripts.
meanwhile, would'nt be nice to split the devices into two? configurable ? classes:
-important ones, which shall be waited for forever, as their failure make the system die anyway (ide subsystem, consoles, keyboards,... for the x86 world ), and
-less important ones, which can be spawned into background and left to take care of themselves, maybe running dependent daemons/initscripts on demand after loading the devices. (soundcards, mobiles, palmpilots...)
who decides? dpkg-configuring user, maybe ?
