On Wednesday 15 August 2007 22:22, Kevin Valko wrote:
On Wednesday 15 August 2007 09:10:45 pm Rajko M. wrote:
On Wednesday 15 August 2007 12:54, Kevin Valko wrote:
and maybe disabling parallel services as well.
I would start with that. Than you have better chance to find service that makes trouble.
Disabling parallel services did allow the system to boot normally without requiring interactive confirmations, so there is definitely a conflict happening somewhere with the boot services running in parallel.
Unfortunately I'm not sure which one, I tried disabling a number of them individually but the boot still hard-locked when parallel services were enabled, I guess I can try to change the S/K sequences in boot.d, to see if grouping the services (the culprit lies in S12) instead of all together can point out the issue. Grrrr.
On the plus side, disabling parallel loading didn't have a too significant impact on my boot time, it's still more or less in line with what I had in 10.2, so it's hardly the end of the world, but it is kind of a drag since faster booting is one of the significant improvements for 10.3.
Cheers, KV
Hi Kevin, If parallel booting makes problem, than is some of scripts the culprit. It doesn't wait for it's dependencies to be performed. Grouping services will not help much as they are not ran sequentially anyway, but cleaning log files, booting and after lockup, booting Live CD and looking in logs may help to debug issue. The other method to isolate script would be add echo command to scripts that will give on the screen script name. For instance echo $0 >> /tmp/startup.log That will at least tell what was loaded before lockup and it will be preserved after new boot. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org